VirtoCommerce Continuous Integration

Overview

VirtoCommerce continuous integration based on GitHub Actions feature. It contain:

• yaml workflows, placed in Platform, Modules, Storefront and Themes repositories;
• special actions, placed in VirtoCommerce/vc-github-actions repository;
• shared library, with common used in special actions components, placed in @virtocommerce/vc-actions-lib

Workflows

Two type of workflows have been implemented main workflows and tests automation workflows.

Main workflow

Main workflow implement base VirtoCommerce CI:

• Module CI;
• Platform CI;
• Storefront CI;
• Theme CI.

Workflow triggers automatically on Pull Request or on Push to Master or Dev branches.

On Pull Request event workflows force only code checks

On Push to Dev branch event workflows force code checks, creates artifacts for alpha version (pre-release) and publish artifacts to GtHub packages (images for Platform and Storefront) or to Azure Blob Storage (zipped binaries for Modules or Themes).

On Push to Master branch event workflows force code checks, creates artifacts for release version and publish artifacts to GtHub releases (zipped binaries for Platform, Storefront, Modules and Themes) to GtHub packages and Docker hub (images for Platform and Storefront). Also Nuget packages publish to VirtoCommerce Nuget Gallery.

Release alpha version

To crete artifacts for alpha version (pre-release) run manually main workflow from specified branch. It create alpha version artifacts and publish it to GtHub packages (images for Platform and Storefront) or to Azure Blob Storage (zipped binaries for Modules or Themes).

Tests automation workflows

OWASP ZAP

OWASP ZAP workflow implements dynamic application security testing. Workflow triggers automatically on Push to Dev branch or manually. The testing result report placed in workflow artifacts.

Read more about OWASP ZAP

E2E API tests

Platform E2E workflow runs API tests for platform and modules (in commerce bundle) endpoints. Workflow triggers automatically on Pull Request to Master or Dev branch or manually. When workflow runs manually testSuite parameter should be specified. A test suite is a collection of multiple different or duplicate test cases in Katalone test project. Default value is Test Suites/Platform_start.

Module E2E workflow runs API tests for current module (repository where workflow runs) and all dependend modules endpoints.

Actual API tests you can find in vc-quality-gate-katalon repository.

Secrets

Create GitHub organization level secrets:

• REPO_TOKEN - Github user token, with access to organization repositories;
• BLOB_TOKEN - connection string to Azure Blob Storage;
• DOCKER_USERNAME - DockerHub user name, with publish images privileges;
• DOCKER_TOKEN - DockerHub user token, with publish images privileges;
• NUGET_KEY - Nuget repository key;
• SONAR_TOKEN - SonarCloud access token, with Execute Analysis and Create Project privileges.

How to enable workflow in a repository

1. Navigate to the main page of the repository.
2. Click Actions.
3. If your repository already has existing workflows click New workflow.
4. Choose template you'd like to use in the "Workflows created by Virto Commerce" section. Click Set up this workflow.
5. For private repository create Secrets on repository level.

vc-github-actions repository

VirtoCommerce specific GitHub actions and actions common components lib.

Actions

• Add version suffix
• Build Docker image
• Build Theme
• Build Vue Theme
• Changelog generator
• Deploy Workflow
• Docker Check Modules
• Docker Env
• Docker Install Modules
• Docker Install Sampledata
• Docker Install Theme
• Docker Restore Dump
• Docker Start Environment
• Docker Validate Swagger
• Get Image version
• Katalon Studio Github action
• Publish Blob Release
• Publish Docker Image
• Publish Github Release
• Publish Katalon Report
• Publish Module Manifest
• Publish Nuget packages
• Publish Theme
• Setup credentials for git
• setup vcbuild
• SonarQube Quality Gate check
• SonarQube .net Analysis start
• SonarQube .net Analysis finish
• SonarQube Theme Analysis
• Swagger validation
• Sync Modules Workflows
• Actions components lib

Supply-chain security: pinned third-party actions

Every third-party uses: reference in this repo (anything not under VirtoCommerce/*) is pinned to a full 40-character commit SHA with a trailing # tag comment, per the GitHub Actions hardening guide. Tags are mutable; SHAs are not.

# Correct
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6

# Rejected by CI
uses: actions/checkout@v6

How updates happen

• Dependabot (.github/dependabot.yml) scans .github/workflows/ and every **/action.yml weekly. When upstream cuts a new tag, it opens a grouped PR bumping the SHA + trailing comment.
• Pin-check CI (.github/workflows/pin-check.yml) runs pinact run -check on every PR that touches workflows or action.yml files. PRs with unpinned third-party uses: lines fail.
• Scope is configured in .pinact.yaml — VirtoCommerce/* is intentionally ignored (internal, not third-party).

For contributors

• When adding a new third-party action, write the SHA, not the tag. Quick lookup:

  gh api repos/OWNER/REPO/commits/TAG --jq '.sha'

• VirtoCommerce/vc-github-actions/<dir>@master and other VirtoCommerce/* refs remain version-/branch-pinned as before.