I have created a build pipeline.
have master, develop and feature/* branches in my Azure repo.
I have created a branch policy to require a build for feature/* branches.
How do I trigger an automatic build on pull request? Or even how do I queue a build manually on the pull request?
I can't see such option on my pull request screen in DevOps.
As far as I know the build policy should appear above Work Items on the right hand side. My policy does not appear there and I have no even a possibility to trigger the build manually.
I am not sure what I am doing wrong? Or what is missing?
The screenshot you provided shows that the PR is for the develop branch. If you want a PR for develop to trigger a build, then set a policy on the develop branch.
Branch policies apply to the target branch, not the source branch.
Related
Background
I want to create the following CI/CD flow in AWS and Github, for a react app using Amplify:
A single main branch, with short-lived feature branches and PRs into main.
Each PR triggers its own test environment in Amplify, with its own temporary subdomain, which gets torn down when the PR is merged, as described here.
Merging into main does not automatically trigger a deploy to production.
Instead, there is a separate mechanism (a web page, or amplify command, or even triggers based on git tags) for manually selecting a commit from main to deploy to production.
Questions
It's not clear to me if...
Support for this flow is already built into Amplify (based on the docs I've read, I think the answer is "no", but I'm not sure).
Support for this flow is already built into AWS CodePipeline, or if it can be configured there.
There is another AWS tool that solves this.
I'm looking for answers to those questions, or specific references in the docs which address them.
The answers for Amplify are Yes, Yes, Yes, Partially.
(1) A single main branch, with short-lived feature branches and PRs into main.
Yes. Feature branch deploys. Can define which branch patterns, such as feature*/, you wish to auto-deploy.
(2) Each PR triggers its own test environment in Amplify, with its own temporary subdomain,
Yes. Web Previews for PRs. "A web preview deploys every pull request made to your GitHub repository to a unique preview URL which is completely different from the URL your main site uses."
(3) Merging into main does not automatically trigger a deploy to production.
Yes. Disable automatic builds on main.
(4) Instead, there is a separate mechanism ... for manually selecting a commit from main to deploy to production.
Partially (HEAD only?). Call the StartJob API to manually trigger a build from, say, Lambda. The job type RELEASE starts a new job with the latest change from the specified branch. I am not sure if jobType: MANUAL with a commitId starts a job from an arbitrary commit hash.
Another workaround for 3+4 is to skip the build for an arbitrary commit. Amplify will skip building if [skip-cd] appears at the end of a commit message.
In my experience, I don't think there is any easy way to meet your requirement.
If you are using Gitlab, you can try Gitlab Review Apps to achieve that (I tried before with some scripts)
Support for this flow is already built into Amplify (based on the docs I've read, I think the answer is "no", but I'm not sure).
Check below links, if this help:
https://www.youtube.com/watch?v=QV2WS535nyI
https://dev.to/rajandmr/deploying-react-app-using-aws-amplify-with-ci-cd-pipeline-setup-3lid
Support for this flow is already built into AWS CodePipeline, or if it can be configured there.
For this, you need to create a full your own pipeline. Yes, you can configure your pipeline.
There is another AWS tool that solves this.
If you are okay with Jenkins, then Jenkins will help you to achieve this.
You can deploy Jenkins docker in AWS EC2 and create your pipeline. You can also use the parameterised option for selecting your environment and git branch.
I'm using an AWS Lambda function to kick off a build in AWS CodeBuild when a Pull Request is created or updated in AWS CodeComimit, which is working well.
However, I'd like to be able to prevent the merging of that Pull Request in to the master branch of the repository, until the latest build for that PR has completed successfully.
Does anyone know if there's a way that can be done in AWS? E.g. so that the Merge button is disabled or not available, like when not enough approvers have been obtained?
I was looking into this myself and from what I understand, it is currently not possible to directly create this rule, but I think it should be doable with a different approach.
Instead of requiring a custom rule that disables merging (which doesn't exist today), you could make it so that the PR requires review from a specific IAM user. With that, you could probably use a fixed "build" user, and fire an automatic approval request for the PR once the build finishes successfully. This will in turn "approve" that rule in the PR and allow it to be merged after the build succeeds.
Since approval can be done via the CLI interface, I'm sure it should also be possible via API. For example, you could use this API to automatically mark any given PR as approved by the calling user, then ensure the service that is calling it is the same user registered in the "build" approval template.
Besides the HTTP WebApi, there are also other ways to call into these CodeCommit actions, like the AWS SDK library (C# example: https://www.nuget.org/packages/AWSSDK.CodeCommit/).
I am not able to find a way to stop the auto triggering of the pipeline whenever I push code to bitbucket.
My assumption is that you want more control over when your pipeline does certain things.
Rather than achieving this through stopping the pipeline from getting triggered, I'd recommend using either stage transitions or manual approvals to achieve this control inside the pipeline.
Stage transitions are better when you want to "turn off" a pipeline and have the latest thing run through when you turn it back on.
Manual approvals are better when you want the version to be locked while waiting for approval so you can run tests without worrying that the version will change.
You mentioned in your comment that you wanted to only run your pipeline at certain times, so a way you could do that is to enable and disable the stage transition after source on a schedule.
https://docs.aws.amazon.com/codepipeline/latest/userguide/transitions.html
https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html
You can disable DetectChanges parameter on your Source action as explained here. Extract with the relevant context:
DetectChanges: Controls automatically starting your pipeline when a new commit is made on the configured repository and branch. If unspecified, the default value is true, and the field does not display by default.
This works on Bitbucket, GitHub, and GitHub Enterprise Server actions. I have a CloudFormation template configured with this option and works. Not sure about the same option on AWS console, because I saw that some configurations are only available from CloudFormation or aws cli. As you can read "this field does not display by default".
My team has been running into issues with our CodePipeline where features were pushed out into production when they shouldn't have been due to our Docker image patching. A little background on our architecture: Our pipeline has two sources, one for the source code and one for the Docker image builder. Docker builds via CodeBuild and is deployed to dev, test, and then prod environments with manual approval steps in between.
Our Docker image receives monthly patching which triggers the pipeline to execute and is what caused the features to be pushed out. We redesigned our git branching strategy so that our master branch will only contain stable releases, but I could still see this issue potentially occurring again if a specific release date is specified. Is there a way to push out the image patching without pushing out the latest commit?
Can CodePipeline Use a Specific Commit
This is an often requested feature but unfortunately CodePipeline will always bring the latest commit from the selected branch in the Source action.
CodePipeline tied to a single git branch is more of a feature of CodePipeline as the design is more inclined towards Trunk based development [0]. Also, as per the designers of this service, CodePipeline is designed for post-merge/release validation. That is, once your change is ready to be released to production and is merged into your master/main branch, CodePipeline takes over and automatically tests and releases the final merged set of changes. CodePipeline has a lot of features like stage locking, superseding versions, etc. which don't work well for the case where you want to test a change in isolation before it's merged (e.g. feature branch testing or pull request testing.) Therefore there currently isn't a recommended way to do this in CodePipeline.
[0] https://trunkbaseddevelopment.com/
Having said that, there is a way to hack this with S3 Source action in pipeline instead of GitHub/CodeCommit source action. Essentially your pipeline's S3 source action is tied to S3 bucket/key. You can then upload a zip of any specific commit to this S3 bucket/key and trigger the pipeline.
I created a new build pipeline for my latest project at Azure DevOps Server 2019. I use the provided Git repository with branch policies to protect master and develop from changes without pull request.
Each pull request requires a successful build.Unfortunately, Azure DevOps Server always creates a new build for each pull request (highlighted red in the image below).
I don’t need that build. The last build status of the assigned branch is enough.Is there any way to disable the pull request build and use the last branch status instead?
No, the new build is required, because it should verify whether the build works fine after migrating the code from source branch to target branch (master/develop).
Regarding the build for assigned branch, it just verifies the current branch instead of the migrated code. (maybe there are some bugs/issues after migrating code)