Projects API show whether a project requires/prevents squashing
Release notes
Currently, the Projects API has a beautiful way to Get a single project
, as described here. Through that API, a user can see lots of settings about a specific project, including Merge Request merge settings (such as source branch deletion after merge, merge method, etc). However, there's no place where the API shows whether a project requires, prevents, encourages, or allows the squashing of commits. This seems like a definite hole in the API response, and it would be helpful to be able to obtain this information from a single API command.
Problem to solve
As a user of GitLab and the GitLab API, I would like to be able to see whether a given project requires, prevents, encourages, or allows the squashing of commits from a single Get a single project
API command. With this addition to the API response, users will be able to better tune merge request command-line tools to only set a new merge request to squash if the project itself allows the squashing. Personally, my command-line tool asks a user upon the creation of a new merge request whether they'd like to squash the merge request. However, the tool asks the same question even on projects where squashing the final merge request isn't allowed. Furthermore, if a project requires the squashing of commits, then my tool shouldn't need to ask the user whether to squash or not; it should automatically fill that in for the user. With this suggested addition to the Get a single project
API response, users (including me) will be able to improve their GitLab workflow automation, which companies and individuals continue to use and rely on every day.
Intended users
Pretty much anybody who utilizes the GitLab Projects API will be able to use this feature. This could include Sasha (Software Developer), Devon (DevOps Engineer), Simone (Software Engineer in Test), Priyanka (Platform Engineer), and others.
User experience goal
The user should be able to use the Get a single project
API call to see whether a given project prevents, allows, encourages, or requires the squashing of merge requests. The API should give information that directly correlates to the project's settings as if the user navigated to this Settings page:
Proposal
Perhaps, create a new version of the Projects API that would include the squash commits data as part of the response. I'd even be willing to be a testing subject for the new version on Beta mode. And then, in a blog post (or for my reference, as a comment on this Issue), release the new version of the API.
Further details
No further details. Please contact me if questions or concerns arise.
Permissions and Security
There should be no impact to any members. If a member previously didn't have access to a project, then seeing whether a project allows squashing or not shouldn't be given via the API. If a user previously had access to see merge-related settings from the API, then they should be able to see this information, too.
Documentation
I'm assuming that this change will require changes to the documentation. The documentation here will need to be updated, and perhaps in other places as well, such as here.
Availability & Testing
I don't believe that updating the API or creating a new version allows any risks of downtime or would risk the quality of the API. It could be worth adding additional tests to verify the new API is successful, and continues to present the existing information to users when used. This could probably be accomplished through end-to-end testing, but I'm not 100% sure without seeing the existing test codebase.
What does success look like, and how can we measure that?
The success of this feature can be measured by answering this simple question:
If I use the
Get a single project
API as described here, then will it provide an option to see whether the given project allows, prevents, encourages, or requires the squashing of merge requests?
What is the type of buyer?
I believe this feature belongs in the free tier.
Is this a cross-stage feature?
This feature would loop in the API group/team, and could possible loop in the Projects team or the API permissions team.
Links / references
This Issue is in direct response to the support ticket I created (ticket number 174806).