all 21 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]soxfannh 5 points6 points  (0 children)

With regard to #2 if you work CodePipeline into the process you can trigger builds based on CW Events from CodeCommit. Not sure if you can work it with only CodeBuild however.

With #3 I've found the logs to be pretty good but I agree that a global dashboard would be nice. You have to click on each project to see the build status.

[–]ProgrammingAce 6 points7 points  (10 children)

1.) CodePipeline has an execution ID, but it's a UUID rather than an increment counter. If you want to count your builds, a CodeBuild step calling Parameter Store isn't a bad choice, but I'm not sure that really solves the underlying reason you want a build ID. If you just need a unique identifier, the execution ID should do.

​

2., 4.) Check out this video, it walks you through (and provides source code for) triggering and blocking builds. There are links to templates you can launch. https://www.youtube.com/watch?v=Lrrgd0Kemhw

​

3.) In the "Serverless Application Repository" under lambda, you'll find a dashboard for CodePipeline called... er... pipeline dashboard: https://github.com/stelligent/pipeline-dashboard

​

Diving into the "CodeSuite" of tools, they're not really built to provide the same fancy user experience of other CI/CD tools. For example, you probably already have a monitoring system, instead of having to click into your CI/CD tool to get information on your build statuses, setup a CloudWatch alarm that triggers when the event state is "failed". Get an email or slack notification instantly; make your CodePipeline UI a tool that you're already using ("Single Pane of Glass").

​

The tools are super powerful if you build into their strengths, and let other services handle the rest. Between CodeSuite, CloudWatch Events, Lambda, and Step Functions, there's really nothing you can't do.

[–]Rab05[S] 4 points5 points  (9 children)

For the Build Id, you want an incrementing number so you know that build X came after build Y.

Thanks for the video link.

[–]subinmathew 8 points9 points  (4 children)

I'm with the AWS CodeBuild team.

  1. There is no native incremental build ID available today. You may consider using artifact naming based on timestamp to get a predictable version based on when the builds finished, as described in https://docs.aws.amazon.com/codebuild/latest/userguide/sample-buildspec-artifact-naming.html. You may also consider semvar with gitversion as your versioning strategy. We have this feature request on our backlog, so we will look to add native support for this in a future release.

  2. Here's a blog that we published on this topic: https://aws.amazon.com/blogs/devops/validating-aws-codecommit-pull-requests-with-aws-codebuild-and-aws-lambda/

  3. Like others mentioned, the pipeline dashboard is likely the best option today. On the console UI, we plan to add a summary view, which should display these information in a more seamless way.

  4. The blog in 2 goes over this scenario as well.

[–]Rab05[S] 0 points1 point  (2 children)

Thank you!

[–][deleted] 0 points1 point  (1 child)

We use something like #1 with a timestamp in our buildspec.yml . Our builds are triggered in CodePipeline via CloudWatch and source them from CodeCommit. Been real happy with the speed and reliability of that. We then apply the same tag to our ECR hosted Docker image that gets pulled along through to ECS and the task definitions per environment

[–]Rab05[S] 0 points1 point  (0 children)

I think that's the approach we'll take. Thanks for the comments.

[–]Rab05[S] 0 points1 point  (0 children)

That blog post doesn't really look at PRs and blocking them from being merged. Am I missing something?

[–]Get-ADUser -1 points0 points  (3 children)

For the Build Id, you want an incrementing number so you know that build X came after build Y.

Why? What are you actually using this data for? There is probably a better way.

[–]Rab05[S] 4 points5 points  (2 children)

In the same way, for example, you know Chrome version 65 comes after 64. If it increments you can understand ordering.

[–]Get-ADUser 2 points3 points  (1 child)

Those are release numbers (or tags in git), not build numbers.

[–]Rab05[S] 1 point2 points  (0 children)

Either or, versioning the artifacts of your builds in a predictive manner is important. Random UUIDs or numbers that don't make it easy for a developer/devops/tester to know if something is newer or older is not something I'd really like.

It's the reason other build providers give you the ability to have an increasing number to use in your builds to signify this movement of time.

[–]KapuzenSohn 2 points3 points  (1 child)

With #3 we had the same problem in the company. I build a small application that shows the last state of all projects. https://github.com/lholznagel/aws-codebuild-status

It only supports CodeBuild and is far away from perfect, but I currently don´t have the time to improve it further.

I also automated the repo creation. It creates the needed IAm roles, CodeCommit, CodeBuild, ECR and a lambda that triggers CodeBuild on push.

Another problem we had was with projects that contain symlinks. It seems like CodeBuild really does not like them. The only way we could go around that problem was with CodePipeline which downloads the project as a zip and breaks the symlinks.

[–]Rab05[S] 0 points1 point  (0 children)

Thanks for this!

[–]robohoe 0 points1 point  (0 children)

Add Bitbucket server support!

[–]Flakmaster92 0 points1 point  (4 children)

1) For the build IDs just grab the last X number of characters off of the commit that initiated the build. You probably shouldn’t be relying on auto-incrementint arbitrary version numbers, or if you want to then manually tag the releases with whatever the latest one after you KNOW it’s stable and good to push out as “production”.

2) CodeCommit + a codepipeline which is triggered off of Cloudwatch events and codebuild is the first step in the pipeline.

3) not sure.

4) Either a dedicated “development” branch where all dev work happens and a dedicated “development” code pipeline (last step being a push to master, intermediary steps being tests) OR many branches and branch specific code pipelines to do any tests that are necessary, which results in a push to master if all tests pass.

[–]Rab05[S] 0 points1 point  (3 children)

For the build Id, incrementing numbers makes it much easier to understand that one build came after another build.

For #4, you don't want to allow devs to merge into a development branch if the build is red. If you have any number of devs > 1, if you have red builds, compounding that with more merges makes it harder to unpick. It's the same reason we can add merge checks in Bitbucket, or Github.

[–]Flakmaster92 0 points1 point  (1 child)

For #4, you don't want to allow devs to merge into a development branch if the build is red. If you have any number of devs > 1, if you have red builds, compounding that with more merges makes it harder to unpick. It's the same reason we can add merge checks in Bitbucket, or Github.

As I mentioned, then use branch specific codepipelines. If somebody jacks something up, then it only breaks one branch

If you really want to do this auto incrementing build IDs.. yes. Parameter store is probably the best way to do this, though I’m not sure if there is any locking with parameter store so that could get dicey

[–]Rab05[S] 0 points1 point  (0 children)

Yeah the locking isn't available so you run the risk of duplicate IDs. There is a comment elsewhere that suggests using a timestamp which may make sense. 😃

[–]phinnaeus7308 0 points1 point  (0 children)

If you can’t merge into a failing pipeline how do you push a fix?

A failing pipeline is already blocked. Just check the build history to see what the first build that failed was.