Instead of passing `string` in the release tool for NPM dist tags, we
should use a union string type that limits the tags to `latest`, `next`
and anything matching `v{number}-lts`. This avoids mistakes at
compilation-level if an invalid/unknown tag would be set by a release
action.
PR Close#42133
Currently the ng-dev release tool always run `bazel clean` before
calling the configured build release function. The clean is necessary
to ensure the release output is actually built; and not restored
from previous builds which could have different bazel workspace
status variables (which provide the NPM package version).
Instead of doing this as part of the release tool, the
actual script running to build the release output should
run the `bazel clean`. The release tool does not intend to
know about details on how the release output is built. This
is necessary because the build setup could vary between version
branches (especially for older ones; such as LTS version branches).
PR Close#42101
Creates a singleton class for GitClient rather than relying on creating an instance to
require being passed around throughout its usages.
PR Close#41515
Previously all github releases created by the release tooling tagged
releases as `latest`. Instead releases which are created for the `next`
tag on NPM should be tagged as `prerelease` for github.
PR Close#40999
Clearing the cached bazel outputs before building the artifacts for
publishing prevents an intermittent error found when the version is
cached between publishes.
PR Close#41000
When fetch is run in normal mode, the `git-fetch-pack` plumbing command
outputs progress to stderr. Since this is unnecessary progress
information for ng-dev usages, it should be suppressed instead.
PR Close#39503
Rather than running ng-dev via ts-node, going forward ng-dev is generated and run
locally via node. Additionally, the generated file is tested on each commit to
ensure that the local generated version stays up to date.
PR Close#39089
Creates a tool for staging and publishing releases as per the
new branching and versioning that has been outlined in the following
document. The tool is intended to be used across the organization to
ensure consistent branching/versioning and labeling:
https://docs.google.com/document/d/197kVillDwx-RZtSVOBtPb4BBIAw0E9RT3q3v6DZkykU/edit#heading=h.s3qlps8f4zq7dd
The tool implements the actions as outlined in the following
initial plan: https://hackmd.io/2Le8leq0S6G_R5VEVTNK9A.
The implementation slightly diverged in so far that it performs
staging and publishing together so that releasing is a single
convenient command. In case of errors for which re-running the
full command is not sufficient, we want to consider adding
recover functionality. e.g. when the staging completed, but the
actual NPM publishing aborted unexpectedly due to build errors.
PR Close#38656
Paul Gschwendtner
Joey Perrott
George Kalpakas