aws-actions / aws-codebuild-run-build Goto Github PK

I want to build to different images, for example windows vs linux.

When I use $GITHUB_OUTPUT within buildspec file with aws-actions/aws-codebuild-run-build then it gives error like:

Error: No file or directory found.

these commands below are used in buildspec file for passing the test to $GITHUB_OUTPUT and then I can use it at commenting in PR with uses: {{ steps.job-id.outputs.test }}.

Previous command: echo "::set-output name=test::${TEST}"
New command: echo "test=${TEST}" >> $GITHUB_OUTPUT.

But this works on a step of the job in GitHub actions, not on buildspec file.

tried
aws-actions/[email protected]
aws-actions/aws-codebuild-run-build@master still same problem.

I want to configure env variables as ARN parameters to be grabbed from the parameter store in AWS? Is there a way to do this?

Could you add support for --image-override option? Happy to PR myself.

Proposal: Add support for sourceTypeOverride and sourceLocationOverride

To enhance the usability of this Action and enable its integration with various source providers, such as GitHub Enterprise, we propose adding support for two new optional parameters:

1. sourceTypeOverride: This parameter allows users to override the source input type defined in the build project for the current build. By providing this option, users can specify alternative source types without modifying the underlying build project configuration. Valid values for this parameter would include:

   • NO_SOURCE
   • CODECOMMIT
   • CODEPIPELINE
   • GITHUB
   • S3
   • BITBUCKET
   • GITHUB_ENTERPRISE

2. sourceLocationOverride: This parameter enables users to specify a custom location that overrides the source location defined in the build project for the current build. By allowing users to provide an alternative source location, this feature offers flexibility in sourcing the build from different repositories or locations, depending on the specific requirements of each build.

The introduction of these parameters would greatly enhance the versatility of this Action, making it compatible with a wider range of source providers and enabling users to customize their build source settings on a per-build basis.

We believe that implementing this proposal would significantly improve the Action's adaptability and attract a larger user base, particularly those utilizing GitHub Enterprise or other source providers.

Please consider this proposal, and let us know your thoughts on how we can move forward with this enhancement.

Hi,

Thanks for implementing 'aws-actions/aws-codebuild-run-build@v1'. This is very useful.

My project has a requirement: Once the Codebuild job is triggered from Actions, the workflow should not wait for Codebuild job to complete.

Is there a way to force the Actions not to wait? Appreciate your help.

Thanks

NOTE: This might change between now and when we publish 1.0.0, but WILL NOT change after that.

There's been some discussion about the naming of the env-passthrough input.

The purpose of this input value is to identify which environment variables in the GitHub Actions job runner environment will be passed in to the CodeBuild environment.

For example, if the GitHub Actions environment contains environment variables:

FOO="BAR"
BAZ="WOW"
COMMIT="1763481762348"

and env-passthrough is set to FOO,COMMIT

then the action will send the following environment variable overrides to the CodeBuild build:

FOO="BAR"
COMMIT="1763481762348"

Even though BAZ is set in the GitHub Actions environment, because it is not identified in env-passthrough it is not sent to CodeBuild.

If we can come up with a better name for this, I'm ok with changing this before 1.0.0.

Humans are not going to look at this file.
Dependabot or similar can handle updating dependancies,
but adding dependancies is still a manual process.

Is there a way to ensure that a given package-lock.json is valid
within the context of a package.json file?

This error started to appear today - shortly after the v1.0.11 release was published.

Our (reusable) workflow file:

on:
  workflow_call:
    inputs:
      codebuild-project-name:
        description: The name of the AWS CodeBuild project to be executed
        type: string
        required: true

jobs:
  post-deployment-testing:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v1
        with:
          # Omitted
      - uses: aws-actions/aws-codebuild-run-build@v1
        with:
          project-name: ${{ inputs.codebuild-project-name }}

The workflow run logs confirm the exact action version used:

Download action repository 'aws-actions/configure-aws-credentials@v1' (SHA:67fbcbb121271f7775d2e7715933280b06314838)
Download action repository 'aws-actions/aws-codebuild-run-build@v1' (SHA:5c0236844bac232ef4c8ae94697cf7ddead5655a)

Note: 5c02368 matches release v1.0.11

Hi, the current GitHub Actions documentation for jobs.<job_id>.uses allows two styles of referencing the path to a reusable action workflow:

• {owner}/{repo}/.github/workflows/{filename}@{ref}
• ./.github/workflows/{filename}

both of these seem to require that /.github/workflows/ be part of the path. however, this repo's README guides users to specify consuming this GH Action as follows:

