A collection of GitHub Actions for CI/CD workflows.
- Setup: Unified tool setup for consistent build environments
- Linters: Code quality checks for multiple languages (Python, Go, PHP, Ruby, Swift, Kotlin, and more)
- Docker: Build and publish Docker images to DockerHub
- AWS: Execute AWS CLI or shell commands
- CodeDeploy: AWS CodeDeploy integration for deployments
- Slack: Build status notifications
- SOUP: Open source license compliance and dependency tracking
- Variables: Environment variable preparation for parallel jobs
Reference the actions directly in your GitHub Actions workflow files:
uses: Cloud-Officer/ci-actions/setup@v2See individual action documentation below for detailed inputs and examples.
- aws: Execute AWS CLI or shell commands
- codedeploy: AWS CodeDeploy actions (checkout, deploy, s3copy)
- docker: Build and publish Docker images
- linters: Code quality linters for multiple languages
- setup: Setup tools for build environments
- slack: Send action status to Slack
- soup: Open source license compliance and SOUP list generation
- variables: Prepare variables for parallel jobs
Control CI behavior by adding these flags to your commit message:
| Flag | Description |
|---|---|
#beta-deploy |
Deploy to beta environment |
#rc-deploy |
Deploy to RC environment |
#prod-deploy |
Deploy to production (requires tag) |
#macos |
Enable macOS deployment |
#tvos |
Enable tvOS deployment |
#skip-licenses |
Skip license checks |
#skip-linters |
Skip linter checks |
#skip-tests |
Skip tests |
#skip-all |
Skip licenses, linters, and tests |
#update-packages |
Update packages |
#deploy-options=<value> |
Pass deployment options |
Example commit message:
Add new feature #beta-deploy #skip-tests
Please refer to the Github Enabling debug logging guide to set secrets to enable runner and steps debug logs.
You can always enable a tmate debug session to connect to a running runner instance and try things manually if debug logs are not enough. See Debug your GitHub Actions by using tmate.
The documentation for all the runner environments.
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
Pull requests are the best way to propose changes to the codebase. We actively welcome your pull requests:
- Fork the repo and create your branch from
master. - If you've added code that should be tested, add tests. Ensure the test suite passes.
- Update the documentation.
- Make sure your code lints.
- Issue that pull request!
When you submit code changes, your submissions are understood to be under the same License that covers the project. Feel free to contact the maintainers if that's a concern.