...
| Info | ||
|---|---|---|
| ||
As part of our work to run our S3P tests on a weekly basis in the Policy Framework we decided to investigate the possibly of using Github Actions for this task. Running our S3P tests weekly would provide regular feedback about the stability and performance of our Policy Framework components. As of now, our S3P tests are ran fully once per release. For this proposed approach, we would run shortened versions of our S3Ps on a weekly basis. This would contribute to our dynamic tests that we run as part of the Policy Framework. In this document I will outline the findings from this investigation. |
What is Github actions?
Github actions is a CI/CD platform for automating build or test pipelines. Further information on Github Actions can be found here: https://docs.github.com/en/actions/about-github-actions
Some key terms:
A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
...
A runner is a server that runs your workflows when they're triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows. Each workflow run executes in a fresh, newly-provisioned virtual machine.
Our Github Actions Workflow File Explained
| Code Block | ||||
|---|---|---|---|---|
| ||||
name: policy-api-performance-test (1)
on:
workflow_dispatch: (2)
# For Branch-Protection check. Only the default branch is supported. See
# https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection
inputs:
GERRIT_BRANCH:
description: 'Branch that change is against'
required: true
type: string
GERRIT_CHANGE_ID:
description: 'The ID for the change'
required: true
type: string
GERRIT_CHANGE_NUMBER:
description: 'The Gerrit number'
required: true
type: string
GERRIT_CHANGE_URL:
description: 'URL to the change'
required: true
type: string
GERRIT_EVENT_TYPE:
description: 'Gerrit event type'
required: true
type: string
GERRIT_PATCHSET_NUMBER:
description: 'The patch number for the change'
required: true
type: string
GERRIT_PATCHSET_REVISION:
description: 'The revision sha'
required: true
type: string
GERRIT_PROJECT:
description: 'Project in Gerrit'
required: true
type: string
GERRIT_REFSPEC:
description: 'Gerrit refspec of change'
required: true
type: string
branch_protection_rule:
# To guarantee Maintained check is occasionally updated. See
# https://github.com/ossf/scorecard/blob/main/docs/checks.md#maintained
# Run every Monday at 16:30 UTC
schedule: (3)
- cron: '30 16 * * 1'
jobs: (4)
run-s3p-tests: (5)
runs-on: ubuntu-22.04 (6)
steps:
- uses: actions/checkout@v4 (6)
- name: Run S3P script (7)
working-directory: ${{ github.workspace }}/testsuites
run: sudo bash ./run-s3p-test.sh run performance
- name: Archive result jtl (8)
uses: actions/upload-artifact@v4
with:
name: policy-api-s3p-results
path: ${{ github.workspace }}/testsuites/automate-performance/s3pTestResults.jtl
|
...
(8) - Archives the result of the Jmeter performance test
Triggering Github Actions
This page outlines the necessary boilerplate workflow code needed to trigger Github Actions workflows from Gerrit events such as a merge or push. https://docs.releng.linuxfoundation.org/projects/gerrit-to-platform/en/stable/index.html
...
We will store and manage our workflow files in the .github/workflows directory in each components repo. This differs to the way we store our Jenkins jjb files. Currently, we store our Jenkins jjb files in the ci-management repo under the policy directory.
Testing
There is two approaches I took when testing out this workflow.
...