glassechidna / cbactions Goto Github PK

What the title says. Right now the mux is hardcoded to have five listeners. It would be nice if we automatically registered and started new listeners whenever we reach 100% capacity.

Soooo it just occurred to me that maybe we could just have multiple copies of the runner's code on the filesystem and that could help avoid all the preload shenanigans. We should investigate if that's better or worse in terms of performance, complexity, etc.

Right now the cfn template allows any key ARN to be used for encrypting job information. We should instead include an AWS::KMS::Key resource in the template with a key policy that:

• Explicitly restricts kms:Decrypt to a principal listed in the encryption context
• Includes a timestamp in the encryption context. kms:Decrypt should only be allowed if the current time is less than this timestamp.
• Maybe include repo information for record-keeping in CloudTrail

Right now when the task is stopped, the replacement task's listeners are rejected for a few minutes until the old listeners timeout. Maybe there's a way to fix that.

Right now when the task is stopped, the replacement task's listeners are rejected for a few minutes until the old listeners timeout. Maybe there's a way to fix that

Right now the actions operate with the role assigned to the CodeBuild project. This isn't the end of the world, but I would like to experiment with the idea of having the Fargate task assume a role and then pass it to CodeBuild as environment variables. Thoughts:

• Obviously needs to be encrypted. As it's sensitive, maybe it should wait on the improvements in #3.
• Then the IAM role for CodeBuild only needs kms:Decrypt and the CloudWatch logs permissions. VPC ones too.
• When assuming the role, we can pass in a wealth of context as role session tags and the role session name. Things like
  • Repository
  • Workflow
  • Job name
  • "Actor" (who triggered it)
  • Branch
  • Commit SHA

Hi, I think it is a neat idea to use CodeBuild jobs as self-hosted runners for GitHub Actions! I was curious how's it working out for you?

Also, presuming you're still using the project, I was wondering if some of the new GitHub features would change the design, in particular GitHub Actions OIDC (which I learned about from your blog, thanks!) or ephemeral self-hosted runners?

We should work out how much vCPU and how much RAM is required for the Fargate task when there are N listeners running.