Update the pullapprove verification tooling to ensure a reviewer is defined for
each group. This is being done in preparation for the upcoming change to how
pullapprove billing works. The new billing will work on a seats based approach
rather than flat usage.
PR Close#42614
Currently the `GitClient` accepts a generic parameter for determining
whether the `githubToken` should be set or not. This worked fine so far
in terms of distinguishing between an authenticated and
non-authenticated git client instance, but if we intend to conditionally
show methods only for authenticated instances, the generic parameter
is not suitable.
This commit splits up the `GitClient` into two classes. One for
the base logic without any authorization, and a second class that
extends the base logic with authentication logic. i.e. the
`AuthenticatedGitClient`. This allows us to have specific methods only
for the authenticated instance. e.g.
* `hasOauthScopes` has been moved to only exist for authenticated
instances.
* the GraphQL functionality within `gitClient.github` is not
accessible for non-authenticated instances. GraphQL API requires
authentication as per Github.
The initial motiviation for this was that we want to throw if
`hasOAuthScopes` is called without the Octokit instance having
a token configured. This should help avoiding issues as within
3b434ed94d
that prevented the caretaker process momentarily.
Additionally, the Git client has moved from `index.ts` to
`git-client.ts` for better discoverability in the codebase.
PR Close#42468
Removes the duplicate `hasLocalChanges` method from the Git client. We
already have `hasUncommittedChanges`. Also removes a TODO for adding
`assertNoLocalChanges` as it seems more flexible to manually check
(i.e. better messaging with context on the current tool; e.g. "cannot
perform rebase")
PR Close#42409
As per SemVer, deprecations should only be released if the
minor version is incremented. This means that we should error
if commits w/ deprecations target an upcoming patch, LTS release.
Additionally, we also error if deprecations are made as part of
an upcoming release-candidate.
PR Close#42454
If a commit message currently mentions the breaking change or
deprecation note keywords, the commit message parse logic
accidentally picks up the note. This could then accidentally
prevent the commit from being merged (e.g. if the commit targets
the patch branch but mentioned the `BREAKING CHANGE: ` marker).
This commit switches the commit message notes pattern to only
capture notes at the beginning of a line (also allowing accidental
whitespace). This matches with the format we describe in our
contribution guide, as well as with our commit message validation
logic that also assumes notes at the beginning of a line.
PR Close#42436
Currently the commit message validation tool from `ng-dev` validates
the `BREAKING CHANGE:` commit message notes. This commit adds a similar
check for `DEPRECATED:` commit message notes.
Additionally, the check for breaking changes is reworked slightly to
be more tolerant (i.e. if there is only a single line break after the
summary; this is acceptable as per the parser and commonly done in the
COMP repo). The checks have been updated to capture wrong keywords that
are commonly used instead of the correct one. e.g. if a commit message
uses `DEPRECATIONS:` instead of `DEPRECATED:`, the validation will fail.
This prevents changelog generation issues where breaking change notes,
or deprecations are missing. This happened in the COMP repo where
the `DEPRECATED:` keyword was used incorrectly. See:
99391e7939
PR Close#42436
We recently updated `@octokit/rest` to a more recent version. For this
the Github client had to be refactored to account for new types of
Octokit. With the refactorings the authentication of the Github
client broke as we used an incorrect option for setting the OAuth
token. The TS transpilation did not fail because the Octokit types
support arbitrary options in the constructor. This is not solvable
on our side, so we cannot prevent similar issues in the future
unfortunately. Adding tests for authentication is not a reasonable
option either.
Add a command to build the release output without stamping for release
and link via `yarn link` the generated builds to a project provided.
PR Close#42319
Move the release notes tooling under its own directory under release rather than
within publish, in preparation to have a release note generation command for ad-hoc
release note generation.
PR Close#42225
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
Joey Perrott
Paul Gschwendtner
Zach Arend
George Kalpakas
Alan Agius