- name: Run CodeBuild
  uses: aws-actions/aws-codebuild-run-build@v1
  with:
    project-name: CodeBuildProjectName

as someone new to GH Actions I'm having trouble getting this CodeBuild action working at all. the contents of the /.github/workflows dir in this repo appear to be related to tests and not to the published AWS CodeBuild functionality. not sure whether this is a newly enforced requirement or updated behavior of GitHub Actions, or maybe I'm doing something else wrong. I suspect that simply moving (copying?) action.yml to /.github/workflows might fix it but not sure. any guidance would be appreciated.

Hi there,

My company uses a monorepo to build/deploy multiple projects at once. As such, we run 10+ checks using this action simultaneously, and if there are multiple PRs building at one time, we often seen failures along the lines of:

Run aws-actions/[email protected]
*****STARTING CODEBUILD*****
##[error]Rate exceeded
*****CODEBUILD COMPLETE*****

My suspicion is that this is actually the AWS api rate-limiting us on the backend as it makes repeated, simultaneous API calls from the same access key. This issue could probably be solved by either increasing the sleep time during waitForBuildEndTime or simply adding a try/catch block to avoid the process dying if the api call returns a rate limit error.

The action output aws-build-id is only set if the build completes.

This should probably be set as soon as possible so that it can be used in subsequent actions. We were trying to find a workaround for #143 so that in-flight builds can be cancelled.

We have a GitHub Action which utilizes aws-actions/aws-codebuild-run-build. We have been using this for the past 6 months in a few different repos. Yesterday (7/8/22) at around 2pm CST the action started failing with an error
STARTING CODEBUILD
Error: Cannot read property 'split' of undefined
CODEBUILD COMPLETE
All of our repos utilizing this action are experiencing the same error. The CodeBuild project in AWS is triggered and runs successfully, however, the workflow in GitHub fails.
We are using v1 in one of our repos and v1.0.3 in another one of our repos. Both experience the same error.
We are using self hosted runners in one of the repos and ubuntu-latest from GitHub runners in another repo. Both experience the same error

Github has started the deprecation process of Node 12 for GitHub Actions. Github is showing warning for this action run.
https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/

Also, 'set-output' and 'save-state' is deprecated and might get disabled by Github. @actions/core package needs to be bumped to v1.10.0 or greated and 'set-output' and 'save-state' needs to be removed if used anywhere.
https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

I'm using image-override to pull from a private ECR repo, but it doesn't work unless I can set image-pull-credentials-type-override to SERVICE_ROLE.

GitHub action I'm referring to: https://github.com/actions/checkout

Follow-up to #36. Ideally, this action should ensure that it always grabs the same commit as the standard action to checkout locally does. I worry there may be other special cases lurking. Perhaps we could even reuse code from that action?

Hello,

Initially, I was receiving an exit error 125, but now I'm receiving an error of 1. Both cases, it seems that CodeBuild isn't recognizing one or more Docker commands or arguments.

This is the current error:

[Container] 2020/08/19 22:15:32 Running command docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
--
41 | "docker build" requires exactly 1 argument.
42 | See 'docker build --help'.

My buildspec.yml is straightforward:

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - $(aws ecr get-login --no-include-email --region $AWS_DEFAULT_REGION)
  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
      - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker image...
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG

Image: aws/codebuild/standard:3.0
Privileged: True
Environment Type: Linux

Any idea what the issue might be? I couldn't find any mention of this error in the troubleshooting docs

We are interested in leveraging this Github action to trigger CB projects when a PR is created in our repo, however we are not comfortable with the idea that the buildspec can be overridden. A malicious user could modify the spec to perform actions beyond those allowed. Is there a way to prevent this behaviour via an IAM condition or any other way?

Currently, there is no way to set gitSumobuleConfigOverride in this action.
https://docs.aws.amazon.com/codebuild/latest/APIReference/API_StartBuild.html#CodeBuild-StartBuild-request-gitSubmodulesConfigOverride

This would be helpful when the repository is private.

The source type override parameter is automatically overridden on the CodeBuild job to the GITHUB type and current repository. We have a scenario that requires our CodeBuild job to source from a different location, but would still like to drive the execution of the CodeBuild job from a GitHub action.

Can we add a new parameter that allows us to disable the source type override parameters and use the CodeBuild job's default values?

The readme says:

The action builds the CodeBuild project, collects the build logs, and prints them as they are written. The user experience is the same as it would be if the logic were executed in the GitHub Actions job runner.

Is this correct? Does the build log become available on the Github Action Run Interface? I don't see it.

CodeBuild log:

