I'm trying to create CI that does the following:
Run terraform plan -out=plan.out to generate a Terraform plan.
After looking at the Terraform plan output in Github actions, I can manually run another job or workflow that calls terraform apply plan.out with the previously generated plan. I want to manually run this automation after the other automation has successfully run, dependent on the previous automation's success, using an artifact from the previous automation.
I've looked online for some examples of this but all the examples of this I can find just run terraform apply without actually allowing someone to verify the plan output.
Is this something that's possible to do in Github Actions?
This can be done using protected environments' required reviewers: https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#required-reviewers
What you would do is setup an environment e.g. production and add yourself as reviewer.
In your workflow, you would then add the environments like so:
jobs:
plan:
steps:
- run: terraform plan
apply:
environment: production
steps:
- run: terraform apply
This means that as soon as the workflow reaches the job apply, it is going to stop and you'll need to manually click a button to approve.
My solution ended up being the following:
When the PR is approved and merged, a Terraform plan is created and pushed to an S3 bucket with the commit hash in the path. Then when the apply workflow is triggered via workflow dispatch it looks for a plan for the commit hash of the code it's running and applies it.
Using pull requests as suggested wasn't the right solution for me because of the following:
How do you know that the plan that was run for the pull request was run with the latest changes on the base branch? The plan could be invalid in this case. The way I solved this was by having the plan workflow run on push of a specific branch that corresponds to the environment being Terraformed. This way the plan is always generated for the state the Terraform says the specific environment should be in.
How do you know that an apply is applying the exact plan that was generated for the pull request? All the examples I saw actually ended up re-running the plan in the apply workflow, which breaks the intended use of Terraform plans. The way I solved this was by having the apply workflow look for a specific commit hash in cloud storage.
Related
I have a ADO git repo with a YAML-based build pipeline that builds a docker image, runs some tests using Docker Compose, and then pushes the image and a helm chart to an ACR.
I'd like the have the build/test part run on PRs too. I have created a second pipeline that's just the first half of the normal build, and assigned it as a Build Validation pipeline for a branch.
However, I don't seem to be able to get the triggers right. If I have trigger: none in the test pipeline, it never triggers. If I have branch names, it is also run on merge alongside the normal build pipeline. How is this supposed to work? The docs define all the individual parts, but not really how they are expected to interact!
Am I supposed to have a multistage pipeline and use that somehow for the validation? (it's just 4 Steps in one Job in one Stage currently).
I am hoping to avoid building the same image too many times, or storing untested images anywhere outside the build agent.
I make it work with the following configuration:
In my YAML pipeline, I set the trigger: none.
In branch policies of a branch, I create a build validation with automatic trigger:
Then I create a pull request to that branch, and the pipeline runs automatically:
There are two possible mistakes:
The "Manual" trigger is selected in build validation, so that the pipeline needs to be run manually rather than triggered automatically.
The branch with branch policy set should be the same branch as the target branch of pull request.
I have an Azure DevOps pipeline that runs our full test suite. It is slow, so we only want to run it on pull requests when the tests are changed or a test run is explicitly requested with a GitHub comment. I have tried the following configuration below.
pr:
paths:
include:
- tests/integration/*
The problem that I am experiencing is that commenting on the pull request with /azp run tests does not work when path filters are used. The bot replies back with "Azure Pipelines could not run because the pipeline triggers exclude this branch/path."
Does anyone know if what I am trying to accomplish is possible, and how to configure it?
I understand that I could create multiple pipelines with different triggers, but I am hoping to get this to work with a single pipeline.
Following your steps, I can reproduce the followig issue.
After reviewing this doc: Comment triggers, we can see the following prerequisites.
Testing this we find that only pushes to branches that are explicitly configured to be included on Pull request validation will trigger a pipeline using comment like /azp run test, as below.
I have repository on local GitLab server of my organization and want to trigger build pipeline that then will trigger release pipeline and publish to staging/production VMs.
I've read a lot of articles at microsoft docs, SO and tons of blogs that you can trigger pipeline by tags providing branch filter like refs/tags/v*. YAML configuration has additional section special for tags, however YAML is not supported for git repos that are connected as "Other git".
And that tag trigger just never works. After I set up trigger UI shows me just "v*", so it understands that refs/tags has special meaning. I can run pipeline manually specifying exact tag, like refs/tags/v1.0-test, and it works. But never launches automatically. Branch triggers work without problems.
What I've already tried:
set include filter for refs/tags/v* - doesn't work
set include filter for refs/tags/exacttagname - doesn't work
set include filter for refs/tags/v* and another one for master - triggers only for master
set include filter for refs/tags/v*, for * and exclude filters for refs/heads/* and refs/remotes/* - doesn't work
I tried pushing commit, then pushing tag. Tried pushing commit and tag in one requiest with git push ---follow-tags. Tried pushing tags for older commits. Nothing of that works.
This issue about the same problem was resolved on azure side previous summer, however all comments where about GitHub integrations. So maybe it's still broken for "other git" or smth else.
Any help?
I tested and got the same result, tags triggers for other git doesnot work. You can submit a feature request(click suggest a feature and choose Azure devops) for supporting tag triggers for gitlab repo to Micrsoft Development team. Please check this thread for example.
As workaround you can use multiple agent jobs to achieve above currently.
You can add another agent job before your original agent job to run a script task, And add dependency on it in your original agent job. The script task will check if there is tag associated to the current commit. If the tag exits, the script task will pass, and the following agent job will run. Or the script task fails and the following agent job will be skipped.
The detailed steps is as below:
add a agent job with a single powershell task. Check below screenshot.
Run below inline scripts in the powershell task to check the tags
$tags = git describe --tags $(Build.SourceVersion)
if($($tags) -notmatch 'v.'){exit 1} #fail the task if the tag doesnot match v*
In the original agent job, add dependencies to above agent job.
Go to Triggers tab and filter all branches.
We often want to test the first part of our release pipeline using a code from the branch. While I can easily trigger the build from any branch, not so with the release pipeline - I have no idea how to trigger it from anything else other than the branch specified in it.
So far my solution was to temporary clone the pipeline, redirect to another branch and use it while testing. Then delete it.
But I wonder if there is a better way. We use TFS 2018 (on-premises), so no YAML to show here.
This is how our pipeline looks like:
When I click the Source I get:
And the Continuous Deployment Trigger on the Source:
Now clicking the Build Artifact:
And the CD trigger:
The four smoketest5x are the same. They have two tasks (a ps1 script and to publish the test results) and their triggers are:
Pre-Deployment:
Post-Deployment:
Finally, the Production stage. Its pre-deployment trigger is the most interesting:
And there is manual approval.
It does not seem possible to provide the branch at release creation time, but maybe I am missing something here?
You can't specify a branch at release time. If you need to do that, create a build pipeline that publishes an artifact, then release a build. You can choose builds versions at deployment time.
My team has multiple Concourse pipelines and as we refactor tasks, we've realized the need to test our actual pipelines.
We already test our tasks by using environment variables enabling task scripts to be run locally, but the pipeline yaml is another matter.
What is the best way to accomplish testing of the pipeline itself?
You can use the Concourse Pipeline Resource to monitor the git repository where you keep your pipeline config. Whenever the pipeline resource detects a change, it will automatically run a fly set-pipeline to update the config in your running Concourse installation. From there, it's easy to script tests against the updated pipeline that is now running in your Concourse installation.
fly validate-pipeline is pretty useful, running that against pipelines before merging has caught a few bugs in "obviously correct" changes for me.
If you want to test the whole pipeline before merging you need to make sure that the data it's using is static and working (no sense in failing the pipeline if it's the repo that's broken), and that there are no side effects (like notifications) shared between the 'real pipeline' and the 'test pipeline'. I suspect that as long as you're careful with the restrictions, you could make it work, but it would have to be designed in the context of your existing pipelines and infrastructure.