Allow fetching extra git refs in CI when shallow cloning is enabled
Problem to solve
When shallow cloning is enabled, CI pipelines will default to git fetch
with a depth of 50
(since https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28919). It's desirable to be able to specify some git refs that should always be fetched for some workflows; for example, to be able to compare changes introduced in a new branch against the default branch (usually master
). To do this currently, one has to disable shallow cloning altogether.
Intended users
Devon (DevOps Engineer). Users who configure CI/CD settings.
Further details
Copied over from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28919#note_196272527:
When using commitlint to lint commits and on a branch (MR), one would use something like this to lint the commits added in the branch:
npx commitlint --from master --to feat/some-feature-branch
Currently for this to work, one has to disable shallow cloning but with this feature proposal, one could configure that only the master
branch is fetched in addition to feat/some-feature-branch
.
Proposal
Add a new project-level CI/CD setting to allow a user ton configure one or more refs that should always be fetched. Ideally, this would:
- be a multiselect field where one could select some refs from existing git refs
- allow the user configure refs that don't yet exist
- allow the user to add a regex pattern to match multiple (most-likely non-existent) refs
- not have a value by default, to maintain backwards compatibility
For branches, this field would function similarly as the ["protected branches" field])(https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring-protected-branches).
If other Git CI/CD settings are updated to be group-level settings, then this would also make sense to have there.
Permissions and Security
Permissions: the current permissions around project-level settings, in this case CI/CD settings.
Security: the input should be carefully validated since it will presumably eventually be supplied to a git fetch
command run by a CI runner. Best to limit inputs to existing git refs if this is a concern.
Documentation
Documentation for the new setting will be required, describing the functionality as outlined in "Proposal" above. By that proposal, the documentation would match the documentation for protected branches.
Testing
This feature does pose some risk since user input would be used as arguments to a shell command. The input validation should be well tested for edge cases and potentially dangerous inputs.
What does success look like, and how can we measure that?
A user can configure a CI pipeline to only fetch changes from the current up to a certain depth and one or more other refs in addition.