Using github actions, I would like to create a docker release on every pull request merged to the master.
I accomplished that, however, the SHA1 of the docker image is labeled with the SHA1 of the pull-request branch.
My goal is to be able to match docker images to the repository git log sha1's.
Looks like I need some kind of action hook that only occurs when PR is actually merged/rebased to master.
I didn't find any event like this.
Is there something else I can do ?
If you only want to build docker releases off master, you could set up to trigger the workflow on push to master (which is also triggered on PRs being merged/rebased into master). Your workflow file would then begin with:
on:
push:
branches:
- master
# rest of your workflow jobs
Related
I've two Azure DevOps CI pipelines
DataPipeline\Windows - Build
DataPipeline\TestPipeline
The second pipeline is a pipeline resource trigger. I've used this doc as a reference.
When a pull request is created (e.g. with dev branch as source branch and main branch as target branch, not merged yet) both these pipelines are triggered (by default configuration). The second pipeline may pick up old artefacts (this is a different part altogether). A second run for pipeline DataPipeline\TestPipeline is triggered automatically as soon as DataPipeline\Windows - Build completes for a commit in the dev branch. Is this possible? I've specified the branch name in the resources trigger. Is something wrong with the YAML configuration?
My expected behaviour is when a pull request is created for branch name: xyz (not main), DataPipeline\TestPipeline shouldn't be triggered again after DataPipeline\Windows - Build completes.
DataPipeline\TestPipeline.yml
trigger: none
resources:
pipelines:
- pipeline: DataPipeline
source: 'DataPipeline\Windows - Build'
branch: main
trigger:
branches:
include:
- main
name: TestPipeline_$(variable)
jobs:
// template based job
I'll do my best to explain my problem.
In standard practice, I have an Azure Devops pipeline that creates a Terraform payload, invokes Terraform API, and lets Terraform do its deployment based off the payload. I do this by "Build Validation" - whenever something is PR'd into my branch, the pipeline runs to make sure I'm deploying proper Terraform infrastructure, and in the process, deploys said resources if the pipeline runs succeeds.
Meaning, the current workflow is:
Incoming PR -> Build Valdiation starts -> Pipeline runs -> Pipeline run succeeds -> Accept the PR and do a merge
However, the team I'm working with now wants the following:
Incoming PR -> Accept the PR and do a merge -> Build Validation starts -> Pipeline runs -> Pipeline run succeeds
Basically, they want to actually review the incoming PR, accept and merge it, and ONLY THEN have the actual pipeline/deployment process start. And I'm not sure how to perform this step. Looking into CI triggers, I couldn't find what I need. Any help appreciated.
As you said, you need to use the CI trigger.
Assuming they merge is to master branch and you want to run the pipeline after the merge add to the yaml the trigger:
trigger:
- master
I was looking for the same earlier. Unfortunately, azure does not offer anything like this.
I think the easiest solution is to set up a protected intermediate branch. E.g. pre-master and then make pr's towards this one and disallow humanly issued master merges. Then, as proposed by others, set a trigger on pre-merge after which you then commit to the master.
You can then complete the ping-pong by defining a trigger on master that aligns pre-master afterwards.
I have three K8s clusters; staging, sandbox, and production. I would like to:
Trigger a pipeline to build and deploy an image to staging, if a merge request to master is created
Upon a successful deploy of staging, I would like the branch to be merged into master
I would like to use the same image I already built in the build job before the staging deploy, to be used to deploy to sandbox and production
Something like this:
build:
... (stuff that builds and pushes "$CI_REGISTRY_IMAGE:$IMAGE_TAG")
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
staging:
...
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
sandbox:
...
?
production:
...
?
What I can't figure out is how to both have a successful MR at the end of the staging job and thereby have the pipeline merge the branch into master, and also then pass down whatever $CI_REGISTRY_IMAGE:$IMAGE_TAG was to continue with the jobs for the sandbox and production deploys.
Trigger a pipeline to build and deploy an image to staging, if a merge
request to master is created
For first you can create rules like
only:
- merge_requests
except:
variables:
- $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "master"
You can run the curl command or hit API to approve the MR
https://gitlab.example.com/api/v4/projects/:id/merge_requests/:merge_request_iid/approve
Reference : https://stackoverflow.com/a/58036578/5525824
Document: https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr
I would like to use the same image I already built in the build job
before the staging deploy, to be used to deploy to sandbox and
production
You can use the TAG_NAME: $CI_COMMIT_REF_NAME passing across the stages as Environment variable
You are making it really complicated ideally you can use the TAG and make it easy to manage and deploy using the CI.
Merge when MR gets merged and create TAG and build docker images with TAG name, deploy that same TAG across environment simple.
Question
Is there some way to set per-label permissions in GitHub?
Background / Context
I'm working on CI/CD pipelines for a project, the code for which is hosted under a GitHub Enterprise account, using GitHub Actions.
I'm hoping to control the process through labels on a PR. The manual key points of this process are outlined below:
When someone creates a PR to master, the CI pipeline kicks off and creates an image and pushes it to AWS ECR. NB: A lot of other stuff also happens here; e.g. linting, vulnerability scanning, automated testing, etc; but needs no manual involvement. If things fail the PR is rejected & no image is pushed to ECR.
The QA team apply the label ApprovedForUAT which checks there are no competing labels (e.g. or ApprovedForUAT or DeployedToUAT labeled PRs; if there are it fails until this is corrected), then kicks off the CD pipeline to deploy that image to our UAT environment.
Once the image is successfully deployed to UAT, the CD pipeline removes the ApprovedForUAT label and applies the DeployedToUAT label.
Once manual testing is completed, the QA team apply the label PassedUAT or FailedUAT as appropriate; a pipeline checks that the label DeployedToUAT had been present to ensure this status update is valid. If things fail, the image is removed from ECR.
The release manager then applies the label ApprovedForProd (can only be applied if the label PassedUAT is already present), causing the CD pipeline to run at a predetermined time to update production with the new image, and removes the ApprovedForProd label, and closes the pull request as complete.
Desired Permissions
The following roles should only be able to apply the given workflow labels:
QA Team
ApprovedForUAT
PassedUAT
FailedUAT
Release Manager
ApprovedForProd
GitHub Actions
DeployedToUAT
Our current pipeline deploys a new instance of our app for every new branch created on azure repos, just like review apps on Heroku or Gitlab.
The creation part went smooth, but I'm not sure what to do with the orphaned resources and deployment once the branch is deleted (hopefully by an accepted pr).
Deleting them manually is not an option and there I can't find a trigger in the documentation for branch deletes.
The only option I can see right now is to create a scheduled job for the master branch(since it always exists) with a bash script that compares the list of deployed apps and existing branches and cleans up the resources.
Is it my only option, or is there another way without a fairly complex, all-access, destroy machine?
So did a little investigation dumping all enviroment vars to Notepad++ and using the compare plugin i realized that when a PR is accepted 2 env variables are different.
First of the initial variable "BUILD_REASON" during a push is set to "IndividualCI", but with the "BUILD_SOURCEBRANCH" set to "refs/heads/feature/******". When a pull request is initiated the "BUILD_REASON" changes to "pullrequest" and "BUILD_SOURCEBRANCH" to "refs/pull/***".
Finally when a PR is accepted the variables change to "BUILD_REASON" = "IndividualCI" and "BUILD_SOURCEBRANCH" = "refs/heads/master".
Once i figured out this i could create stage that have the following conditions:
- stage: CleanUp
displayName: 'CleanUp'
dependsOn: Test
condition: and(succeeded(), in(variables['Build.Reason'], 'IndividualCI'),in(variables['Build.SourceBranchName'], 'master'))
The above stage will be triggered when PR is accepted so to cleanup resources created during PR :-) havnt tested all the way but seems to do the job.
You can use a webhook in Azure DevOps to watch the pull request for updates. When the pull request status changes to completed, fire a script that deletes the resources used for the PR.