We have the following idea / use case:
- heavy job (system end-2-end tests) that MAY take >10 mins
Our general requirements are:
- MUST NOT run this job on every commit
- MUST allow developers to manually run the job if necessary
- MAY auto-run the job on MERGE
- MUST allow the job to be triggered by schedule (nightly)
So I gravitated to this:
And then for the nightly:
For requirement (3) we may or may not do this.
So to the question - if we define a job that is both MANUAL as well as “only on schedule”, what is the theoretical outcome here?
I’m not sure how you integrate CI with the existing branches, but you’d want to split manual job and schedule job, somethings like following
- sleep 600s
Thanks @shinya, that is precisely what I was wondering about, and you have clarified. Any suggestion on improving the documentation? I could submit a PR easily. Was thinking to add clarification to the above-mentioned sections in terms of their interactions with one another (in fact they are mutually exclusive).
Off the top of my head, https://docs.gitlab.com/ee/ci/examples/ would be a good place.
Updating this despite the age since it comes up in the top 10 on Google when searching for how to have a job trigger both manually and scheduled. It seems the latest advice is here: Choose when to run jobs | GitLab. Basically it looks like this:
script: echo "Hello, Rules!"
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_PIPELINE_SOURCE == "schedule"
In my case I changed “merge_request_event” to “push” as the former was resulting in “detached” pipelines that wouldn’t run the other non-manual jobs.