Solvro Devops Actions

The repository's purpose is to provide reusable workflows and composite actions for Solvro projects' CI/CD.

Two types of components are defined in this project:

Component	Runner (machine)	Purpose
Composite Action	runs on caller's job runner	a building block of another job
Reusable Workflow	has its own jobs and runners	entire pipeline

Examples

Composite action example

This example CI is built using project's composite actions.

CI flow:

• checkout with entire commit history
• setting up NodeJS on the runner
• running checks (without commitlint and building the project)

steps:
    - name: Checkout
       uses: Solvro/devops-actions/.github/actions/github-checkout@v1
       with:
         fetch-depth: 0

    - name: Setup Node.js
      uses: Solvro/devops-actions/.github/actions/node-setup@v1

    - name: Run migrations
      run: node ace migration:run --force

    - name: Node checks
      uses: Solvro/devops-actions/.github/actions/node-checks@v1
      with:
        should-run-commitlint: false
        should-run-build: false

Use reusable workflow example

Rember that workflows creates its own runners, one for each job.

The example yaml code does the same thing as example for composite actions.

uses: Solvro/devops-actions/.github/workflows/node-checks-ci.yml@v1
with:
    should-run-commitlint: false
        should-run-build: false

Components

Composite Acitons

Name	Path to use	Purpose
github-checkout	Solvro/devops-actions/.github/actions/github-checkout@v1	Checkout with depth param
node-setup	Solvro/devops-actions/.github/actions/node-setup@v1	Set up NodeJS project
node-ckecks	Solvro/devops-actions/.github/actions/node-checks@v1	Run checks for NodeJS project

Reusable Workflows

Name	Path to use	Purpose
node-checks-ci	Solvro/devops-actions/.github/workflows/node-checks-ci.yml@v1	CI for NodeJS project

Versioning

For versioning Google's release automation tool is used.

How does it work?

On every push to main branch the tool checks for specific commit messages and creates or updates release PR with bumped version.

• fix: → patch (1.0.1)
• feat: → minor (1.1.0)
• feat!: → major (2.0.0)
• chore: / docs: → no new version

Once the release PR is merged, _release.yml CI script created new version tag and runs smoke tests. If they pass the major tag (v1) moves to the newest version.