#release-engineering (2024-04)

Wow, interesting…

Finally closed my feature request for this… https://github.com/aws-actions/aws-codebuild-run-build/issues/80

Would be great now to add this to https://github.com/cloudposse/terraform-aws-codebuild

should just be a matter of integrating the webhook resource, https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/codebuild_webhook

Same for organizational runners?

i don’t see how this would support organizational runners, exactly. the webhook is to a specific repository

i think you could either have a codebuild job per repository each with 1 webhook, or 1 codebuild job with a webhook per repository. but something has to scale per repository, rather than one and done at the org level

Oh, just build a lambda and…

sorry, i feel like i missed something. lambda?

Oh, sorry, I was being facetious! Just whenever something isn’t supported out of the box in AWS, for example, when there’s a new exciting announcement of native support for GitHub Runners, and when it doesn’t actually do what is needed, the fall back is always, “Just write a lambda”

I guess you could schedule a lambda that describes your github org repos, and creates the webhook

Perhaps my problem is coming at this from a Actions Runner Controller / Philips Labs Runners perspective, so the expectation is a more drop-in replacement than yet another apparatus.

Yeah, I was a little bummed that I couldn’t override ENVs as part of the StartBuild request. But then I realized it would read all that from the Github Actions config, not it’s own BuildSpec (which gets ignored in this setup)

There are org-level webhooks on the github side. I wonder if maybe some future feature on the Codebuild side might support an org-level codebuild job as a runner…

(thinking back to the other thread, about managing GitHub with Terraform, this would probably be pretty neat to incorporate with that)

this is the syntax for your github action config:

runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}

I was thinking that also. Create github repo, apply config, create codebuild job/webhook. Easy.

Would make it easy to provide specific types of runners for specific repos

Compared to the Actions Runner Controller / Philips Labs Runners setup, everything using the codebuild approach would be ephemeral. 1 job and done, scale to zero are just natural features

Yea, which is nice, although a bit slow waiting for instances to boot up

Slow but scalable

What are the options to speed that up?

i find codebuild startup to be very fast, just seconds really. unless i’ve hit some quota limiting how many i can launch at once

that’s for container jobs. you can use the lambda runner if you want faster startup

THat’s cool so it’s very flexible based on execution parameters. Fast/lightweight builds can use Lambda, and so on.

yeah they say you can use the lambda runners with this feature, but the docs don’t show an example yet… this is supposed to be the syntax for customizing the runner from the github action config:

runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<image>-<image-version>-<instance-size>

and there’s a table of the “values” for each of those tokens, but it doesn’t talk about lambda. i wonder if maybe you have to setup lambda on the job itself so it’s the default, and then you could “override” that from the action config…