There is an `exec()` helper provided by `utils/shelljs.ts`, which is a
wrapper around ShellJS' `exec()` with some default options (currently
`silent: true`). The intention is to avoid having to pass these options
to every invocation of the `exec()` function.
This commit updates all code inside `dev-infra/` to use this helper
whenever possible).
NOTE: For simplicity, the `utils/shelljs` helper does not support some
of the less common call signatures of the original `exec()`
helper, so in some cases we still need to use the original.
PR Close#37444
Clean up pullapprove tooling to use newly created common utils.
Additionally, use newly created logging levels rather than
verbose flagging.
PR Close#37338
We recently added a better reporting mechanism for oauth tokens
in the dev-infra git util. Unfortunately the logic broke as part
of addressing PR review feedback. Right now, always the empty
promise from `oauthScopes` will be used as `getAuthScopes` considers
it as the already-requested API value. This is not the case as
the default promise is also truthy. We should just fix this by making
the property nullable.
PR Close#37439
Adds an assertion that the provided TOKEN has OAuth scope permissions for `repo`
as this is required for all merge attempts.
On failure, provides detailed error message with remediation steps for the user.
PR Close#37421
Rename bazel workspace from npm_dev_infra to npm_angular_dev_infra_private to make it clear that this package is private to angular.
Change driver-utilities module_name to match the new bazel workspace name.
Correct a comment by rewording it from "deployed version" to "published version".
Fix merge conflicts in tmpl-package.json
Make "//packages/bazel/src:esm5.bzl" replacement more generalized so that importing from "//packages/bazel" works.
Deleted "dev_infra/*" path from modules/benchmarks tsconfig.
Moved //dev-infra/benchmark/browsers to //dev-infra/browsers.
PR Close#36800
Migrate to using .ng-dev directory for ng-dev configuration to better
allow management of the configuration using multiple files. The
intention is to prevent the config file from becoming unruly.
PR Close#37142
Migrate the release tool in ng-dev to use new logging system rather
than directly calling console.* to create a better experience
for users.
PR Close#37232
Migrate the ts-circular-dependencies tool in ng-dev to use new logging system rather
than directly calling console.* to create a better experience
for users.
PR Close#37232
Migrate the merge tool in ng-dev to use new logging system rather
than directly calling console.* to create a better experience
for users.
PR Close#37232
Migrate the pullapprove tool in ng-dev to use new logging system rather
than directly calling console.* to create a better experience
for users.
PR Close#37232
Migrate the rebase tool in ng-dev to use new logging system rather
than directly calling console.* to create a better experience
for users.
PR Close#37232
Migrate the discover-new-conflicts tool in ng-dev to use new logging system
rather than directly calling console.* to create a better experience
for users.
PR Close#37232
Migrate the commit-message tool in ng-dev to use new logging system rather
than directly calling console.* to create a better experience
for users.
PR Close#37232
Migrate the formatting tool in ng-dev to use new logging system rather
than directly calling console.* to create a better experience
for users.
PR Close#37232
Adds .group and .groupEnd functions to each of the logging functions
to allow creating groups in the logged output. Additionally removes
the color parameter from logging functions, in favor of the color
being applied to the string at the call site.
PR Close#37232
The components repo and framework repository follow the same patch
branch concept. We should be able to share a script for determining
these merge branches.
Additonally the logic has been improved compared to the old merge script because
we no longer consult `git ls-remote` unless really needed. Currently,
`git ls-remote` is always consulted, even though not necessarily needed.
This can slow down the merge script and the caretaker process when a
couple of PRs are merged (personally saw around ~4 seconds per merge).
Additionally, the new logic is more strict and will ensure (in most
cases) that no wrong patch/minor branch is determined. Previously,
the script just used the lexicographically greatest patch branch.
This _could_ be wrong when a new patch branch has been created too
early, or by accident.
PR Close#37217
We recently added support for automatic registration of `ts-node`
when the dev-infra configuration is loaded.
In addition to registering ts-node, we should also ensure that the
`commonjs` module is set up. By default, `ts-node` would use ES module
imports that are not supported by default in NodeJS.
PR Close#37217
Creates common logging functions at different levels. Allows for providing
logging statements which are actually printed to the console based on the
LOG_LEVEL environment variable.
PR Close#37192
`ts-node` is now an optional peer dependency of the shared dev-infra
package. Whenever a `ng-dev` command runs, and a TypeScript-based
configuration file exists, `ts-node` is set up if available.
That allows consumers of the package (as the components repo) to more
conveniently use a TypeScript-based configuration for dev-infra.
Currently, commands would need to be proxied through `ts-node`
which rather complicates the setup:
```
NG_DEV_COMMAND="ts-node ./node_modules/@angular/dev-infra-private/cli.js"
```
I'm thinking that it should be best-practice to use TypeScript for
writing the configuration files. Given that the tool is used primarily
in Angular projects (for which most sources are TypeScript), this should
be acceptable.
PR Close#37196
Creates a tool in ng-dev which rebases a PR automatically and pushes
the rebase commits back to the PR. This is meant to be a replacement
to the local merge script currently in the repo and currently has
feature parity.
PR Close#37055
As mentioned in the previous commit, the autosquash strategy has
not been used in the components repo, so we could easily regress.
After thorough manual testing of the autosquash strategy again,
now that the merge script will be moved to framework, it came
to mind that there is a bug with the base revision in the
autosquash merge strategy. The problem is that the base revision
of a given PR is relying on the amount of commits in a PR.
This is prone to error because the amount of commits could easily
change in the autosquash merge strategy, because fixup or squash
commits will be collapsed. Basically invalidating the base revision.
To fix this, we fixate the base revision by determining the actual
SHA. This one is guaranteed to not change after the autosquash rebase.
The current merge script in framework fixates the revision by creating
a separate branch, but there is no benefit in that, compared to just
using an explicit SHA that doesn't need to be cleaned up..
PR Close#37138
The components repo does not use the autosquash merge strategy, so
recent changes to that seem to broke the autosquash strategy.
Since we don't run the rebase in interactive mode, the `--autosquash`
flag has no effect. This is by design in Git. We can make it work by
setting the git sequence editor to `true` so that the rebase seems
like an interactive one to Git, while it isn't one for the user.
This matches conceptually with the merge script currently used in
framework. The only difference is that we allow a real interactive
rebase if the `commit message fixup` label is applied. This allows
commit message modifications (and others) if needed.
PR Close#37138
Integrates the merge script into the `ng-dev` CLI. The goal is that
caretakers can run the same command across repositories to merge a pull
request. The command is as followed: `yarn ng-dev pr merge <number>`.
PR Close#37138
Moves the merge script from the components repository over
to the shared dev-infra package. The merge script has been
orginally built for all Angular repositories, but we just
kept it in the components repo temporarily to test it.
Since everything went well on the components side, we now
move the script over and integrate it into the dev-infra package.
PR Close#37138
Creates a tool in ng-dev to determine the PRs which become conflicted
by merging a specified PR. Often the question is brought up of how
many PRs require a rebase as a result of a change. This script allows
to determine this impact.
PR Close#37051
Adds the gitub configuration to the ng-dev configuration. This github
configuration provides information needed for making API requests to
github. Upcoming tooling related PRs will require these API requests
being possible.
PR Close#37097
Adds a gitub object to the common configuration for ng-dev. This github
configuration provides information needed for making API requests to
github.
PR Close#37097
Release commits do not require a commit body as the context, usually
provided in commit body, is already available in the process of
releasing. No additional value is gained from adding a body message
on these commits.
PR Close#37110
Introduces infrastructure to validate configuration of the ng-dev
command at run time. Allowing for errors to be returned to the
user running the command.
PR Close#37049
As per our discussion in the dev-infra sync meeting, we don't want
to have all dependencies show up as peer dependencies. Instead, we
only want to have larger dependencies such as `typescript` or buildifier
as peer dependencies. Tslib is also included for the sake of it being
generally a peer dependency of all Angular framework packages.
The rationale is that Yarn is smart enough to collapse packages
if all satisfy a given range. This means that we don't necessarily
need to have all dependencies as peer dependencies. The initial
idea was to keep all dependencies as peer dependencies so that
we have control over duplication of packages as downloading multiple
packages w/ different versions impacts local dev, CI and caches.
At the same time though, we don't want to bother with setting
up peer dependencies all the time. Not every consumer of the
shared dev-infra package would like to manually specify `yaml`
or `multimatch` etc. in the project `package.json`. Hence we
decided to go with a hybrid approach where only more impactful
dependencies are peer dependencies, and other smaller ones can
be standard depdencies that are usually collapsed by Yarn anyway.
Also this commit removes tslib from build targets that don't
rely on it.
PR Close#36980
Previously ng-dev loaded the config through a javascript file, this
change allows for the loaded file to be either javascript or
typescript. This enables configurations to be written with type
safety.
PR Close#37017
Migrating to a js file for providing a configuration allows for more
extensive configuration at run time. This allows for configs to include
logic and move beyond static values found in JSON files.
PR Close#36918
Migrates away from inline searching for files and running buildifier
directly, instead using ng-dev for formatting. Additionally, provides
a deprecation message for any usages of the previous commands.
PR Close#36842
In an effort to centralize formatting and linting enforcement into one
location, buildifier is being added as a formatter for ng-dev's format
command. Allowing for format enforcement for all .bzl, .bazel, WORKSPACE
and BUILD files.
PR Close#36842
Create a common environment stamping script in the ng-dev tooling
as to be used in common release tasks. This is the first step in
consolidating pieces of the release scripting process into a single
location to develop a release tool.
PR Close#36844
Previously we used gulp to run our formatter, currently clang-format,
across our repository. This new tool within ng-dev allows us to
migrate away from our gulp based solution as our gulp solution had
issue with memory pressure and would cause OOM errors with too large
of change sets.
PR Close#36726
* Set up dev-infra's :npm_package to also contain benchmarking suite
* Add benchmarking deps to dev-infra's package.json
* Add a bazel workspace to dev-infra's package.json. This is so that when a
project wants to use dev-infra's code and macros, they can just import the
macros from their node_modules instead of loading it separately
PR Close#36434