Commit Graph

5 Commits

Author SHA1 Message Date
Joey Parrish 507a731a9a
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 10:50:29 -07:00
Joey Parrish 56e227267c 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-21 21:46:48 +00:00
Joey Parrish acafc0fd93 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 13:36:59 -07:00
Joey Parrish a2e07a901e 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 10:32:24 -07:00
Joey Parrish 53c39ef9ac 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 14:24:24 -07:00