I am new to Code Commit and know a little about git.
I have root access to the repo
Basically, I want to maintain code Commit branch (master).
I want to implement trigger, (if possible) such as:
All developers need to create their own branch from "master" and when they want to push to "master" branch, a new Pull request gets created.
Not sure if possible (create gating),
when I approve the pull request, it goes to master branch.
I hope I am clear
A Million thanks
There’s no way to add IAM permissions on branches. It’s one of the BIG pains of CodeCommit that makes it hard to implement - it drastically reduce security compared to all the other solutions on the marker
Edit:
CodeCommit now supports branch level permissions. You can read more about it here
https://aws.amazon.com/about-aws/whats-new/2018/05/aws-codecommit-supports-branch-level-permissions/
or here
https://aws.amazon.com/blogs/devops/refining-access-to-branches-in-aws-codecommit/
There is currently no branch level permissions on a repository that would prevent someone from pushing specifically to master, or any other branch.
A number of customers are interested in this feature, your request will help us prioritize our work.
Related
I want my BitBucket instance to trigger the creation of a plan branch, when a pull request is created.
But I want to filter which pull requests trigger such action: the plan branch should be created only if the pull request's target branch matches a particular regular expression.
The Bamboo instance is self-hosted. It is not on the Atlassian's cloud. I don't know if this makes any difference, when it comes to features.
Note: I would like to avoid setting all stage's tasks as conditional, based on the variable repository.pr.target.Branch. As that would make maintaining the pipelines more painful than it already is.
Also, that would result in a successful build in BitBucket for that PR. I'd like the build to not exist at all.
Having conditional stages would make maintenance easier. But Bamboo does not feature conditional stages.
What you're asking is not possible. I've been through the same quest and repository.pr.target.Branch with conditional tasks (or alternatively conditionals in shell script tasks) is the only way to go.
Right now we have few branches in aws code commit one of the repository like master , develop , release and main branches. I don't want any developer commit the code into main branch but i want that branch will be there only because we have code on that. How we will restrict that main branch
You can do so via IAM policy restrictions on the User. Following documents provide the details on the steps required:
https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-conditional-branch.html
https://aws.amazon.com/blogs/devops/refining-access-to-branches-in-aws-codecommit/
Using Codecommit to store the repositories. I have one branches in RepoA and one branch in RepoB. I am trying to sync the changes made in RepoA's branch into RepoB's branch but in an automated way. Is there any way I can use Lambda or codebuild containers to do so?
I don't think so there is any out-of-the-box solution from CodeCommit for this. I also don't think having 2 different repos, one for developer and one for deployment is a good design.
Coming back to answer your question, you can sync the branches in 2 different repos through a script, and call the same from Lambda. However, what you have to take care over here is, are all the parameters to execute this script are well within Lambda's limits?
Assuming the sequence of operation is something like :
Clone repo A.
Checkout branch A.
Add new remote "origin2" as repo B to repo A cloned copy.
Pull from origin2 branch A.
Push to origin2 branch A.
I would say, better to trigger a Container with required script and details/parameters to execute the script.
If you already have any CI setup such as Jenkins/Bamboo, it will be a lot easier.
I am trying to make a code pipeline which will build my branch when I make a pull request to the master branch in AWS. I have many developers working in my organisation and all the developers work on their own branch. I am not very familiar with ccreating lambda function. Hoping for a solution
You can dynamically create pipelines everytime a new pull-request has been created. Look for the CodeCommit Triggers (in the old CodePipeline UI), you need lambda for this.
Basically it works like this: Copy existing pipeline and update the the source branch.
It is not the best, but afaik the only way to do what you want.
I was there and would not recommend it for the following reasons:
I hit this limit of 20 in my region: "Maximum number of pipelines with change detection set to periodically checking for source changes" - but, you definitely want this feature ( https://docs.aws.amazon.com/codepipeline/latest/userguide/limits.html )
The branch-deleted trigger does not work correctly, so you can not delete the created pipeline, when the branch has been merged into master.
I would recommend you to use Github.com if you need a workflow as you described. Sorry for this.
I have recently implemented an approach that uses CodeBuild GitHub webhook support to run initial unit tests and build, and then publish the source repository and built artefacts as a zipped archive to S3.
You can then use the S3 archive as a source in CodePipeline, where you can then transition your PR artefacts and code through Integration testing, Staging deployments etc...
This is quite a powerful pattern, although one trap here is that if you have a lot of pull requests being created at a single time, you can get CodePipeline executions being superseded given only one execution can proceed through a given stage at a time (this is actually a really important property, especially if your integration tests run against shared resources and you don't want multiple instances of your application running data setup/teardown tasks at the same time). To overcome this, I publish an S3 notification to an SQS FIFO queue when CodeBuild publishes the S3 artifact, and then poll the queue, copying each artifact to a different S3 location that triggers CodePipeline, but only if there are are currently no executions waiting to execute after the first CodePipeline source stage.
We can very well have dynamic branching support with the following approach.
One of the limitations in AWS code-pipeline is that we have to specify branch names while creating the pipeline. We can however overcome this issue using the architecture shown below.
flow diagram
Create a Lambda function which takes the GitHub web-hook data as input, using boto3 integrate it with AWS pipeline(pull the pipeline and update), have an API gateway to make the call to the Lambda function as a rest call and at last create a web-hook to the GitHub repository.
External links:
https://aws.amazon.com/quickstart/architecture/git-to-s3-using-webhooks/
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/codepipeline.html
Related thread: Dynamically change branches on AWS CodePipeline
We are a relatively inexperienced development team trying to do things 'the right way'. We are using Github along with AWS and CodeDeploy for multiple PHP based web applications. We are utilising Github's auto-deployment with CodeDeploy when the master branch is updated.
We have two production EC2 web servers in separate AZ's along with a single EC2 staging server.
It currently works as follows:
We write code in a branch, we push to GitHub, we merge into 'master' which then kicks off CodeDeploy to write to our staging server where we can test it. Once we have tested it we then manually kick off CodeDeploy to write to production (with the same commit ID).
The problem is, if testing brings up issues, and we have another branch waiting to be merged and tested, everything becomes backed up?
We are obviously doing something wrong. We are writing to the master branch to utilise GitHub's autodeploy, but I assumed master was only to be written to when it was ready to be deployed?
Can someone please help us and put us straight?
Thanks
Make another branch called 'livecandidate' this branch will have each of the new feature branches merged into it
Each time a feature branch is merged into 'livecandidate' pull 'livecandidate' into your Code Deploy process and install to the test machine.
If the tests pass then merge 'livecandidate' into 'master' and kick off the install to production
If the tests do not pass then unwind the merge into 'livecandidate' (assuming no dependencies on chains of changes etc)
After doing a production install or a un-merge, try the next feature
General idea is to never ever have a broken master
All problems in computer science can be solved by another level of indirection - David Wheeler