Skip to content

Latest commit

 

History

History

README.md

UltraGrid GitHub workflows

Table of contents

Dependencies

Further are described external dependencies needed to build proprietary parts of UltraGrid. The dependencies are not required - UltraGrid would build also without.

These additional dependencies must be provided at URL specified by a secret SDK_URL.

Further subsection briefly describe individual assets and how to obtain them. All assets are unmodified files downloaded from vendor website. However, rename may be required.

macOS

  • videomaster-macos-dev.tar.gz - VideoMaster SDK for Mac from DELTACAST

Windows

  • videomaster-win.x64-dev.zip - VideoMaster SDK from DELTACAST for Windows

Linux

Note: VideoMaster SDK is not used because DELTACAST doesn't provide redistributable libraries for Linux (as does for macOS and Windows).

Secrets

  • APPIMAGE_KEY - GPG exported (armored) private key to sign AppImage;
  • APPLE_KEY_P12_B64 - base64-encoded Apple signing key in P12 (see below) currently unused (no signing as for now - see the commit 2e321f65)
  • COVERITY_TOKEN - Coverity token to be used for build (Coverity CI only)
  • NOTARYTOOL_CREDENTIALS - Apple developer credentials to be used with notarytool for macOS build (username:password:teamid) notarization in format "user:password" (app-specific password is strongly recommended)
  • SDK_URL - URL where are located the Dependencies assets (currently Deltacast only)

Note: not all secrets are used by all workflows (see Workflows for details)

Note2: secret names are case-insensitive

Generating Apple keys to sign the image

This section contains a procedure to get and process keys to be used as APPLE_KEY_P12_B64 above.

  • first generate signing request (replace subject if needed):

    openssl genrsa -out mykey.key 2048 openssl req -new -key mykey.key -out CertificateSigningRequest.certSigningRequest -subj "/emailAddress=ultragrid-dev@cesnet.cz, CN=CESNET, C=CZ"

  • then login to Apple developer and generate a certificate from the above signing request for "Developer ID Application" and download developerID_application.cer

  • convert certificate to to PEM:

    openssl x509 -inform DER -outform PEM -text -in developerID_application.cer -out developerID_application.pem

  • export private key with password "dummy":

    openssl pkcs12 -export -out signing_key.p12 -in developerID_application.pem -inkey mykey.key -passout pass:dummy

  • add GitHub action secret APPLE_KEY_P12_B64 from output of:

    base64 signing_key.p12

Workflows

Currently workflows are triggered by push to the respective branch. Some of are triggered by a cron (schedule). Workflow dispatches available as well.

There are 4 main workflows and 3 OS-specific reusable workflows called by C/C++ CI:

ARM builds

(file .github/workflows/arm-build.yml)

Creates ARM AppImages. Trigerred by push to branch arm-build. In CESNET/UltraGrid repo creates a release asset, otherwise a build artifact. No secret are used.

Trigerred also once a week by a schedule.

Coverity

(file .github/workflows/coverity-scan.yml)

Sends build for analysis to Coverity service. Trigerred by push to coverity_scan - requires COVERITY_TOKEN, optionally also SDK_URL to increase code coverage.

Coverity workflow currently uses Linux runner only.

Trigerred also 2 times per week by a schedule.

C/C++ CI

(file .github/workflows/ccpp.yml)

This is the basic workflow, has multiple modes depending on which branch is pushed to. Whether or not triggered from official repository influences where will the build be uploaded:

  • push to official repository (branch master or v[0-9]+) - triggers rebuild of release asset (continuous for master) and uploads to release assets.
  • push to other repositories (branch master or v[0-9]+) - creates build artifacts

This worflow utilizes APPLE_KEY_P12_B64, APPIMAGE_KEY (currently not used, see above), NOTARYTOOL_CREDENTIALS,SDK_URL.

The OS-specific runners are split to 3 YAML files, that can be triggered separately by pushing to the respecitve branches - the upload rules are the above, which means that build artifact is created if pushed to the specific branch:

Semi-weekly tests

(file .github/workflows/semi-weekly_tests.yml)

Some additional tests run twice a week in the main repo.