Use GitHub Actions syntax in a buildspec in Amazon CodeBuild
You can use a CodeBuild-managed action runner to run GitHub Actions within CodeBuild. This
can be done by adding steps
to any phase
in your buildspec file.
CodeBuild buildspecs support a list of sequential GitHub Action steps which run in a separate phase from CodeBuild commands. These GitHub Actions integrate with CodeBuild’s existing features, which include dependency caching, batch builds, access to Amazon Secrets Manager, and more.
Topics
- How do I get started with using a GitHub Action in my buildspec?
- Which GitHub Actions can I use in my buildspec?
- Can I use source providers other than GitHub when using GitHub Actions in my buildspec?
- Why do I need to connect to GitHub as a source provider in order to use GitHub Actions in my buildspec?
- How much does it cost to use GitHub Actions in my buildspec?
- Which regions support using GitHub Actions in my buildspec?
- Best practices for using GitHub Actions in your buildspec
- Limitations of using GitHub Actions in your buildspec in CodeBuild
- GitHub Action runner buildspec reference
- GitHub Action syntax samples with Amazon CodeBuild
How do I get started with using a GitHub Action in my buildspec?
The high-level steps to use a GitHub Action in your buildspec are as follows:
-
If you haven't done so already, connect your project to GitHub.
To do so, you can do one of the following:
-
You can add GitHub as a source provider in the console. For more information, see Connect GitHub with an access token (console) .
-
You can import your GitHub credentials via the CodeBuild API. For more information, see Connect GitHub with an access token (CLI) .
Note
This only needs to be done if you haven't connected to GitHub in another project.
-
-
In your project's buildspec, you can add
steps
, each of which references a GitHub Action. This can be edited in the CodeBuild console or in your source repository. Each build phase supports either a list of commands or a list of steps, but both cannot be used in the same phase. For more information, see Use GitHub Actions syntax in a buildspec in Amazon CodeBuild.
Which GitHub Actions can I use in my buildspec?
You can use any action available in the GitHub Marketplace
Can I use source providers other than GitHub when using GitHub Actions in my buildspec?
Yes, but connecting to GitHub is still required to authenticate with GitHub and access GitHub Actions. For more information, see GitHub and GitHub Enterprise Server access token.
Why do I need to connect to GitHub as a source provider in order to use GitHub Actions in my buildspec?
In order to use GitHub Actions in your buildspec, the source must be downloaded on a build compute. Anonymous downloads will be rate limited, so by connecting to GitHub, it can help ensure consistent access.
How much does it cost to use GitHub Actions in my buildspec?
Using GitHub Actions in your buildspec is supported at no additional cost.
Which regions support using GitHub Actions in my buildspec?
Using GitHub Actions in your buildspec is supported in all CodeBuild regions. For more information about Amazon Web Services Regions
where CodeBuild is available, see Amazon Services by Region
Best practices for using GitHub Actions in your buildspec
GitHub Actions are open source, built and maintained by the community. We follow the shared responsibility
model
More specific guidance and security best practices for GitHub Actions:
Limitations of using GitHub Actions in your buildspec in CodeBuild
-
GitHub Actions in your buildspec that internally rely on the
github
contextor that reference GitHub-specific resources, such as pull requests and issues, aren't supported in CodeBuild. For example, the following actions won't work in CodeBuild: -
GitHub Actions that attempt to add, change, or update GitHub resources, such as actions that update pull requests, or create issues in GitHub.
Note
Most official GitHub Actions listed in https://github.com/actions
rely on github
context. Instead, use actions available in the GitHub Marketplace. -
-
GitHub Actions in your buildspec that are Docker container actions
will work, but your build project must have privileged mode enabled and be run by the default Docker user (root). -
Actions must be run as a root user. For more information, see the USER
topic in Dockerfile support for GitHub Actions .
-
-
GitHub Actions in your buildspec are not supported in CodeBuild projects which are configured to run on Windows.
-
GitHub Action jobs (groups of steps) and GitHub Action job properties in your buildspec are not supported.
-
GitHub Actions in your buildspec are not supported in CodeBuild projects that are configured to be triggered by a webhook for a public Git repository. For more information, see git-credential-helper.
-
VPC builds without public internet access cannot run GitHub Actions in your buildspec.
-
Each build phase supports either a list of commands or a list of steps, but both cannot be used in the same phase. For example, in the following sample, steps are used in the pre-build phase to list GitHub Actions, while commands are used in the build phase to list CodeBuild commands.
version: 0.2 phases: pre-build: steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: 'true' DEFAULT_BRANCH: main build: commands: - echo "Building..." - npm run build
GitHub Action runner buildspec reference
This topic contains the buildspec reference for GitHub Action runner properties.
steps
Optional sequence. Steps are used to run commands and actions in CodeBuild. For more information, see Use GitHub Actions syntax in a buildspec in Amazon CodeBuild.
Note
Each build phase supports either a list of commands
or a list of steps
, but
both cannot be used in the same phase.
Each build step contains the following properties.
- id
-
Optional. The identifier for the step that can be used to reference the step in other contexts
. - if
Optional. A conditional statement that can be used to prevent a step from running unless a condition is met. This statement can use any supported context
, such as referencing environmental variables from CodeBuild, as well as expression . - name
-
Optional. The name for the step. If the name isn't specified, the name will default to the text specified in the
run
command. - uses
-
The action that runs for the step. Some actions require you to set inputs using
with
. Reference the action's README to determine which inputs are required. For more information, see Which GitHub Actions can I use in my buildspec?.If
uses
is specified in your build phase, it can't be used withrun
.Note
It's recommended that you include the version of the action you are using. This can be done by specifying a Git ref, SHA, or Docker tag. For more information, see steps.uses syntax
. - run
-
A command that runs command-line programs. These can be single-line commands or multi-line commands. By default, these commands run using non-login shells. To choose a different shell, use
shell
.If
run
is specified in your build phase, it can't be used withuses
. - shell
-
Optional. The shell specified for this sequence. For supported shell parameters, see steps.shell
. If unspecified, the shell used is bash. If bash is unavailable, sh is used. - with
-
Optional. A map of input parameters defined by the action. Each parameter is a key/value pair.
- with.args
-
Optional. A string that defines inputs for a Docker container.
- with.entrypoint
-
Optional. The Docker entrypoint specified for the Dockerfile.
- env
-
Optional. The variables specified for steps to use in the environment.
- continue-on-error
-
Optional. A Boolean value that indicates if a failure of this step sequence can be ignored.
false
-
The default value. If this step sequence fails, the build will fail.
true
-
If this step sequence fails, the build can still succeed.
- timeout-minutes
-
Optional. The maximum number of minutes the step can run for before terminating. By default, there is no timeout. If the step timeout exceeds the build timeout, the step will stop when the build timeout is reached.
The following is an example using the Super-Linter
version: 0.2 phases: build: steps: - name: Lint Code Base uses: github/super-linter@v5 env: VALIDATE_ALL_CODEBASE: true USE_FIND_ALGORITHM: true FILTER_REGEX_INCLUDE: '/github/workspace/buildspec.yml'
GitHub Action syntax samples with Amazon CodeBuild
These groups of samples can be used to experiment with GitHub Actions in your buildspec in CodeBuild.
Topics
Super-Linter GitHub Action sample
This sample demonstrates how to add the Super-Linter
You can add the Super-Linter GitHub Action to your CodeBuild project by updating the phase section of your buildspec file.
version: 0.2 phases: build: steps: - name: Lint Code Base uses: github/super-linter@v5 env: VALIDATE_ALL_CODEBASE: true
The Super-Linter logs will look similar to the following:
/github/workspace/hello-world/app.js:3:13: Extra semicolon.
/github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed.
/github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found.
/github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4.
/github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.
Batch build graph sample
The following example defines a build graph that creates a dependency chain and runs commands using steps
. In
this example, build1
runs first because it has no dependencies. Since
build2
has a dependency on build1
, so
build2
runs after build1 completes. For information, see Build graph.
version: 0.2 batch: fast-fail: false build-graph: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 env: variables: BUILD_ID: build2 depend-on: - build1 phases: build: steps: - run: echo $BUILD_ID
Amazon CodeGuru Reviewer sample
Amazon CodeGuru Reviewer finds issues in your Java and Python code and recommends how to remediate them. The following example uses CodeGuru Reviewer to provide full repository analysis code reviews. These code reviews scan all the code in a specified branch. For information, see Create code reviews with GitHub Actions in the Amazon CodeGuru Reviewer User Guide.
version: 0.2 phases: build: steps: - name: Amazon CodeGuru Reviewer Scanner if: ${{ always() }} uses: aws-actions/codeguru-reviewer@v1.1 with: s3_bucket: codeguru-reviewer-user artifacts: files: - codeguru-results.sarif.json
Note
Your Amazon S3 bucket must start with the codeguru-reviewer-
prefix.
The logs will look similar to the following:
INFO CodeReview created with arn=arn:aws:codeguru-reviewer:region
:account-id
:association:id
:code-review:RepositoryAnalysis-job
for job=job
INFO SARIF persisted to /github/workspace/codeguru-results.sarif.json
INFO Amazon CodeGuru Reviewer job execution completed
After the Amazon CodeGuru Reviewer job is complete, a sarif report is generated as CodeBuild artifact. For information, see Full repository analysis in the Amazon CodeGuru Reviewer User Guide.
Amazon Secrets Manager sample
Amazon Secrets Manager helps you manage, retrieve, and rotate database credentials, application credentials,
OAuth tokens, API keys, and other secrets throughout their lifecycles. The following example defines
a secret using Secrets Manager and runs commands using steps
. For information, see
What is Amazon Secrets Manager? in the Amazon Secrets Manager User Guide.
version: 0.2 env: secrets-manager: SECRET_VALUE: "arn:aws:secretsmanager:us-east-1:xxxx:secret:/secret-l3IJg9:my_super_secret_key" phases: build: steps: - run: echo $SECRET_VALUE
The logs will look similar to the following:
echo $SECRET_VALUE
env:
SECRET_VALUE: ***
***
Environment variable sample
The following example defines environment variables under the env
sequence. A S3_BUCKET
variable is defined in the buildspec
and assigned <bucket-name>
as its value. This variable is referenced in the if conditional like a regular environment variable by using the
dollar sign ($) to access the GitHub Action env context. For more
information, see env sequence.
version: 0.2 env: variables: S3_BUCKET: "
<bucket-name>
" phases: build: steps: - if: ${{ env.S3_BUCKET == '<bucket-name>
' }} run: echo "S3 bucket is $S3_BUCKET"
The logs will look similar to the following:
echo "S3 bucket is $S3_BUCKET"
env:
S3_BUCKET: my-s3-bucket
S3 bucket is my-s3-bucket
Exported environment variable sample
Exported environment variables are used in conjunction with CodePipeline to export environment variables from the current build stage to subsequent stages
in the pipeline. The following example defines an exported environment variable under the env
sequence named MY_VARIABLE
and writes to the GITHUB_ENV
environment file.
version: 0.2 env: exported-variables: - MY_VARIABLE phases: build: steps: - run: echo "MY_VARIABLE=my-value" >> $GITHUB_ENV
For more information, see ExportedEnvironmentVariable in the Amazon CodeBuild API Reference.