...
9 | [Container] 2020/10/05 07:19:32 Registering with agent
10 | [Container] 2020/10/05 07:19:32 Phases found in YAML: 1
11 | [Container] 2020/10/05 07:19:32  BUILD: 1 commands
12 | [Container] 2020/10/05 07:19:33 Phase complete: DOWNLOAD_SOURCE State: SUCCEEDED
13 | [Container] 2020/10/05 07:19:33 Phase context status code:  Message:
14 | [Container] 2020/10/05 07:19:33 Entering phase INSTALL
15 | [Container] 2020/10/05 07:19:33 Phase complete: INSTALL State: SUCCEEDED
16 | [Container] 2020/10/05 07:19:33 Phase context status code:  Message:
17 | [Container] 2020/10/05 07:19:33 Entering phase PRE_BUILD
18 | [Container] 2020/10/05 07:19:33 Phase complete: PRE_BUILD State: SUCCEEDED
19 | [Container] 2020/10/05 07:19:33 Phase context status code:  Message:
20 | [Container] 2020/10/05 07:19:33 Entering phase BUILD
21 | [Container] 2020/10/05 07:19:33 Running command echo Hello World
22 | Hello World
23 |  
24 | [Container] 2020/10/05 07:19:33 Phase complete: BUILD State: SUCCEEDED
25 | [Container] 2020/10/05 07:19:33 Phase context status code:  Message:
26 | [Container] 2020/10/05 07:19:33 Entering phase POST_BUILD

Is there a way to get the CODEBUILD_BUILD_NUMBER or any other attributes as output ? There's a build id returned as output but I need more details (especially build number)
@seebees @hyandell @juneb @alex-chew @odanado

This PR has broken builds #102

And we get the following error when using aws-actions/aws-codebuild-run-build@v1

*****STARTING CODEBUILD*****
Error: Unexpected key 'disableSourceOverride' found in params
*****CODEBUILD COMPLETE*****

I just saw a new warning when running this action:

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: aws-actions/aws-codebuild-run-build@v1. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Context

I am currently working on developing workflows for stack deployment through CodeBuild. This includes a need to terminate previous builds before initiating a new one.
To implement this, I currently list the commit SHA and passes it to the CodeBuild run to stop the previous build.

Issue

I experience functional difficulties with this workflow when rebasing the branch, as the commit tree is completely different following the rebase.

Suggested Solution

Here are my solutions propositions to override the source version.

Proposal 1

The first proposition is to simply pass a source version adhering to the AWS CodeBuild sourceVersion standard.
The proposed implementation is:

- name: Trigger build on Codebuild
  uses: aws-actions/aws-codebuild-run-build@v1
  with:
    project-name: MyProjectName
    sourceVersion: refs/pull/${{ github.event.pull_request.number }}/head # or ${{ github.ref }} or ${{ github.sha }}

Proposal 2

The second proposition is slightly different, using a sourceVersionStrategy parameter instead. The proposed implementation is:

- name: Trigger build on Codebuild
  uses: aws-actions/aws-codebuild-run-build@v1
  with:
    project-name: MyProjectName
    sourceVersionStrategy: pull_request # or branch or sha

Personal notes

I'll be happy to implement this feature if ever approved

At current I've not seen a way to set an override for the compute type for this action.
I would like the ability to set this value as it seems to be supported by the API.
https://docs.aws.amazon.com/codebuild/latest/APIReference/API_StartBuild.html#CodeBuild-StartBuild-request-computeTypeOverride

Using v1.0.3, the build logs were functional for a time showing up in the GH action but then they suddenly stopped appearing. I checked and it is not a permissions issue because I can run an aws get-log-events just fine.

The only solution I found was downgrading to v1.0.0 where the logs show up again, but the rate-limiting error is occuring. (v1.0.1 and v1.0.2 also did not work). Is there a better solution?

Thank you!

v1.0.5...master

there are inputs, including compute-type-override, that weren't included in the action.yml file at the time of the latest release

see also: #95

The URL that we pass to CodeBuild to check out the code is currently hard-coded to use https://github.com. Because GitHub Actions is available in GitHub Enterprise, it would be nice if this action worked there too.

CodeBuild Projects can output artifacts, usually into an S3 bucket, from the build filesystem as a result of the build. We should collect these and pull them into the Actions environment.

I was curious if you had thought about a mechanism to register/run CodeBuild jobs as self-hosted runners for GitHub Actions? I think it would be a great feature, to avoid costs for Actions minutes, as self-hosted runners are free.

Hello,

What I'd like to have is a workflow in github actions that triggers for every branch on push (defined in a workflow in master default branch).

This workflow should trigger aws-codebuild-run-build action & the codebuild project should download source from a branch some_branch.

