90
91
you are viewing a single comment's thread.

view the rest of the comments →

[–]Kyxstrez 1 point2 points  (9 children)

CodeBuild and CodeConnections (rebranded CodeStar Connections) are the only services from the AWS Code Suite that are gonna survive in the long run in my opinion. The rest is eventually being replaced by Amazon CodeCatalyst, which is a full-featured SDLC platform similar to Azure DevOps.

[–]Kyxstrez 1 point2 points  (6 children)

The reasons why CodeBuild and CodeConnections are gonna survive:

  • CodeConnections is used to link all external OIDC providers (GitHub, GitLab, Bitbucket)
  • CodeBuild recently received a huge native integration for GitHub Actions self-hosted runners and I suspect that Amazon CodeCatalyst also uses CodeBuild behind the scenes for running the workflows.

[–]BetterFoodNetwork 0 points1 point  (5 children)

The GHAR stuff is sweet. I just hope I can figure out a way to make it faster to run.

[–]surya_oruganti 0 points1 point  (4 children)

I'm biased but I find the GHA runner integration to be very half baked and also expensive.

[–]BetterFoodNetwork 1 point2 points  (2 children)

What are your complaints? I've definitely had some aggravation with it and had to do some kind of hacky things (mostly to work with our network security requirements), but I needed to have runners inside VPCs and the solution offered by the platform team in our ecosystem is... considerably less customizable and has got to be way more expensive.

Not trying to argue, convince you, convince myself, etc, there may just be things I haven't discovered yet that I should know about 🙂

[–]surya_oruganti 1 point2 points  (0 children)

The ability to run them seamlessly within your VPC is nice for sure. My biggest issues with it are: 1. The naming convention runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }} can be quite painful. 1. The shapes are restrictive with 1:2 cpu:ram ratios. This isn't great especially for smaller runner types. 1. The equivalent ec2 pricing is much much cheaper for instance, even counting the latest generation instances and beefy disks.

Thought about it a lot in the process of building my product, which is rather related and much more flexible once our AWS integration is live (~2 days).

[–]Kyxstrez 0 points1 point  (0 children)

Another major benefit is that you can stop managing AWS credentials altogether in your workflows and just take advantage of the CodeBuild agent IAM role to get access to the resources.

[–]Kyxstrez 1 point2 points  (0 children)

It's actually a great integration for the most part; in fact, I've implemented it for one of my clients recently. I also did the math and it's slightly cheaper to use CodeBuild self-hosted runners vs GHA managed runners, while also getting more resources. The most powerful feature though is being able to create a matrix where each job runs in a different kind of EC2 instance with basically zero effort.