FAQ | This is a LIVE service | Changelog

Skip to content
Snippets Groups Projects

feat(terraform-pipeline): disable for non MR/push pipelines

Closed Dr Rich Wareham requested to merge issue-67-terraform-job-rules into master
1 unresolved thread

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • assigned to @rjw57

  • added 1 commit

    • 1c13505b - feat(terraform-pipeline): disable for non MR/push pipelines

    Compare with previous version

  • Ryan Kowalewski requested review from @rk725

    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/or pipeline) which we do do currently, or execute deployment pipelines via Client SDKs such as python-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 via scheduled 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 Wareham
    • 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?

      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 Wareham
    • I 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? Our terraform-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? Our terraform-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.

    • Please register or sign in to reply
  • mentioned in issue #68 (closed)

  • I'm closing this MR off in favour of the work in #68 (closed) which I am starting now :-).

  • Ryan Kowalewski mentioned in merge request !81 (merged)

    mentioned in merge request !81 (merged)

Please register or sign in to reply
Loading