If I understood correctly, aws-codebuild-run-build overrides the source version to the triggering commit, regardless of the settings in the codebuild project.

How do I make sure that codebuild is going to get source from the specified branch some_branch?

Thanks!

Sorry for posting this here, I'm not sure where else to make this request. We use CodePipeline as part of our CI process (so we can also test out our pipeline infrastructure when we make changes). It would be great to have this same type of action but for CodePipeline instead (same basic functionality -- it will trigger the pipeline and wait for it to fail or complete successfully).

I am trying to use CodeBuild in time-consuming build that might exceed GitHub Actions free tier timeout (6 hrs).
Is it possible to somehow detach the build? I am fine with the information that it successfully started.
I can work around by simply retracting GetLogsEvents permission from the aws user, but then GH build fails, even though codebuild starts (and finishes) successfully.

Hi,

I have a codebuild job that takes just over an hour.

• The assume role allows for a 3 hour session.
• The job completes successfully and I can view the logs.
• The Github check fails and an error is logged about the security token being expired.

[Container] 2022/08/31 21:11:31 Phase complete: POST_BUILD State: SUCCEEDED
[Container] 2022/08/31 21:11:31 Phase context status code:  Message:
Error: The security token included in the request is expired
*****CODEBUILD COMPLETE*****

Any thoughts on what might be going on here?

I have a self-hosted runner on an EC2 instance that has the necessary IAM permissions granted via its instance profile.

On this instance, I am able to successfully interact with CodeBuild via the AWS CLI and Node.js SDK.

However, attempting to use this action fails with the message "No credentials. Try adding @aws-actions/configure-aws-credentials earlier in your job to set up AWS credentials."

I think the assertion below is not correct. In some cases, credentials are available, they just have not been initialized yet.

The following test script can be used to demonstrate this.

const aws = require("aws-sdk");

const codeBuild = new aws.CodeBuild({
    customUserAgent: "aws-actions/aws-codebuild-run-build",
});

console.log("The credentials object before using the API: " + codeBuild.config.credentials);

codeBuild.listProjects(function (err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else console.log("The credentials object after using the API: " + codeBuild.config.credentials);   // successful response
});

If I run it on my EC2 instance, the output is

$ node test.js 
The credentials object before using the API: null
The credentials object after using the API: [object Object]

So you can see that it was null at first, which is why your assertion failed, but that the API call actually succeeded.

I think the assertion should be reworked somehow to be more robust, or you could just remove it and catch and report permissions failures.

AWS Codebuild supports Environment Variable supports PLAINTEXT | PARAMETER_STORE | SECRETS_MANAGER as mentioned https://docs.aws.amazon.com/codebuild/latest/APIReference/API_EnvironmentVariable.html.

The github actions only supports PLAINTEXT. Support for PARAMETER_STORE | SECRETS_MANAGER should be added.

GitHub actions has file commands - GITHUB_ENV, GITHUB_STEP_SUMMARY and GITHUB_STEP_SUMMARY.
I'm trying to use GITHUB_STEP_SUMMARY this command but that's not working.
The same with setting-an-environment-variable

aws-actions/[email protected]

I'm running into an issue where I'm trying to set environment variables inside of the buildspec.yml but the variables are never set during install/build steps of the CodeBuild process. The buildspec.yml has the following in it:

batch:
  build-matrix:
    dynamic:
      env:
        variables:
          <<snip>>

Is this something that isn't supported?

In order to save on codebuild resources+cost, I want to use the functionality where we can say

close-running-builds: REF_FOR_TAG

to be able to close previous running builds for the given commit

This will be useful when running codebuild projects on each commit of a PR

During execution a GitHub Pull Request runs as a detached head, causing the GITHUB_SHA version to not match the latest commit.

This value is then passed to CodeBuild and shows up as the "Resolved Source Version" when the correct value is in github.event.pull_request.head.sha

Trying to override GITHUB_SHA in the Run does not work. Could an override be added? Similar to the others?

could its because am using bitbucket if there is any solution i would really appreciate

when triggering a codebuild project that is normally triggered from codepipeline this action sets the sourceTypeOverride and sourceLocationOverride . this is great.. however:

codebuild projects configured for codepipeline usually have Artifacts.Type: CODEPIPELINE resulting in

Error: ArtifactsOverride must be set when using artifacts type CodePipelines

we should support setting artifactsOverride.type to NO_ARTIFACTS

