Mirror-Tools
/
shaka-packager
mirror of https://github.com/shaka-project/shaka-packager.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
shaka-packager/.github/workflows/github_release.yaml

228 lines
7.3 KiB
YAML
Raw Normal View History

Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
name: GitHub Release
# Runs when a new tag is created that looks like a version number.
#
# 1. Creates a draft release on GitHub with the latest release notes
# 2. On all combinations of OS, build type, and library type:
# a. builds Packager
# b. builds the docs
# c. runs all tests
# d. attaches build artifacts to the release
# 3. Fully publishes the release on GitHub
#
# Publishing the release then triggers additional workflows for NPM, Docker
# Hub, and GitHub Pages.
#
# Can also be run manually for debugging purposes.
on:
push:
tags:
- "v*.*"
# For manual debugging:
workflow_dispatch:
inputs:
tag:
description: "An existing tag to release."
required: True
jobs:
setup:
name: Setup
runs-on: ubuntu-latest
outputs:
tag: ${{ steps.compute_tag.outputs.tag }}
steps:
- name: Compute tag
id: compute_tag
# We could be building from a workflow dispatch (manual run)
# or from a pushed tag. If triggered from a pushed tag, we would like
# to strip refs/tags/ off of the incoming ref and just use the tag
# name. Subsequent jobs can refer to the "tag" output of this job to
# determine the correct tag name in all cases.
run: |
# Strip refs/tags/ from the input to get the tag name, then store
# that in output.
echo "::set-output name=tag::${{ github.event.inputs.tag || github.ref }}" \
| sed -e 's@refs/tags/@@'
draft_release:
name: Create GitHub release
needs: setup
runs-on: ubuntu-latest
outputs:
release_id: ${{ steps.draft_release.outputs.id }}
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
path: src
ref: ${{ needs.setup.outputs.tag }}
- name: Check changelog version
# This check prevents releases without appropriate changelog updates.
run: |
cd src
VERSION=$(packager/tools/extract_from_changelog.py --version)
if [[ "$VERSION" != "${{ needs.setup.outputs.tag }}" ]]; then
echo ""
echo ""
echo "***** ***** *****"
echo ""
echo "Version mismatch!"
echo "Workflow is targetting ${{ needs.setup.outputs.tag }},"
echo "but CHANGELOG.md contains $VERSION!"
exit 1
fi
- name: Extract release notes
run: |
cd src
packager/tools/extract_from_changelog.py --release_notes \
| tee ../RELEASE_NOTES.md
- name: Draft release
id: draft_release
uses: actions/create-release@v1
env:
ci: Use GITHUB_TOKEN instead of SHAKA_BOT_TOKEN (#977) There is not a good reason to use a long-lived token attached to shaka-bot. Instead, use a short-lived, automatic token generated by GitHub Actions for the workflow run.
2021-08-12 17:50:29 +00:00
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
with:
tag_name: ${{ needs.setup.outputs.tag }}
release_name: ${{ needs.setup.outputs.tag }}
body_path: RELEASE_NOTES.md
draft: true
Fix python linter errors and add linter checks to CI Internal CI systems and the new GitHub CI system were out of sync, with the external system not doing any linting. Further, the internal system was using an internal-only linter for Python. This creates a script for Python linting based on the open-source pylint tool, checks in the Google Style Guide's pylintrc file, creates a custom action for linting and adds it to the existing workflows, fixes pre-existing linter errors in Python scripts, and updates pylint overrides. b/190743862 Change-Id: Iff1f5d4690b32479af777ded0834c31c2161bd10
2021-06-18 19:23:22 +00:00
lint:
needs: setup
name: Lint
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
path: src
ref: ${{ needs.setup.outputs.tag }}
# This makes the merge base available for the C++ linter, so that it
# can tell which files have changed.
fetch-depth: 2
- name: Lint
uses: ./src/.github/workflows/custom-actions/lint-packager
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
build_and_test:
Fix python linter errors and add linter checks to CI Internal CI systems and the new GitHub CI system were out of sync, with the external system not doing any linting. Further, the internal system was using an internal-only linter for Python. This creates a script for Python linting based on the open-source pylint tool, checks in the Google Style Guide's pylintrc file, creates a custom action for linting and adds it to the existing workflows, fixes pre-existing linter errors in Python scripts, and updates pylint overrides. b/190743862 Change-Id: Iff1f5d4690b32479af777ded0834c31c2161bd10
2021-06-18 19:23:22 +00:00
needs: [setup, lint, draft_release]
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
strategy:
matrix:
CI: update runner labels for self-hosted runners It was suggested in code review for another project that we update the runner labels for clarity. This brings Packager in line with that, so that we are using the same labels across projects. The runners have already been updated to register with the new label. Change-Id: I30b22530225b5bd22b965ba98d276bcd74ade6cf
2021-08-26 21:02:49 +00:00
os: ["ubuntu-latest", "macos-latest", "windows-latest", "self-hosted-linux-arm64"]
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
build_type: ["Debug", "Release"]
lib_type: ["static", "shared"]
include:
- os: ubuntu-latest
os_name: linux
build: Add arm64 to the build matrix This will also allow us to create official arm64 builds starting with our next release. Change-Id: Iaca5e8406c5e28883346a7884eb0f30815ad0d19
2021-08-03 04:06:07 +00:00
target_arch: x64
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
exe_ext: ""
build_type_suffix: ""
- os: macos-latest
os_name: osx
build: Add arm64 to the build matrix This will also allow us to create official arm64 builds starting with our next release. Change-Id: Iaca5e8406c5e28883346a7884eb0f30815ad0d19
2021-08-03 04:06:07 +00:00
target_arch: x64
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
exe_ext: ""
build_type_suffix: ""
- os: windows-latest
os_name: win
build: Add arm64 to the build matrix This will also allow us to create official arm64 builds starting with our next release. Change-Id: Iaca5e8406c5e28883346a7884eb0f30815ad0d19
2021-08-03 04:06:07 +00:00
target_arch: x64
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
exe_ext: ".exe"
# 64-bit outputs on Windows go to a different folder name.
build_type_suffix: "_x64"
CI: update runner labels for self-hosted runners It was suggested in code review for another project that we update the runner labels for clarity. This brings Packager in line with that, so that we are using the same labels across projects. The runners have already been updated to register with the new label. Change-Id: I30b22530225b5bd22b965ba98d276bcd74ade6cf
2021-08-26 21:02:49 +00:00
- os: self-hosted-linux-arm64
build: Make release binary names more consistent Now that we have multiple architectures, we should factor both OS and architecture into the names of release binaries. This makes the names more formulaic, as well as consistent with the static-ffmpeg-binaries repository. Shaka Streamer will pull binaries from both this repo and that one, so consistent names would be helpful. The pssh-box release is actually OS and architecture independent, so remove the suffix from that and only release one copy of it. Change-Id: Ief3de49fae267c5267647a8dd4377023777ead37
2021-08-26 16:46:21 +00:00
os_name: linux
build: Add arm64 to the build matrix This will also allow us to create official arm64 builds starting with our next release. Change-Id: Iaca5e8406c5e28883346a7884eb0f30815ad0d19
2021-08-03 04:06:07 +00:00
target_arch: arm64
exe_ext: ""
build_type_suffix: ""
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
build: Make release binary names more consistent Now that we have multiple architectures, we should factor both OS and architecture into the names of release binaries. This makes the names more formulaic, as well as consistent with the static-ffmpeg-binaries repository. Shaka Streamer will pull binaries from both this repo and that one, so consistent names would be helpful. The pssh-box release is actually OS and architecture independent, so remove the suffix from that and only release one copy of it. Change-Id: Ief3de49fae267c5267647a8dd4377023777ead37
2021-08-26 16:46:21 +00:00
name: Build and test ${{ matrix.os_name }} ${{ matrix.target_arch }} ${{ matrix.build_type }} ${{ matrix.lib_type }}
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
runs-on: ${{ matrix.os }}
steps:
- name: Configure git to preserve line endings
# Otherwise, tests fail on Windows because "golden" test outputs will not
# have the correct line endings.
run: git config --global core.autocrlf false
- name: Checkout code
uses: actions/checkout@v2
with:
path: src
ref: ${{ needs.setup.outputs.tag }}
- name: Build docs (Linux only)
if: runner.os == 'Linux'
uses: ./src/.github/workflows/custom-actions/build-docs
- name: Build Packager
uses: ./src/.github/workflows/custom-actions/build-packager
with:
os_name: ${{ matrix.os_name }}
build: Fix missing target_arch parameter in build action This was causing failures on arm64, where the build action had an arm-specific clause that was skipped due to the missing parameter. Change-Id: I71b7fb15120855c444749dc2216b5f19f0561f6e
2021-08-24 05:13:52 +00:00
target_arch: ${{ matrix.target_arch }}
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
lib_type: ${{ matrix.lib_type }}
build_type: ${{ matrix.build_type }}
build_type_suffix: ${{ matrix.build_type_suffix }}
exe_ext: ${{ matrix.exe_ext }}
- name: Test Packager
uses: ./src/.github/workflows/custom-actions/test-packager
with:
lib_type: ${{ matrix.lib_type }}
build_type: ${{ matrix.build_type }}
build_type_suffix: ${{ matrix.build_type_suffix }}
exe_ext: ${{ matrix.exe_ext }}
- name: Attach artifacts to release
if: matrix.build_type == 'Release' && matrix.lib_type == 'static'
uses: dwenegar/upload-release-assets@v1
env:
ci: Use GITHUB_TOKEN instead of SHAKA_BOT_TOKEN (#977) There is not a good reason to use a long-lived token attached to shaka-bot. Instead, use a short-lived, automatic token generated by GitHub Actions for the workflow run.
2021-08-12 17:50:29 +00:00
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
with:
release_id: ${{ needs.draft_release.outputs.release_id }}
assets_path: artifacts
test: Run docker-based Linux distro tests in GitHub Actions When testing a PR or release, make sure the build still passes on all supported Linux distros. Change-Id: Id7046e8eb8fe999965ea22e12dd1ffdce2fa2d63
2021-10-13 19:11:35 +00:00
test_supported_linux_distros:
# Doesn't really "need" it, but let's not waste time on a series of docker
# builds just to cancel it because of a linter error.
needs: lint
name: Test builds on all supported Linux distros (using docker)
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
path: src
ref: ${{ github.event.inputs.ref || github.ref }}
- name: Install depot tools
shell: bash
run: |
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
echo "${GITHUB_WORKSPACE}/depot_tools" >> $GITHUB_PATH
- name: Setup gclient
shell: bash
run: |
gclient config https://github.com/google/shaka-packager.git --name=src --unmanaged
# NOTE: the docker tests will do gclient runhooks, so skip hooks here.
gclient sync --nohooks
- name: Test all distros
shell: bash
run: ./src/packager/testing/dockers/test_dockers.sh
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
publish_release:
name: Publish GitHub release
needs: [draft_release, build_and_test]
runs-on: ubuntu-latest
steps:
- name: Publish release
uses: eregon/publish-release@v1
env:
ci: Use GITHUB_TOKEN instead of SHAKA_BOT_TOKEN (#977) There is not a good reason to use a long-lived token attached to shaka-bot. Instead, use a short-lived, automatic token generated by GitHub Actions for the workflow run.
2021-08-12 17:50:29 +00:00
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Refactor actions and workflows It turns out that workflows were the wrong way to abstract reusable pieces of work. This turns common steps into custom actions (build docs, build packager, test packager) which can be used as encapsulated steps in multiple workflows. This is a much more natural way to avoid duplication compared to the previous approach of triggering one workflow from another. This also has the benefit of all of the steps of a release being represented on GitHub as a single workflow, making it easier to understand what is happening and what event triggered those steps. Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
2021-06-17 04:32:05 +00:00
with:
release_id: ${{ needs.draft_release.outputs.release_id }}