This repository contains a set of templates for Github workflows adapted to Smartway context.
Below is the list of available templates and associated documentations:
| Name | Path | Description | Documentation |
|---|---|---|---|
| Android Format Version Code | .github/workflows/android-format-version-code.yml |
Generates version code for Android applications | Documentation |
| ArgoCD Sync | .github/workflows/argocd_sync.yml |
Synchronizes applications with ArgoCD | Documentation |
| Build Image | .github/workflows/build-image.yml |
Builds and validates Docker images | Documentation |
| Build Xamarin Libs | .github/workflows/build-xamarin-libs.yml |
Builds Xamarin libraries | Documentation |
| Create APK Artifact | .github/workflows/create-apk-artifact.yml |
Creates Android APK artifacts | Documentation |
| Create Go-To-Prod PR | .github/workflows/create-gotoprod-pr.yml |
Creates production deployment pull requests | Documentation |
| Delete Docker Image | .github/workflows/delete-docker-image.yml |
Deletes Docker images from registry | Documentation |
| .NET Build | .github/workflows/dotnet-build.yml |
Builds and tests .NET applications | Documentation |
| .NET Publish | .github/workflows/dotnet-publish.yml |
Publishes .NET packages | Documentation |
| Dockerfile Linter | .github/workflows/dockerfile-linter.yml |
Lints Dockerfile syntax | Documentation |
| GitHub Release Notes | .github/workflows/gh-release-notes.yml |
Generates GitHub release notes | Documentation |
| GitHub Release Please | .github/workflows/gh-release-please.yml |
Automates release process | Documentation |
| Infra Cost | .github/workflows/infra-cost.yml |
Calculates infrastructure costs | Documentation |
| Publish APK to S3 | .github/workflows/publish-apk-s3.yml |
Publishes Android APKs to S3 | Documentation |
| Python Publish | .github/workflows/python-publish.yml |
Publishes Python packages | Documentation |
| Push Image GHCR to ECR | .github/workflows/push-image-ghcr-to-ecr.yml |
Pushes images from GHCR to ECR | Documentation |
| Release Tag | .github/workflows/releasetag.yml |
Generates release tags | Documentation |
| Run AWS | .github/workflows/run-aws.yml |
Executes AWS commands | Documentation |
| Run Docker | .github/workflows/run-docker.yml |
Runs Docker containers | Documentation |
| Run Docker with DB | .github/workflows/run-docker-with-db.yml |
Runs Docker containers with database | Documentation |
| Run Docker Upload Artifact | .github/workflows/run-docker-upload-artifact.yml |
Runs Docker and uploads artifacts | Documentation |
| Run Python | .github/workflows/run-python.yml |
Executes Python scripts | Documentation |
| Run Pytest | .github/workflows/run-pytest.yml |
Runs Python tests | Documentation |
| Send Slack Notification | .github/workflows/send_slack_notif.yaml |
Sends Slack notifications | Documentation |
| Send Slack Message | .github/workflows/send_slack_message.yaml |
Sends Slack messages | Documentation |
| Send Slack Github Actions Status | .github/workflows/send_slack_gha_status.yaml |
Sends Slack notifications | Documentation |
| Terraform | .github/workflows/terraform.yml |
Manages Terraform infrastructure | Documentation |
| Terraform Check Kube Enabled | .github/workflows/terraform_check_kube_enabled.yml |
Checks Kubernetes enablement for Terraform | Documentation |
Each workflow template has its own dedicated documentation page with detailed information about inputs, outputs, and usage examples.
This project uses Release Please from Google to automate the release process. The tool handles versioning and changelog generation based on commit messages.
To ensure releases are generated correctly, we follow the Conventional Commits specification. Commit messages should be structured as follows:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, etc.)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- build: Changes that affect the build system or external dependencies
- ci: Changes to our CI configuration files and scripts
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit
Example:
feat: add new workflow to handle peppermint
When introducing breaking changes, follow these steps to ensure a new major version is released:
- Prefix the commit message with
BREAKING CHANGE:: Indicate that the commit introduces breaking changes. - Describe the breaking change in the commit message: Provide details about what changes are being made and how they affect existing functionality.
- Merge the commit: Once the breaking change commit is merged,
Release Pleasewill automatically create a new major version.
Example commit message for a breaking change:
feat!: add new workflow to handle peppermint
BREAKING CHANGE: This update changes the way the Datadog monitor module interacts with the API, requiring updates to existing configurations.
The ! after feat indicates a breaking change, and the BREAKING CHANGE: section provides details about the change.