Currently this solution can be used in conjunction with github apps for organizations and personal repositories.

Github Enterprise supports "self-hosted enterprise runners" that can be registered on the enterprise level. Would be nice to have the option to created self-hosted enterprise runners.

Trying to use this library with my GHE resulted in the following error message:

The GitHub server does not support configuring a self-hosted runner with 'DisableUpdate' flag.

I'm using the codebuild provider and narrowed it down to the --disableupdate flag.

I'm new to this whole topic, but removing it from by buildspec manually resolved the issue. I'm guessing that the flag might even be irrelevant anyways since the runners are ephemeral?

What are the impacts of removing that flag? could we make it optional?

Hey,

I use codebuild for my runners and the default linux image (no custom image) provided. Ecr has the capability to do a vulnerability scan (https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html). I found a lot of critical security vulnerabilities inside of the container image. Do you have a clue why ?

br,

flo

From https://github.com/CloudSnorkel/cdk-github-runners/issues/72#issuecomment-1289480905

In your case it sounds like it's because we expect every job with the self-hosted label to also have a label we recognize. It sounds like you have multiple installations of cdk-github-runners in different accounts, each implementing different labels. That means some of the installations will not recognize the label and cancel the job. We can probably add a flag to disable this behavior. Let's do this in a separate ticket.

@laxgoalie392

Problem

Because the images use ubuntu:18.04, the git version is 2.17.1, checkout@v3 throws this warning message:

The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH

This causes some problems with committing inside the self-hosted runner, meaning you will get an error like this when you try to commit:

fatal: not a git repository (or any of the parent directories): .git

I don't know if there's a specific reason we use 18.04 but is it possible to bump the ubuntu version to 20.04 since it is LTS as well?

I just tried out to use the EC2 runners. Within our accounts we do not have a default VPC which leads to the stack can not be deployed.

const ec2Provider = new Ec2Runner(this, "ec2Runner", {
      subnet: subnets[0],
      spot: true,
    })

10:28:42 AM | CREATE_FAILED        | AWS::ImageBuilder::Image                       | Dev/GitHubRunners/...mage Builder/Image
Resource handler returned message: "Error occurred during operation 'No default VPC for this user. GroupName is only supported for EC2-Classic and default VPC.'." (RequestToken: ...., Handle
rErrorCode: GeneralServiceException)

Currently the Ec2RunnerProps also do not provide the option to set a VPC.

https://github.com/CloudSnorkel/cdk-github-runners/blob/main/src/providers/ec2.ts#L126-L186

Build images in AWS using CodeBuild (or any user configured method) so that:

1. We can automatically update images on a schedule to get the latest runner version and latest OS updates.
2. We can build any type of image independent of the deployment platform. This will make it easy to provide Windows or ARM images (closes #7).
3. We can expose an interface allowing the user to easily modify the Docker images by adding packages or commands to the build process (closes #26).

BREAKING CHANGE: providers no longer take runner version directly

Allow user to ask for multiple labels for each provider instead of just one. This allows easier usage of runners without remembering specific order of parameters in a label. For example users can use runs-on: [self-hosted, windows, x64, team1] instead of runs-on: [self-hosted, windows-team1-x64].

Resolves #128

Hey @kichik,

can`t get that image - maybe because I`m in another region .. eu-central-1 I wanted to build a windows container image for codebuild ...

code

    const windowsDefaultImage = new ContainerImageBuilder(
      this,
      `${props.serviceName}-${props.stage}-windows-image`,
      {
        architecture: Architecture.X86_64,
        os: Os.WINDOWS,
        runnerVersion: RunnerVersion.latest(),
        rebuildInterval: Duration.days(14),
        instanceType: ec2.InstanceType.of(
          ec2.InstanceClass.T3A,
          ec2.InstanceSize.LARGE
        ),
      }
    );

error:

The following required resource 'Image' cannot be found: 'arn:aws:imagebuilder:us-east-1:aws:image/windows-server-20
19-x86-core-ltsc2019-amd64/2020.12.8'

I'm using a codebuild runner and trying to run an action that relies on aws credentials.

i've tried using the following step in my workflow:

- name: Test
  run: aws sts get-caller-identity

but i end up getting the following error:

Unable to locate credentials. You can configure credentials by running "aws configure".

I also tried using the aws configure credentials action but am hitting basically the same error

- name: AWS Secure Access
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-region: us-east-1

My first impression was that I would be able to inherit the role that the codebuild runner was using

Ran into an issue where my org name + project name were 66 characters; GitHub errors if it's more than 64. This truncates that edge case at the cost of a couple bits of entropy from a UUID.

The following error is produced in SFN, when the spot is not available:

{
  "resourceType": "aws-sdk:ec2",
  "resource": "runInstances.waitForTaskToken",
  "error": "Ec2.Ec2Exception",
  "cause": "There is no Spot capacity available that matches your request. (Service: Ec2, Status Code: 500, Request ID: 5b80a392-c6eb-42d1-99e9-d36db1909cf4)"
}

Catching this error, and then defaulting to non-spot would be optimal.

Otherwise, GitHub runners continue running, waiting to be completed and nothing happens.

Does it make sense to launch multiple EC2 instances for each workflow?

This really slows the process down. I think ideally it should launch one instance, and then re-use it for all runs, and then when idle - shut down.

There was no label match, yet the state machine still waits to reap idle providers. No real harm here, but I think it'd be more optimized if it didn't wait in the cases where there was no match.

In fact, ideally, I think this selection should as early as possible.

I added the ec2 runner for test ...

cdk code:

    const cloudPlatformsEc2Runner = new Ec2Runner(
      this,
      `${props.serviceName}-${props.stage}-ec2-runner`,
      {
        labels: ["cloudplatforms", "ec2"],
        vpc: existingVpc,
        subnetSelection: vpcSubnets,
        spot: true,
        instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
      }
    );

workflow.yml:

name: fargate example
on: workflow_dispatch
jobs:
  self-hosted:
    runs-on: [self-hosted,cloudplatforms,ec2]
    steps:
      - run: echo hello world

stepfunctions:

these labels have been transmitted:

  "labels": {
    "self-hosted": true,
    "cloudplatforms": true,
    "ec2": true
  },

result:

it`s taking the wrong label :O

I assume because of this weird parent label