Prevent CI/CD for release branches for forks

GitLab CI/CD
1

A lot of time is wasted in forks for CI/CD when people rebase their master (or other release branches) and push, since they inherit the CI/CD configurations for those branches.

I tried disabling CI/CD specifically in the master branch for my fork, which worked fine until I wanted to do a merge request from an issue branch created off of master. The MR wants to include that commit disabling CI/CD along with the actual issue fix.

From what I can tell, there’s no way to get gitlab to ignore that commit, which means apparently my entire fork now has to be deleted and regenerated w/o the CI/CD commit for me to do MRs and I’ll be back where I started not being able to exclude the release branches in my fork from wasteful and completely unnecessary CI/CD runs.

Is there some way I can get this to work so my fork doesn’t waste resources (and also then block necessary CI/CD by consuming jobs)?

Thanks

2

We have a working solution for this on the production (upstream) repository’s CI config below. The project lives under a group named “products” and so it will always run the CI pipeline for every commit. Forks live in the user’s namespace/group and so will not run the pipeline (the pipeline is created, but all jobs must be manually triggered).

The piece you may have already found since this question is already a couple months old is the CI_MERGE_REQUEST_TARGET_BRANCH_NAME variable which
allows us to automatically run the pipeline for all merge requests that target the master branch.

Finally, we use the workflow rules to completely disable any pipeline for the master branch on forks. We use the fork-branch-merge model of development and so one should never commit to the master branch on their forks.

.jobs:
  rules:
	- if: '$CI_PROJECT_NAMESPACE == "products" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
	  when: on_success
	- when: manual
	  allow_failure: true

workflow:
  rules:
	- if: '$CI_COMMIT_REF_NAME == "master" && $CI_PROJECT_NAMESPACE != "products"'
	  when: never
	- when: always
	
a-ci-job:
	extends: .jobs
3

Thank you Theodore! Exactly what I was looking for.
Regards,
Quanah

4

I get the “.jobs” and “extends: .jobs” parts, but I’m a little fuzzy on the “workflow” part.

Should I put “workflow” before my “stages”? (Does it matter?)

There’s no “stage: whatever” in “workflow”? I didn’t know you could have a job that wasn’t part of a stage.

I can use $CI_DEFAULT_BRANCH instead of “master” here, right?

Also, why “allow_failure: true” under “when: manual” in “.jobs”?

Sorry, I’m a bit new to GitLab CI. Any enlightenment would be appreciated.

Thanks,
Ed