When multiple target labels are applied to a PR, it should be considered
invalid as our tooling does not support a single PR targetting multiple
trains/versions.
PR Close#40156
Delaying the check if a closed PR was closed by a merge or just closed by 30 seconds
allows for Github to have time to update the PR to be associated to the commit which
closed the PR. Without this delay, a race condition can exist in which we check for
how a PR was closed before this association is made.
PR Close#40181
This commit updates the versions of Chrome and Firefox used in tests -
both with Bazel and without (via Puppeteer) - to the latest:
- Chrome v87
- Firefox v84
PR Close#40150
This commit adds instructions in `dev-infra/browsers/README.md` on how
to update the version of GeckoDriver (the WebDriver implementation for
Firefox browsers).
NOTE:
The gecko driver download URLs perform redirection, so the `curl`
command needs to be run with the `-L/--location` option to follow
redirects. I updated all `curl` commands (even those that are not used
on gecko driver download URLs) for consistency.
PR Close#40150
Previously, the instructions and process for updating the version of
Chrome ued in tests assumed that there was always going to be a
ChromeDriver version that corresponded to a Chrome version. For example,
if we wanted to use Chrome v87.0.4272.x, we assumed that there was going
to be ChromeDriver v87.0.4272.x. It turns out that this is not always
the case.
This commit updates the instructions and process for updating the Chrome
version to ensure a valid version of ChromeDriver will be used as well.
PR Close#40150
This commit fixes the instructions in `dev-infra/browsers/README.md` to
use the `shasum` executable (instead of `sha256`, which does not exist
afaict).
The commit also fixes a couple of typos.
PR Close#40150
This commit refactor the `dev-infra/browsers/README.md` file to have one
sentence per line. This makes it consistent with other Markdown files in
the repository and makes diffs for future changes more readable.
This commit also uses proper Markdown numbered lists and fixes
indentation.
PR Close#40150
When building the environment stamp, support two modes: release and snapshot
The release mode will always stamp using the current version of in the root package.json
and in snapshot mode will use a version stamp expressing a version based on the tag and
the number of commits from the tag.
PR Close#40095
With the migration to husky@5, the environment variable used to skip husky changed from
`HUSKY_SKIP_HOOKS` to `HUSKY`. To continue skipping husky during the merge process as
expected, the environment variable used is updated.
PR Close#40025
Previously, when a PR which does not target the master branch in the Github UI was
merged it would not close automatically. This change detects when this case occurs
and closes the PR via the Github API.
For example:
A PR which targets the 11.0.x branch in the Github UI has the `target: patch` label
This PR is only pushed into the 11.0.x branch, which does not trigger Github's
reference based actions to close the PR.
PR Close#39979
When attempting to actually rely on `parseCommitMessagesForRange`, it became apparent
that the function really belongs in the parse file, rather than utils.
PR Close#39747
Allowing command line arguments to provide the file and source values to
the restore-commit-message command will assist in the the process of
upgrading to husky@5.
PR Close#39739
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
Some usages of the `GitClient` are better served by suppressing the
logging of lines that express what commands are being run. Many usages
of `GitClient` are contained within tools which are best served by
keeping the output clean as mostly read actions are occurring.
PR Close#39474
The node hash bang was incidentally removed in the published ng-dev, it should
be included to allow for the command to be run without having to specify node.
PR Close#39443
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
Perviously, it was not immediately clear what branches a PR would merge
into during the merge process. This prompt allows for caretakers to
understand and acknowledge where the PR will merge to.
PR Close#39333
Previously, temporary branches were created to be used for comparison to
the g3 branch, instead comparisons are now done using the branches
latest shas.
PR Close#39137
Previously, the `isCommitClosingPullRequest()` method (used in
`ng-dev release` to detect whether a commit is closing a PR based on
keywords found in the commit message) was only able to detect a subset
of the keywords supported by GitHub.
This is fine currently, because the merge script adds `PR Close #XYZ`
when merging a PR, but it might break in the future.
This commit makes the code more robust by ensuring the method can detect
all keywords supported by GitHub for automatically closing a PR based on
a commit message.
Original discussion:
https://github.com/angular/angular/pull/39135#discussion_r503440973
PR Close#39229
In #39135, the commit message string was accidentally changed from a
template literal to a regular string literal. This prevented the
`npmDistTag` variable from being correctly displayed in the error
message.
This commit fixes it by switching it back to a template literal.
NOTE:
This was pointed out in
https://github.com/angular/angular/pull/39135#discussion_r503361412, but
the PR was accidentally merged before the review feedback had been
addressed.
PR Close#39229
The `ng-dev release publish` command needs to check whether a commit
closed a pull request. This is implemented via checking the commit
message for specific closing keywords referencing the pull request
number.
The regex used previously failed to correctly ensure that the specified
pull request was referenced. For example, it would allow `#12345` to
also match for `#1234`.
This commit fixes the regex.
PR Close#39135
Bump Chrome to the next stable release (84.0.4147) by following the
instructions in dev-infra/browsers/README.md.
With Chrome 86 about to be released as stable, the current local version
(Chrome 83) is starting to lag behind. It also contains a bug that
blocks Angular unit and integration tests from using Trusted Types.
PR Close#39179
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.
Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0
Features of note for angular/angular:
* stdout/stderr/exit code capture; this could be potentially be useful
* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
heavy weight
Breaking changes of note for angular/angular:
* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
(which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`
* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.
* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
`@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
`@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
internals for ng_module.
* runfiles.resolve will now throw instead of returning undefined to match behavior of node require
Other changes in angular/angular:
* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.
NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.
* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
PR Close#39182
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.
Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0
Features of note for angular/angular:
* stdout/stderr/exit code capture; this could be potentially be useful
* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
heavy weight
Breaking changes of note for angular/angular:
* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
(which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`
* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.
* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
`@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
`@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
internals for ng_module.
* runfiles.resolve will now throw instead of returning undefined to match behavior of node require
Other changes in angular/angular:
* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.
NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.
* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
@josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial.
PR Close#37727
This commit adds a new command to the `ng-dev` suite, which verifies that the NgBot YAML config is
correct. It also adds this command to the `lint` CircleCI job so that we execute this check while
running CI.
This should help prevent syntax errors similar to the one introduced in:
393ce5574b
PR Close#39071
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
Introduces a new command for `ng-dev release`, so that the NPM
dist tag can be set for all configured NPM packages. This command
can be useful in case a manual tag needs to be set, but it is
primarily used by the release tooling when a new stable version
is cut, and when the previous patch branch needs to be set as LTS
version through a `v{major}-lts` dist tag.
It is necessary to have this as a command so that the release tool
can execute it for old branches where other packages might have been
configured. This is similar to the separate `ng-dev build` command
that we created.
Note that we also added logic for spawning a process conveniently
with different "console output" modes. This will be useful for
other command invocations in the release tool and it's generally
better than directly using native `child_process` as that one doesn't
log to the dev-infra debug log file.
PR Close#38656
Adds a command for building all release packages. This command
is primarily used by the release tool for building release output
in version branches. The release tool cannot build the release packages
configured in `master` as those packages could differ from the
packages available in a given version branch. Also, the build process
could have changed, so we want to have an API for building
release packages that is guaranteed to be consistent across branches.
PR Close#38656
Moves the existing `ng-dev release env-stamp` command into a
subfolder so that the staging/publish tool can have its own
dedicated folder (without being polluted by the env-stamp logic).
Every subcommand should be in its own folder.
PR Close#38656
Adds a new folder to dev-infra where shared testing utilities
could be placed in. This commit already adds initial testing
utilities for dealing with the `GitClient` and SemVer versions.
The `GitClient` in the testing utilities simulates actual Git
behavior in a virtual manner. It's not complete at all, but can
be extended based on our needs. The currently implemented commands
are the most basic ones that we'd need for our release tooling.
PR Close#38656
Adds a method for printing active release trains for a configured
project. This is helpful for the release tool that will print
the active release trains. Also this can be useful for the
caretaker status command, where we could print the active
version branches (i.e. "is there currently a feature-freeze branch").
PR Close#38656
Adds logic for determining active LTS branches for a given
release configuration. The active LTS branches can be determined
by querying NPM and matching dist tags against a specific
pattern. i.e. `v{major}-lts`.
This logic will be useful for the release tool that supports
publishing of active LTS version branches.
PR Close#38656
Cleans up outdated comments in the shared dev-infra Git
utilities. We also export the Graphql client for consistency
as we expose the `GithubClient` and `GitClient` too.
PR Close#38656
We initially added logic for determining active release trains into
the merge script. Given we now build more tools that rely on this
information, we move the logic into a more general "versioning" folder
that can contain common logic following the versioning document for the
Angular organization.
PR Close#38656
Introduces a new configuration for the `ng-dev release` command. This
configuration will be the source of truth for all release packages
and how they can be built.
Additionally, in a temporary manner where each project has its own
way of generating the changelog, the changelog generation can be
configured. This will be removed in the future when there is
canonical changelog generation in the dev-infra shared package.
PR Close#38656
Exposes logic for dealing with LTS branches, so that the release
tool can re-use it for cutting LTS patch releases.
Eventually, we can move all of this logic to a more dedicated
folder instead of having it inside the merge folder.
PR Close#38656
Instead of maintaining multiple interface for grouping
owner name and repo name, we expose a shared interface
describing a Github repository.
One unfortunate downside is that the GraphQL Github
and Rest API diverge slightly with the key for the
repository name. i.e. rest uses `repo` for the name
of a repository, while GraphQL uses `name` for the name.
If that would be consistent, we could use the rest operator
to pass a repository to the Octokit REST or GraphQL API. This
does not work, so we have a small manual overhead as seen
in the `branches.ts` file.
PR Close#38656
The dev-infra package is currently built with Bazel and ts-node.
In Bazel, the shared tsconfig from the `packages/` folder is used.
This means that the code is built in strict mode, but IDEs and
ts-node do not know about the strictness. This is because the tsconfig
is part of the `packages` folder and not accessible from the
dev-infra package. We fix this by adding an IDE and ts-node specific
tsconfig to the dev-infra package.
This helps with spotting compilation failures before building
with Bazel / waiting for CI to check build state.
PR Close#38656
Previously, the logic for determing the active release trains did not
return the resolved version of a release train. With the publish script
being created, we need this information and can just pass it through,
so that we do not need to fetch and parse the package.json of given
branches multiple times.
PR Close#38656
Sets up the NPM `ora` package in the project and in dev-infra,
so that we can show progress spinners when needed. This is useful
in the publish release script when we wait for a pull request to
be merged.
PR Close#38656
The git client respects the `SpawnSyncOptions` when a command
is executed. Currently it does not hide the command info
messages when commands are run in silent mode.
We fix this as part of this commit, so that the command info
is only printed to `debug` if `stdio` is set to `ignore`.
Additonally, the github token is made public so that it can be
used by commands if other repositories like forks are targeted.
PR Close#38656
Instead of repeating the logic for adding the github token to
a repository git url, we add a shared function for automatically
computing the URls with token.
Additionally, URLs for updating/generating tokens have been moved
to a dedicated file in the `utils` folder. Also while being at it,
the yargs github token helper is also moved into the dedicated
Git/Github related util folder.
PR Close#38656
This commit adds a logic to ouput the number of new and fixed cycles after running circular
dependency checker. This information is useful to better understand an impact of changes in case
the number of new/fixed cycles is relatively big.
PR Close#38805
During the merge process, all validations have already been completed so git commit
hooks can be safely skipped. This additionally, prevents errors from occuring which
would be caused the commit hooks executing, such as when yarn updates and then yarn
commands are unable to run within the same process.
PR Close#38888
As part of the commit message conformance check, local commit message checks are
made to be warnings rather than failures. An additional local option is also in
place to allow for the commit message validation failures to be considered errors
instead.
PR Close#38784
Currently we validate the configuration file on each `getConfig`
invocation. We can only validate once since the configuration
is cached.
Also while being at it, renames the cache variables to lower-case as those
do not represent constants (which are convention-wise upper case).
PR Close#38808
As not all users, particularly contributors consistently contributing with a deep
understanding of our commit message guidelines, will not want to rely on the
commit message wizard, we allow a user to opt out of using this wizard during
commit message creation.
PR Close#38701
Create a utility for loading a local user configuration object to describe
local configuration values, such as skipping the commit message wizard.
PR Close#38701
Previously, the validateCommitMessage function ran validation and logged the results.
The validateCommitMessage function now returns an object containing the validation
results and the cli action functions are instead responsible for logging the results.
This is being done as a prefactor for a change which allows for commit message
hook validation to be either a blocking error or a warning.
PR Close#38703
The angular team relies on a number of services for hosting code, running CI, etc. This
tool allows for checking the operational status of all services at once as well as the current
state of the repository with respect to merge and triage ready issues and prs.
PR Close#38601
Creates a mixin for requiring a github token to be provided to a command. This mixin
allows for a centralized management of the requirement and handling of the github-token.
PR Close#38630
Currently the merge script default branch configuration throws an error
if an unexpected version branch is discovered. The error right now
assumes to much knowledge of the logic and the document outlining
the release trains conceptually.
We change it to something more easy to understand that doesn't require
full understanding of the versioning/labeling/branching document that
has been created for the Angular organization.
PR Close#38622
Creates infrastructure to write outputs of command runs to ng-dev log file.
Additionally, on commands which fail with an exit code greater than 1, an
error log file is created with the posix timestamp of the commands run time
as an identifier.
PR Close#38599
When creating a commit with the git cli, git pre-populates the editor
used to enter the commit message with some comments (i.e. lines starting
with `#`). These comments contain helpful instructions or information
regarding the changes that are part of the commit. As happens with all
commit message comments, they are removed by git and do not end up in
the final commit message.
However, the file that is passed to the `commit-msg` to be validated
still contains these comments. This may affect the outcome of the commit
message validation. In such cases, the author will not realize that the
commit message is not in the desired format until the linting checks
fail on CI (which validates the final commit messages and is not
affected by this issue), usually several minutes later.
Possible ways in which the commit message validation outcome can be
affected:
- The minimum body length check may pass incorrectly, even if there is
no actual body, because the comments are counted as part of the body.
- The maximum line length check may fail incorrectly due to a very long
line in the comments.
This commit fixes the problem by removing comment lines before
validating a commit message.
Fixes#37865
PR Close#38438
Creates a tool within ng-dev to checkout a pending PR from the upstream repository. This automates
an action that many developers on the Angular team need to do periodically in the process of testing
and reviewing incoming PRs.
Example usage:
ng-dev pr checkout <pr-number>
PR Close#38474
Previously commit message types were provided as part of the ng-dev config in the repository
using the ng-dev toolset. This change removes this configuration expectation and instead
predefines the valid types for commit messages.
Additionally, with this new unified set of types requirements around providing a scope have
been put in place. Scopes are either required, optional or forbidden for a given commit
type.
PR Close#38430
We recently updated the benchpress package to have a more loose
Angular core peer dependency, and less other unused dependencies.
We should make sure to use that in the dev-infra package so that
peer dependencies can be satisified in consumer projects, and so
that less unused dependencies are brought into projects.
PR Close#38440
When a commit message fails validation, rather than throwing out the commit message entirely
the commit message is saved into a draft file and restored on the next commit attempt.
PR Close#38304
Adds an ng-dev formatter option to format all of the staged files. This will can
be used to format only the staged files during the pre-commit hook.
PR Close#38402
Previously, each Angular repository had its own strategy/configuration
for merging pull requests and cherry-picking. We worked out a new
strategy for labeling/branching/versioning that should be the canonical
strategy for all actively maintained projects in the Angular organization.
This PR provides a `ng-dev` merge configuration that implements the
labeling/branching/merging as per the approved proposal.
See the following document for the proposal this commit is based on
for the merge script labeling/branching: https://docs.google.com/document/d/197kVillDwx-RZtSVOBtPb4BBIAw0E9RT3q3v6DZkykU
The merge tool label configuration can be conveniently accesed
within each `.ng-dev` configuration, and can also be extended
if there are special labels on individual projects. This is one
of the reasons why the labels are not directly built into the
merge script. The script should remain unopinionated and flexible.
The configuration is conceptually powerful enough to achieve the
procedures as outlined in the versioning/branching/labeling proposal.
PR Close#38223
The merge tool provides a way for configurations to determine the branches
for a label lazily. This is supported because it allows labels to respect
the currently selected base branch through the Github UI. e.g. if `target: label`
is applied on a PR and the PR is based on the patch branch, then the change
could only go into the selected target branch, while if it would be based on
`master`, the change would be cherry-picked to `master` too. This allows for
convenient back-porting of changes if they did not apply cleanly to the primary
development branch (`master`).
We want to expand this function so that it is possible to report failures if an
invalid target label is appplied (e.g. `target: major` not allowed in
some situations), or if the Github base branch is not valid for the given target
label (e.g. if `target: lts` is used, but it's not based on a LTS branch).
PR Close#38223
The merge script currently accepts a configuration function that will
be invoked _only_ when the `ng-dev merge` command is executed. This
has been done that way because the merge tooling usually relies on
external requests to Git or NPM for constructing the branch configurations.
We do not want to perform these slow external queries on any `ng-dev` command
though, so this became a lazily invoked function.
This commit adds support for these configuration functions to run
asynchronously (by returning a Promise that will be awaited), so that
requests could also be made to the Github API. This is benefical as it
could avoid dependence on the local Git state and the HTTP requests
are more powerful/faster.
Additionally, in order to be able to perform Github API requests
with an authenticated instance, the merge tool will pass through
a `GithubClient` instance that uses the specified `--github-token`
(or from the environment). This ensures that all API requests use
the same `GithubClient` instance and can be authenticated (mitigating
potential rate limits).
PR Close#38223
There are a few changes in this PR to ensure conditions that are based
on groups (i.e. `- groups.pending.length == 0`) do not fail the verify
task:
* Remove the warning when a condition is encountered that depends on the
`groups` state. The warning will otherwise be printed once for every
file that triggers the execution of the condition (400,000+ times)
* Add an `unverifiable` flag to `GroupCondition` interface and set it to
true when an error is encountered due to attempting to get the state of
`groups` in a condition
* Ignore any unverifiable conditions when gathering unmatched
conditions. These should not be considered `unmatched` for verification
purposes.
* Print the unverifiable conditions by group in the results
Sample output:
```
┌──────────────────────────────────────────────────────────────────────────────┐
│ PullApprove results by group │
└──────────────────────────────────────────────────────────────────────────────┘
Groups skipped (4 groups)
Matched conditions by Group (37 groups)
Unmatched conditions by Group (0 groups)
Unverifiable conditions by Group (3 groups)
[public-api]
len(groups.pending.exclude("required-minimum-review")...
len(groups.rejected.exclude("required-minimum-review")...
[size-tracking]
len(groups.pending.exclude("required-minimum-review")...
len(groups.rejected.exclude("required-minimum-review")...
[circular-dependencies]
len(groups.pending.exclude("required-minimum-review")...
len(groups.rejected.exclude("required-minimum-review")...
```
PR Close#37798
Conditions can refer to the groups array that is a list of the preceding groups.
This commit adds support to the verification for those conditions.
This commit also adds some tests to the parsing and condition matching
to ensure everything works as expected.
PR Close#38164
* Without this BUILD file we were seeing errors about the reference to
expand_template.bzl in ng_rollup_bundle.bzl because dev-infra/bazel
was not considered a package.
PR Close#38026
Adds Firefox as browser to `dev-infra/browsers` with RBE
compatibility. The default Firefox browser is not compatible similar to
the default Chromium version exposed by `rules_webtesting`.
The Angular Components repository will use this browser target as
it enables RBE support. Also it gives us more flexibility about
the Firefox version we test against. The version provided by
`rules_webtesting` is very old and most likely not frequently
updated (based on past experience).
PR Close#38029
With `rules_nodejs` v2.0.0 being in RC phase currently, we should
make sure that the package is compatible so that we can use it
in the components repo in combination with rules_nodejs v2.0.0.
In v2.0.0 of the NodeJS rules, Bazel workspaces are recommended
to no longer be symlinked under a separate repository. Instead,
bazel rules and targets should be accessed directly from the
user-selected NPM repository. Usually `@npm`, so that the import
changes to `@npm//@angular/dev-infra-private/<..>`.
PR Close#37968
Alexey Elin
Joey Perrott
George Kalpakas
Charles Lyding
Andrew Scott
Bjarki
Greg Magolan
Andrew Kushnir
Paul Gschwendtner
Wagner Maciel
Ikko Ashimine
Andrew Scott