Skip to content

Latest commit

 

History

History
138 lines (96 loc) · 5.13 KB

File metadata and controls

138 lines (96 loc) · 5.13 KB

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 "/[email protected], 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.