feat(terraform-pipeline): disable for non MR/push pipelines
Add rules which disable the jobs created by terraform-pipeline.yml is the pipeline is not a MR or push-triggered one. This means that we don't risk adding extra jobs to a scheduled pipeline by mistake.
Closes #67 (closed)
Merge request reports
Activity
assigned to @rjw57
added 1 commit
- 1c13505b - feat(terraform-pipeline): disable for non MR/push pipelines
requested review from @rk725
@rjw57 on further thought I'm not sure I agree this is a bug after all, and I'm concerned that the following is too restrictive.
rules: - if: '$CI_PIPELINE_SOURCE != "merge_request_event" && $CI_PIPELINE_SOURCE != "push"' when: never
The full list of acceptable values for the
CI_PIPELINE_SOURCE
variable is:- push
- web
- schedule
- api
- external
- chat
- webide
- merge_request_event
- external_pull_request_event
- parent_pipeline
- trigger
- pipeline
If we merge this MR won't we be removing the ability to run an adhoc deployment via the web ui (
web
), trigger the deployment repo pipeline from the webapp repo (trigger
and/orpipeline
) which we do do currently, or execute deployment pipelines via Client SDKs such aspython-gitlab
(api
). All of which I believe are valid use-cases. Also, I have a valid use-case in digital admissions to run Terraform deployments viascheduled
pipelines which this MR would block, no?With this in mind, I wonder if it is actually better to leave the defaults as they are and just override the rules in your particular jobs as required?
If I'm missing something here please let me know!
I suppose the question is "when should the jobs always be created"? As I read the docs, it suggests to me that
a) test jobs should run in MRs pipelines or commit pipelines when MRs are not open. Specifically "The default workflow is that as soon as a commit is made or merge request is opened the test stage jobs start running. For merge requests, the various terraform test jobs will run for both the original commit and the post-merge commit."
b) plan jobs only run in MR or commit pipelines. Specifically "When commits are pushed to an open merge request, or a commit is merged to the default branch, a Terraform plan is generated for each of the development, staging, and production workspaces."
c) apply jobs only run for commit pipelines to the default branch. Specifically "The Terraform apply jobs only run when commits are merged to the default branch."
So if the intended behaviour is "jobs always run for pipelines on the default branch, irrespective of source" then I'm OK with that being documented clearly and maybe adding a suggeted workaround to disable jobs? Maybe a global
TERRAFORM_PIPELINE_DISABLED
variable too which can be used to disable all jobs so that the ones wanted can be re-enabled?Edited by Dr Rich WarehamMaybe a global
TERRAFORM_PIPELINE_DISABLED
variable too which can be used to disable all jobs so that the ones wanted can be re-enabled?Being able to set
TERRAFORM_PIPELINE_DISABLED
would make the scheduled job configuration a bit more robust to new terraform jobs being added to the template. See https://gitlab.developers.cam.ac.uk/uis/devops/infra/entra-app-factory/-/blob/eefe0d7a459ce6a0273a66b4d6ad4fc80f8eecb4/.gitlab/scheduled.gitlab-ci.yml for the current work-around.Edited by Dr Rich WarehamI take your point that the docs are perhaps a bit misleading at the moment. I think the default workflow section is fine but I should reword the terraform plan and terraform apply sections to be clear that the intended defaults of this template are that "jobs always run for pipelines on the default branch, irrespective of source". I've raised #68 (closed) for this.
Regarding a global variable to disable all jobs, I wonder if we should instead separate the hidden
.terraform-plan
and.terraform-apply
jobs into their own "base" template, similar to how the AutoDevOps templates do this? Ourterraform-pipeline.yml
template could then import the "base" template and use the hidden jobs to configure our standard environment jobs. In your case you could just include the "base" template and build your custom pipeline as required? Thoughts?I wonder if we should instead separate the hidden
.terraform-plan
and.terraform-apply
jobs into their own "base" template, similar to how the AutoDevOps templates do this? Ourterraform-pipeline.yml
template could then import the "base" template and use the hidden jobs to configure our standard environment jobs. In your case you could just include the "base" template and build your custom pipeline as required? Thoughts?This sounds perfect.
mentioned in issue #68 (closed)
I'm closing this MR off in favour of the work in #68 (closed) which I am starting now :-).
mentioned in merge request !81 (merged)