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/build_and_test.yaml

94 lines
2.9 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: Build and Test PR
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
# Builds and tests on all combinations of OS, build type, and library 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
# Also builds the docs.
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
#
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 when a pull request is opened or updated.
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
#
# Can also be run manually for debugging purposes.
on:
pull_request:
types: [opened, synchronize, reopened]
workflow_dispatch:
inputs:
ref:
description: "The ref to build and test."
required: False
jobs:
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:
name: Lint
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
path: src
ref: ${{ github.event.inputs.ref || github.ref }}
# 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
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +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
# Doesn't really "need" it, but let's not waste time on an expensive matrix
# build step just to cancel it because of a linter error.
needs: lint
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
strategy:
matrix:
os: ["ubuntu-latest", "macos-latest", "windows-latest"]
build_type: ["Debug", "Release"]
lib_type: ["static", "shared"]
include:
- os: ubuntu-latest
os_name: linux
exe_ext: ""
build_type_suffix: ""
- os: macos-latest
os_name: osx
exe_ext: ""
build_type_suffix: ""
- os: windows-latest
os_name: win
exe_ext: ".exe"
# 64-bit outputs on Windows go to a different folder name.
build_type_suffix: "_x64"
name: Build and test ${{ matrix.os_name }} ${{ matrix.build_type }} ${{ matrix.lib_type }}
runs-on: ${{ matrix.os }}
steps:
- name: Configure git to preserve line endings
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
# Otherwise, tests fail on Windows because "golden" test outputs will not
# have the correct line endings.
run: git config --global core.autocrlf false
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
- name: Checkout code
uses: actions/checkout@v2
with:
path: src
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
ref: ${{ github.event.inputs.ref || github.ref }}
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
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: Build docs (Linux only)
if: runner.os == 'Linux'
uses: ./src/.github/workflows/custom-actions/build-docs
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
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: Build Packager
uses: ./src/.github/workflows/custom-actions/build-packager
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
with:
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
os_name: ${{ matrix.os_name }}
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
CI overhaul based on GitHub Actions This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with GitHub Actions. In addition to using GitHub Actions to test PRs, this also expands the automation of releases so that the only manual steps are: 1. Create a new CHANGELOG.md entry 2. Create a release tag Workflows have been create for building and testing PRs and releases, for publishing releases to GitHub, NPM, and Docker Hub, and for updating documentation on GitHub Pages. When a new PR is created, GitHub Actions will: - Build and test on all combinations of OS, release type, and library type Appveyor's workflow took ~2 hours, whereas the new GitHub Actions workflow takes ~30 minutes. When a new release tag is created, GitHub Actions will: - Create a draft release on GitHub - Extract release notes from CHANGELOG.md & attach them to the draft release - Build and test on all combinations of OS, release type, and library type, aborting if any build or test fails - Attach release artifacts to the draft release, aborting if any one artifact can't be prepared - Fully publish the draft release on GitHub - Publish the same release to NPM (triggered by GitHub release) - Publish the same release to Docker Hub (triggered by GitHub release) - Update the docs on GitHub pages Closes #336 (GitHub Actions workflow to replace Travis and Appveyor) b/190743862 (internal; tracking replacement of Travis) Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
2021-06-10 21:40:14 +00:00
with:
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 }}