When `ng-dev format --check` is run, the ng-dev tool prints out
all files that are out-of-date. We recently updated the format
tool to also capture `stderr` for failed files. This broke the
console message as we did not unwrap the `FormatFailure` to
their file path when printing the "ng-dev format" fix command.
PR Close#42252
Currently if formatting for a file fails due a formatter error,
the `ng-dev` tool reports that formatting failed, but no actual
error (or involved file) is printed out. This commit prints out
the failed files with their error message.
PR Close#42202
Previously, the dev-infra release tool would publish major versions
directly to the NPM `@latest` dist tag. This is correct in theory, but
rather unpractical given that we want to publish packages first as
`@next` so that other dependent Angular packages can update too,
allowing us to publish all main Angular packages (from FW, COMP
and TOOL) at the same time to `@latest` on NPM.
This involves creating a new release action for re-tagging the
previously released major as `@latest` on NPM.
PR Close#42133
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
Currently if a PR modifies any file that configures a Github action
(e.g. a workflow file), the caretaker might face an error when merging
such PR:
```
! [remote rejected] merge_pr_target_11.2.x -> 11.2.x (refusing to allow a Personal Access Token to create or update workflow
```
This happens because Github requires the token being used for the
push operation to have the `workflow` scope set. This is a special
scope added by Github to ensure that no changes can be made on
upstream branches that might expose the `GITHUB_TOKEN` environment
variable, which is available for push builds and could cause the
token being leaked.
With this commit we enforce that the caretaker adds the workflow
scope to their github token. Since PRs can only be merged if reviewed
thoroughly, it's acceptable to allow workflow file changes being
merged through the merge tool by the caretaker (especially since we
also allow CircleCI config files being merged with the default
`repo`/`public_repo` scope).
PR Close#41989
Previously by default GitClient would log the commands it was executing at the
INFO level. This change moves the default level of this logging to DEBUG, while
still allowing callers of the methods to set the log level back to INFO.
PR Close#41899
We recently added a sanity check that ensures that `python` is
available for Bazel. The check relies on `/usr/bin/python` to check
if python is available w/ the correct version. The problem is
that on Windows there is no guarantee that the `/usr/bin` folder
exists, so the `ng-dev release publish` command always fails.
We fix this by just accessing the `env` binary that is also consulted
by scripts executed within Bazel actions. The `env` binary can be
assumed exist in the shell's `$PATH` and can point us to Python
as if it would be executed within Bazel.
PR Close#41943
Currently we have a common utility method for running commands
in a child process. This method pipes all stdout and stderr, but sets
the `stdin` to `inherited`. This seemed to work as expected in terms of
allowing interactive commands being executed, but it messes with the
TTY in Windows (and potentially other platforms) so that colors and
prompts no longer work properly. See attached screenshot.
We fix this by not inheriting the stdin by default; but exposing
a dedicated method for interactive commands. This results in more
readable and obvious code too, so it's worth making this change
regardless of the TTY issues.
PR Close#41948
Currently if a major release-train in the `release-candidate`/`feature-freeze`
phase becomes `latest`, we intend to set the NPM LTS dist tag for all packages
of the previous major (as the old release train in `latest` moves into LTS phase).
The logic for this exists but the release tool sets the NPM dist tag for
all packages of the new major. This means that the script might error if
a new package is part of the new major; or it could cause a deleted
package to not receive the LTS tag properly.
PR Close#41946
Remove the getBaseDir method from GitClient as the baseDir is determined
once during construction and does not need to be rediscovered. The property
access should always be used.
PR Close#41898
This commit uses the correct property name (`prettier` vs `pretter`) to
check whether prettier is enabled via the config.
(It also fixes some typos in `dev-infra`.)
PR Close#41860
Since recently, the `githubToken` parameter passed to the `ReleaseTool`
constructor is no longer used. This commit removes the unused parameter
and also the corresponding argument from the `publish` script.
PR Close#41688
As `getRepoBaseDir()` relies on git, it should be a method on `GitClient` for retrieval
rather than its own utility outside of the common GitClient used for all git ineractions.
PR Close#41527
Creates a singleton class for GitClient rather than relying on creating an instance to
require being passed around throughout its usages.
PR Close#41515
During merging with `ng-dev pr merge` tooling will ensure that pull requests are
properly labeled for breaking changes. Pull requests with commits noting breaking
changes must also be labeled as such, additionally pull requests with breaking
change labels must contain commits noting breaking changes.
Fixes#38776
PR Close#41546
After updating to use the v4 graphql api in the merge tooling, the githubTargetBranch
was set to be the sha of the latest commit rather than the branch name of the target
branch. This caused our tooling to mismatch which branches were actually being targeted
with the effect that if a PR targeted only the patch branch (i.e. labeled `target: patch`
and targeting `11.2.x` in github)it would still expect to merge into both `11.2.x` and
`master`. This is now corrected to once again use the branch name, restoring to the
previous functionality.
PR Close#41523
Add a property, `targetLabelExemptScopes`, to the merge configuration allowing certain
scopes to be exempted from requirements for features and breaking changes only included
in PRs targetting certain labels.
PR Close#41459
Check commits in pull requests to ensure the pr can be merged into the target branch. Confirms
that prs targeting minor do not contain breaking changes, and prs targeting patch or lts do not
contain breaking changes or `feat` commits.
PR Close#41459
As the `test` and `refactor` commit types are not used in release notes and there
are solid use cases for having multiple scopes/scopeless uses of these types, they
are made to be optional instead of required on commits.
PR Close#41486
For commits from git log entries additional fields are available such as the reference
hash and author name, update the utility functions in commit-message to include the
parsed fields. Additionally define, per commit message type, whether to include the
commit in a release notes entry.
PR Close#41458
Create a utility method for the latest git tag, sorted by committerdate, which
matches SemVer, representing the latest version released on the branch.
PR Close#41455
Due to an issue with wombat proxy returning the login state of the generated tokens,
we will need to require a login for all `ng-dev release publish` runs to ensure npm
login has occured.
PR Close#41422
Check a range of commits by retrieving the log files to be parsed with the expected
format for the parser.
This change is in part of a larger set of changes making the process for obtaining
and parsing commits for release note creation and message validation consistent.
This consistency will make it easier to debug as well as ease the design of tooling
which is built on top of these processes.
PR Close#41341
As discovered in #41316, commit body length checks should consider all of the non-header
content as the commit body rather than the conventional-commit-parser's current method
of considering everything after an issue/PR reference to be the footer.
PR Close#41367
Use conventional-commits-parser for parsing commits for validation, this is being done
in anticipation of relying on this parser for release note creation. Unifying how commits
are parsed will provide the most consistency in our tooling.
PR Close#41286
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
Paul Gschwendtner
Joey Perrott
Zach Arend
George Kalpakas
Alan Agius
Kristiyan Kostadinov