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/README.md

50 lines
2.2 KiB
Markdown
Raw Normal View History

Address PR feedback - Document necessary repo secrets - Compress build artifacts directly to the arifacts folder - Log test commands as they are executed - Add comments Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
2021-06-16 21:15:08 +00:00
# GitHub Actions CI
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
## Actions
- `custom-actions/build-packager`:
Builds Shaka Packager. Leaves build artifacts in the "artifacts" folder.
Requires OS-dependent and build-dependent inputs.
- `custom-actions/test-packager`:
Tests Shaka Packager. Requires OS-dependent and build-dependent inputs.
- `custom-actions/build-docs`:
Builds Shaka Packager docs.
Address PR feedback - Document necessary repo secrets - Compress build artifacts directly to the arifacts folder - Log test commands as they are executed - Add comments Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
2021-06-16 21:15:08 +00:00
## Workflows
- On PR:
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.yaml`:
Builds and tests all combinations of OS & build settings. Also builds
docs.
Address PR feedback - Document necessary repo secrets - Compress build artifacts directly to the arifacts folder - Log test commands as they are executed - Add comments Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
2021-06-16 21:15:08 +00:00
- On release tag:
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
- `github_release.yaml`:
Creates a draft release on GitHub, builds and tests all combinations of OS
& build settings, builds docs on all OSes, attaches static release binaries
to the draft release, then fully publishes the release.
- On release published:
- `docker_hub_release.yaml`:
Builds a Docker image to match the published GitHub release, then pushes it
to Docker Hub.
- `npm_release.yaml`:
Builds an NPM package to match the published GitHub release, then pushes it
to NPM.
- `update_docs.yaml`:
Builds updated docs and pushes them to the gh-pages branch.
Address PR feedback - Document necessary repo secrets - Compress build artifacts directly to the arifacts folder - Log test commands as they are executed - Add comments Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
2021-06-16 21:15:08 +00:00
## Required Repo Secrets
- `DOCKERHUB_CI_USERNAME`: The username of the Docker Hub CI account
- `DOCKERHUB_CI_TOKEN`: An access token for Docker Hub
- To generate, visit https://hub.docker.com/settings/security
Make CI workflows safe when testing in a fork Testing CI workflows is a pain. This usually involves forking the main repo and testing various operations there, where the results will not break the main repo. However, some things like NPM and Docker package names were initially hard-coded. This meant that a fork would need to customize those in the workflows to avoid pushing official-looking packages during CI testing. This change moves those hard-coded names to GitHub Secrets. Though the names are not actually secret, the secret store is per-repo, and will be independent in a fork. This makes it easier to avoid accidentally pushing official-looking releases during testing, even if the fork has access to the same auth tokens. Change-Id: Ide8f7aa92a028dd217200fca60881333bf8ae579
2021-06-17 20:36:56 +00:00
- `DOCKERHUB_PACKAGE_NAME`: Not a true "secret", but stored here to avoid
someone pushing bogus packages to Docker Hub during CI testing from a fork
- In a fork, set to a private name which differs from the production one
Address PR feedback - Document necessary repo secrets - Compress build artifacts directly to the arifacts folder - Log test commands as they are executed - Add comments Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
2021-06-16 21:15:08 +00:00
- `NPM_CI_TOKEN`: An "Automation"-type access token for NPM for the `shaka-bot`
account
- To generate, visit https://www.npmjs.com/settings/shaka-bot/tokens and
select the "Automation" type
Make CI workflows safe when testing in a fork Testing CI workflows is a pain. This usually involves forking the main repo and testing various operations there, where the results will not break the main repo. However, some things like NPM and Docker package names were initially hard-coded. This meant that a fork would need to customize those in the workflows to avoid pushing official-looking packages during CI testing. This change moves those hard-coded names to GitHub Secrets. Though the names are not actually secret, the secret store is per-repo, and will be independent in a fork. This makes it easier to avoid accidentally pushing official-looking releases during testing, even if the fork has access to the same auth tokens. Change-Id: Ide8f7aa92a028dd217200fca60881333bf8ae579
2021-06-17 20:36:56 +00:00
- `NPM_PACKAGE_NAME`: Not a true "secret", but stored here to avoid someone
pushing bogus packages to NPM during CI testing from a fork
- In a fork, set to a private name which differs from the production one
Address PR feedback - Document necessary repo secrets - Compress build artifacts directly to the arifacts folder - Log test commands as they are executed - Add comments Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
2021-06-16 21:15:08 +00:00
- `SHAKA_BOT_TOKEN`: A GitHub personal access token for the `shaka-bot`
account, with `workflow` scope
- To generate, visit https://github.com/settings/tokens/new and select the
`workflow` scope