<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> Currently, the Projects API has a beautiful way to `Get a single project`, as described [here](https://docs.gitlab.com/ee/api/projects.html#get-single-project). 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 <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> 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 <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) --> 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 <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> The user should be able to use the [`Get a single project` API](https://docs.gitlab.com/ee/api/projects.html#get-single-project) 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 <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> 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 <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> No further details. Please contact me if questions or concerns arise. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members --> 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 <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> I'm assuming that this change will require changes to the documentation. The documentation [here](https://docs.gitlab.com/ee/api/projects.html#get-single-project) will need to be updated, and perhaps in other places as well, such as [here](https://docs.gitlab.com/ee/api/). ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> 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? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. Create tracking issue using the the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> 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](https://docs.gitlab.com/ee/api/projects.html#get-single-project), 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? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> I believe this feature belongs in the free tier. ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> This feature would loop in the API group/team, and could possible loop in the Projects team or the API permissions team. ### Links / references <!-- Label reminders - you should have one of each of the following labels if you can figure out the correct ones --> This Issue is in direct response to the support ticket I created (ticket number 174806).