-
Notifications
You must be signed in to change notification settings - Fork 10.4k
GitHub Actions
This page contains a brief setup description for CI/CD pipelines in GitHub Actions workflows.
dev
branch uses that.
CONTENT
- Build workflows YAML definitions
- On Pull Request Builds
- On Push Builds
- GitHub Composite Actions
- Additional References
Folder /.github/workflows/
has all the YAML files for all build workflows. Although (for simplicity reasons) eShopOnContainers
that has all code in the same repo, we have one separated build per microservice. All builds have two jobs (named BuildContainersForPR_Linux
and BuildLinux
) that build the Linux version of the microservice for each PR and push on the dev
branch.
We use path filters to queue only the build when commits have files in certain paths. For example, this is the path filters sections of the Web Status microservice:
paths:
- src/BuildingBlocks/**
- src/Web/WebStatus/**
- .github/workflows/webstatus.yml
The build will be triggered if the commits have some file in these folders. Any other change won't trigger the build. Using path filters we have the flexibility to use a single repository, separated builds, and trigger only the needed builds.
Please, refer the GitHub Actions for more information.
We have a build workflow for each service in GitHub Actions created from the YAML file. To create the build
workflow from an existing YAML file, create a new build workflow in GitHub Actions:
After choosing a new workflow, either you can define your workflow YAML from scratch or choose the Feature Actions from the Market place. To define the workflow file, you can leverage the online YAML editor.
We have enabled the build workflows for pull_request
event on dev
branch.For that each workflow has BuildContainersForPR_Linux
job. There are some differences between a normal build and the build triggered by a PR though:
The build triggered from a PR do not push the docker images to any docker registry.
We have enabled the build workflows for push
event on dev
branch.
For that each workflow has BuildLinux
job. Each push event builds the docker image and push it to the dockerhub.
Recently, all the GitHub workflows have been refactored with the help of GitHub Composite Actions. You can find the PR and discussions in here.
If you want to know more about it, please refer to GitHub Composite Actions
- System requirements
- Development setup
- Databases & containers
- Architecture
- Application
- Code
- Logging and Monitoring
- Tests