One key feature of Github Actions is the ability to kill obsolete builds when an update to a PR is pushed, through concurrency control (https://docs.github.com/en/actions/using-jobs/using-concurrency#overview).

I believe the way this Action works is (per docs):

1. Github starts aws-codebuild-run-build action based on some event (e.g. PR created/updated/edited)
2. aws-codebuild-run-build action starts codebuild
3. aws-codebuild-run-build action polls codebuild for status
4. aws-codebuild-run-build action succeeds or fails based on the final status

I was curious how to accomplish canceling the codebuild job started in (2) if during the polling step (3), the Github action is cancelled.
Would it be possible to use the expression functionality, to stop the aws-codebuild-run-build-action's aws-build-id when the cancellation happens, for example?

Curious if anyone in the community has gotten something like this to work, or if there are any contributions that would be needed to the action to allow this type of thing to work?

Related issue: #134 (comment)

(edit: Action State seems relevant. step (2) could store the build ID in Action State (which can potentially be removed in step (4) upon completion). Then, we can add a cleanup step after main that stops the build if the active build ID is present in the Action State.)

This article
AWS federation comes to GitHub Actions
explains we can use OIDC federated IAM Role in github actions workflow.

But now I got this error with aws-actions/aws-codebuild-run-build@v1.

Error: No credentials. Try adding @aws-actions/configure-aws-credentials earlier in your job to set up AWS credentials.

Simply comment out this assert, it works well.
https://github.com/aws-actions/aws-codebuild-run-build/blob/8945a85e94fd346070a0d8a28da303dbdd80b4bf/code-build.js#L228_L230

 assert(
    codeBuild.config.credentials && cloudWatchLogs.config.credentials,
    "No credentials. Try adding @aws-actions/configure-aws-credentials earlier in your job to set up AWS credentials."
  );

so for the moment I suggest just log this not assert but warning.

When I attempt to use the image override option, codebuild still uses the default container and I get a warning in the logs.

Warning: Unexpected input(s) 'image-override', valid inputs are ['project-name', 'buildspec-override', 'env-vars-for-codebuild']

- name: Codebuild
   uses: aws-actions/aws-codebuild-run-build@v1
   with:
     project-name: project_name
     image-override: overide_image_uri

Hi guys, I got this error when I run pnpm install in CodeBuild. Seems that pnpm cannot found the GitHub event.json when install.
Is there any way to fix or ignore this?
Cheers!

113 | [Container] 2023/03/01 04:59:07 Running command pnpm install
114 | node:fs:585
115 | handleErrorFromBinding(ctx);
116 | ^
117 |  
118 | Error: ENOENT: no such file or directory, open '/home/runner/work/_temp/_github_workflow/event.json'
119 | at Object.openSync (node:fs:585:3)
120 | at Object.readFileSync (node:fs:453:35)
121 | at NodeFS.readFileSync (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:84834:28)
122 | at NodeFS.readJsonSync (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:84171:30)
123 | at ../node_modules/.pnpm/@yarnpkg[email protected][email protected]/node_modules/@yarnpkg/core/lib/Configuration.js (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:160610:117)
124 | at __require (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:12:50)
125 | at ../node_modules/.pnpm/@yarnpkg[email protected][email protected]/node_modules/@yarnpkg/core/lib/execUtils.js (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:161970:27)
126 | at __require (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:12:50)
127 | at ../node_modules/.pnpm/@yarnpkg[email protected][email protected]/node_modules/@yarnpkg/core/lib/index.js (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:174430:43)
128 | at __require (/usr/local/lib/node_modules/pnpm/dist/pnpm.cjs:12:50) {
129 | errno: -2,
130 | syscall: 'open',
131 | code: 'ENOENT',
132 | path: '/home/runner/work/_temp/_github_workflow/event.json'
133 | }
134 |  
135 | [Container] 2023/03/01 04:59:07 Command did not exit successfully pnpm install exit status 1
136 | [Container] 2023/03/01 04:59:07 Phase complete: BUILD State: FAILED
137 | [Container] 2023/03/01 04:59:07 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: pnpm install. Reason: exit status 1

In #28 an issue was encountered with exceeding API rate limits. This was attended to with PR #29 where the update query interval was increased to 30s, and handling was added for rate exceeded error.

30s interval also has the effect of adding a 0-30s overhead to each action, depending on when the CodeBuild job happens to complete. For some use cases this overhead can be quite noticeable and unnecessary. E.g. for a singular/small group of short CodeBuild build(s), where we have little danger of hitting the rate-limiting. Some use-cases may also involve running CodeBuild builds in sequence, where this overhead is multiplied by the number of sequenced builds.

Offering a way to configure the update interval and backoff, rather than have them hard-coded as they are now, allows for a more fine-grained way to tune the API call rate to fit the use-case. This makes it possible to limit the unnecessary time overhead involved and enable a faster turn-around time. The current values could be kept as default.