The `dev-infra-framework` codeowners section is located after
all the codeowner sections for the individual framework packages.
This means that for certain wildcards, like `*.bzl` take precedence
over the individual package sections (like of `/packages/bazel/**`).
This can be observed in the following PR where `dev-infra` got requested
for file changes to `@angular/bazel`. #32955.
To fix this, we move the `dev-infra-framework` section before all
individual framework package sections. This means that we only match
files which are not matched by other patterns.
Additionally a pattern for `*.BAZEL` has been added to the dev-infra
section. This helps getting changes to `BUILD.bazel` files through
easier as dev-infra can review those (Note: only for bazel files which
are not matched by other patterns).
PR Close#32956
This change aims to align the documented members in `CODEOWNERS` with
the actual members of the secret `framework-global-approvers` GitHub
team.
PR Close#32667
BREAKING CHANGE:
Angular bazel users using protractor_web_test_suite from @angular/bazel npm package should now switch to the @bazel/protractor npm package.
This should impact very few users and the user's that are impacted have a very easy upgrade path to switch to fetching the protractor_web_test_suite rule via the @bazel/protractor npm package.
PR Close#32485
Based on the output of `node aio\scripts\verify-docs-codeownership`, the
following guides still have no owners:
- accessibility.md
- angular-compiler-options.md
- aot-metadata-errors.md
- bazel.md
- cli-builder.md
- static-query-migration.md
PR Close#32360
Initially when the `material-unit-tests` job got wired up,
Ivy was not really backwards-compatible and a few bugs caused
test failures when running the Angular Material test suites w/ Ivy.
These bugs got fixed progressively and eventually the test
blocklist became empty. At this point we don't want to regress
in the future and the blocklist should never have new items.
Additionally since we switched the unit-tests job to run against
Angular Material `master` with Bazel, the blocklist is no
longer respected. Therefore we can safely remove the blocklist.
PR Close#32138
Add some recommended config files to use (as is or as basis) for setting
up [remote development using docker containers][1] with VSCode. This is
an opt-in feature. See `.devcontainer/README.md` for more info.
The configuration can be further tweaked/improved, but is a good
starting point.
[1]: https://code.visualstudio.com/docs/remote/containers
PR Close#30450
This directory contains some top-level files (`.gitignore`,
`tsconfig.json`, `tslint.json`) that are related to the examples
infrastructure (building, linting, etc.).
They had previously no owner; now they are owned by the `docs-infra`
group.
PR Close#30087
With a770aa231, ngcc was moved to a different directory
(`compiler/src/ngcc/` --> `compiler/ngcc/`), but the `CODEOWNERS` file
was not updated to reflect that.
PR Close#29660
Currently, whenever someone on fw-core approvals list approves a change
to the angular_material_blocklist.js file, it is not sufficient because
dev-infra is also requested as a mandatory reviewer. This does not make
sense because this folder only contains the list of ignored tests and
not anything dev-infra related.
Previously, we tried to fix this by creating a "Material CI" section
underneath the existing "Build & CI" section, so that the "Material CI"
rule would override the rule matching the entire "tools" folder.
Unfortunately, this did not work. This commit attempts to resolve the
problem by explicitly marking all sub-folders in the "tools" folder
as owned by dev-infra (leaving out "material-ci"), so "material-ci"
is only referenced by the rule assigning fw-core as code owners.
PR Close#28990
Since we build and publish the individual packages
using Bazel and `build.sh` has been removed, we can
safely remove the `rollup.config.js` files which are no
longer needed because the `ng_package` bazel rule
automatically handles the rollup settings and globals.
PR Close#28646
Somehow the current list ommits quite a few important targets. Especially the cla and google3.
This changes adds all the statuses that must always be present and green for this agregate state expised as "ci/angular: merge status" to be green.
PR Close#28613
@alxhub spotted that the public api rule in codeowners is being overriden by the Build & CI Owners rule.
swapping the two sections fixes the problem.
PR Close#27999
I’ve observed that Brandon reviews many docs-only PRs and then we still need me or Jeniffer to approve them.
In most cases, Brandon is perfectly qualified to approve these, so I’m proposing that Brandon is added to the framework-global-approvers-for-docs-only-changes group.
PR Close#27949
Summary of changes:
- created .github/CODEOWNERS with docs and config similar to the one in .pullapprove.yml
- updated docs
- updated .github/angular-robot.yml to not expect pullapprove status
- removed .pullapprove.yml
The primary motivations behind this change are:
- CODEOWNERS didn't exist when we introduced pullapprove
- CODEOWNERS is a functionality tightly integrated with github which results in better DX
- pullapprove v2 has been very unstable recently causing productivity loss
- pullapprove v2 has been deprecated in favor of v3, which requires and migration
PR Close#27690
We are overincluding files, all of these are not necessary in google3 and should not be synced
because it's only slowing us down.
Related CL: http://cl/225197013
PR Close#27653
When we launched the new issue templates (.github/ISSUE_TEMPLATE/*), we forgot to update these
docs which got stale and needed a refresh.
PR Close#27608
Currently the Github robot is not able to measure the artifacts of the `hello_world` and `todo` bundling tests because those will be only built with the `ivy-only` rule tag. This means that the current CircleCI job that is supposed to upload the size artifacts, does not even build those bundles.
PR Close#27042
These templates take advatange of github's feature that allows
us to define multiple templates and which the UI presents to the
user and lets them choose the most appropriate template.
The goal of this is to tailor the templates to the templates to
various use-cases and bug categories and provide better guidance to
developers filing issues which should result in more efficient
processing of the issue backlog.
PR Close#26918