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

103 lines
3.2 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:
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
os: ["ubuntu-latest", "macos-latest", "windows-latest", "linux-arm64"]
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_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
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
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
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
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
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
exe_ext: ".exe"
# 64-bit outputs on Windows go to a different folder name.
build_type_suffix: "_x64"
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
- os: 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: ""
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: 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 }}
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
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 }}
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
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 }}