This handles trusted publishing for Shaka Packager to NPM without
tokens.
This also updates upload/download actions, and adds a filter on specific
artifacts downloaded to avoid conflicts that have arisen since the last
release.
Also updates the images used in the build matrix.
Issue shaka-project/shaka-player#9132
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.
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
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
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
- Document necessary repo secrets
- Compress build artifacts directly to the arifacts folder
- Log test commands as they are executed
- Add comments
Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
