Live data from Hacker News

AWS CodeBuild – Build and test code with continuous scaling

aws.amazon.com

21–30 of 46 posts

Re: AWS CodeBuild – Build and test code with continuous scaling

#21
When I saw this I got super excited because I thought it was going to be "per-minute low-latency distcc hosts" which was probably set up by having a ton of common toolchains ready to go at all times, and my big questions were "did they bother to support MinGW (easy)" and "do they have a reasonable story for iOS (though I can't imagine they have armv6 working right)", but while they got my hopes up when they said one could even upload custom toolchains I realized that didn't make much sense and a few paragraphs later I got the disappointing news that this is just some extremely thin wrapper over ECS that is limited to doing builds on single computers which max out at 8 vCPU (why?!). I mean, I guess this makes CI slightly more accessible to some people, but it isn't anything terribly exciting and is mostly going to help people with extremely small projects: this isn't going to scale up to the kinds of builds where you'd expect a service billing itself on scalability to be most valuable.

...Except for this part: CloudBuild has per-minute billing!! This is one of the major complaints people have about EC2 (and all the services Amazon builds over it), and is one of the major downsides of using it over Google's Compute Engine. If you have any kind of task that can possibly be thought of as a "build"--one which can be expressed as a container of software configured to access some external asset as input and which generates a concrete output "artifact" (and maybe even not, right? to support some silly things people do in their builds like "check out code from npm", you likely get network access, and your build output could always be an empty file)--this now seems like a depressingly hilarious way to trick Amazon's infrastructure into giving you per-minute billing for random tasks which take less than 20 minutes to run (important limit, as they are charging a 3x overhead vs the on demand price for an equivalent instance: for 8 vCPU / 15 GB instance, a c4.2xlarge costs $0.419 per hour and a build.general1.large costs $.02 per minute, which would be $1.20 per hour).

In other words: I will argue that this service really can and maybe should just be looked at as a different pricing model for ECS, to support any "small" task (not just building code): if it takes less than 20 minutes and doesn't require a massive computer, CodeBuild is not only cheaper but probably easier to use (as it already models the problem in terms of a task queue, so you don't have to do that part either).

Re: AWS CodeBuild – Build and test code with continuous scaling

#22
post #9

I'm trying to find if they offer or plan to offer these features: 1. Caching. CircleCI and Travis cache intermediate build artifacts (e.g., virtualenv in python) to reduce build time. 2. Github pull request integration (red cross on pull requests if the build fails). 3. Chat integration. Sending a message to slack or hipchat when the build fails. 4. SSH into build container. Very handy for rare but difficult to local…

Re #3: I'm confident that they won't offer that OotB, but they'll very likely have SNS integration, which could be translated into a Slack or HipChat message via Lambda. Depends on how much work you want to put in.

Re: AWS CodeBuild – Build and test code with continuous scaling

#25

At any time someone can show up to eat your lunch but if you're developing software for operations or developers it seems like a scary space to be in. AWS has a huge advantage by being able to simply add a service to their existing catalog.

I feel like none of the AWS developer offerings (the Code* services) are compelling enough.

Kind of like a lot of Microsoft tools, they are all lacking but, hey, the have deep integration with each other, so easier gluing.

Re: AWS CodeBuild – Build and test code with continuous scaling

#26
post #11
post #9

I'm trying to find if they offer or plan to offer these features: 1. Caching. CircleCI and Travis cache intermediate build artifacts (e.g., virtualenv in python) to reduce build time. 2. Github pull request integration (red cross on pull requests if the build fails). 3. Chat integration. Sending a message to slack or hipchat when the build fails. 4. SSH into build container. Very handy for rare but difficult to local…

The Github PR integration is the most important part for me. It's a necessity for us to be able to use it. We use our own install of Drone on a fairly sizable EC2 instance and not having to manage that anymore would be wonderful.

Github does expose an API for this: https://developer.github.com/v3/repos/statuses/

I mean integration is one less thing to build & manage, but you can sling together support in a pinch

Re: AWS CodeBuild – Build and test code with continuous scaling

#27
How many different CI workflow tools are on AWS these days? How do I know which one to pick? I really wish Amazon would spend some time building comparison guides for their services. Each one feels very silo'd off from each other and the crossover in functionality seems very high.

Re: AWS CodeBuild – Build and test code with continuous scaling

#28
post #6

https://aws.amazon.com/blogs/aws/aws-codebuild-fully-managed...

Hmm this blog post says it is available but there seems to be no way to get to it and it is not showing up in the console.

the url works

https://console.aws.amazon.com/codebuild

Re: AWS CodeBuild – Build and test code with continuous scaling

#29

I really wish AWS CodeBuild supported .net\C# as a preconfigured environment. Hopefully .net is not too far down on their priority list...right now we are using Jenkins.

I'm pretty certain someone will make a Docker image for Core CLR apps soon. There's one for Bitbucket Pipelines already.
Post reply on HN