We should have the ability to run a test of tests against the yet to be released versions of the npm packages. Might need to create a docker image that will set up a local NPM registry and test out each of the projects.
Example: When a major release is done, we should have the capability for Tools to run their tests against the x.0.0 framework release before its actually on NPM

Provide a common importable function to setup the WORKSPACE for downstream repositories, retrieving necessary dependencies and setting up things like node modules.

This would allow us to sychronize the versions of node and rules_nodejs being used by repositories.

Before:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# Fetch rules_nodejs so we can install our npm dependencies
http_archive(
    name = "build_bazel_rules_nodejs",
    sha256 = "5c40083120eadec50a3497084f99bc75a85400ea727e82e0b2f422720573130f",
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/4.0.0-beta.0/rules_nodejs-4.0.0-beta.0.tar.gz"],
)

load("@build_bazel_rules_nodejs//:index.bzl", "node_repositories", "yarn_install")

node_repositories(
    node_repositories = {
        "14.17.0-darwin_amd64": ("node-v14.17.0-darwin-x64.tar.gz", "node-v14.17.0-darwin-x64", "7b210652e11d1ee25650c164cf32381895e1dcb3e0ff1d0841d8abc1f47ac73e"),
        "14.17.0-linux_amd64": ("node-v14.17.0-linux-x64.tar.xz", "node-v14.17.0-linux-x64", "494b161759a3d19c70e3172d33ce1918dd8df9ad20d29d1652a8387a84e2d308"),
        "14.17.0-windows_amd64": ("node-v14.17.0-win-x64.zip", "node-v14.17.0-win-x64", "6582a7259c433e9f667dcc4ed3e5d68bc514caba2eed40e4626c8b4c7e5ecd5c"),
    },
    node_version = "14.17.0",
)

yarn_install(
    name = "npm",
    package_json = "//:package.json",
    yarn_lock = "//:yarn.lock",
)

After:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# Fetch rules_nodejs so we can install our npm dependencies
http_archive(
    name = "angular-dev-infra",
    sha256 = "...",
    urls = ["https://github.com/angular/dev-infra-private-builds/..."],
)

See: angular/angular#33186

I would like to have a separate circle-ci job which would execute the profile_all.js to measure if the PR is making things better or worse.

1. Revert PR in job and run profile_all.js --write baseline.json
2. Restore PR in job and run profile_all.js --read baseline.json

For now this is enough to see if the number are stable/predictable.

We should check bash scripts for problematic patterns, particularly patterns that are inconsistent between macOS and Linux.

During the release process, when the new Changelog entry is generated and added to the CHANGELOG.md file, we should leverage the formatFiles function from ng-dev/format/format to format the newly modified CHANGELOG.md file.

This notably presents as a failure on CI for CLI as markdown files are formatted using prettier.

When someone posts to an issue a message like "Any updates?", the bot would immediately respond with something like

Updates will appear on this issue when progress is made. You
can subscribe to the issue for updates and use the "thumbs up"
reaction to register your interest.

<sub>_This automated message made by a bot_</sub>

Would have to have some rate limit to avoid trolls spamming it

Add a separator between changelog entries in CHANGELOG.md files to allow us to easily do things like archiving or filtering when updating changelogs.

Proposal:

<a name="1.2.3"></a>
# 1.2.3 (2000-01-01)
### ng-dev
| Commit | Type | Description |
| -- | -- | -- |
| [abc123](https://github.com/angular/dev-infra/commit/abc123) | feat | **release:** Add changlog separators |

<!-- CHANGELOG SPLIT MARKER -->

<a name="1.2.2"></a>
# 1.2.2 (2000-01-01)

• Create ng-dev based tooling for checking if a list of files is being synced into google3
• Create Github Action to determine if the files changed in a repository sync as expected into google3

This is a migration away from the check being done in the ngbot

We currently have no automated tests for the actual npm package we produce. We should, at the very least, run our e2e tests against the real packages.

It would additionally be good to test the components against an Angular CLI application. It might be best, then, to change our e2e app to be an Angular CLI application.

Some other possibilities worth discussion:

• Creating a general angular-package-validator tool that we could use for all Angular-related projects.
• Clone and run the tests for angular.io and/or material.angular.io with the packages

Other related checks

• Ensure that the release doesn't include cdk/testing or material/testing

Open to other ideas here.

cc @josephperrott

Currently we have a structure like this.

ng-dev/pr                   
├── checkout                │ Checks out a PR locally to modify
├── check-target-branches   │ Prints the branches a pr would merge into
├── common                  │ 
│   └── checkout-pr.ts      │ Actual logic for checking out a PR used by checkout and rebase
├── discover-new-conflicts  │ Determines what other pending PRs can merge cleanly after a PR merges
├── merge                   │ Merges PRs (also houses the config.ts)
└── rebase                  │ Attempts to rebase a PR and push the rebased commits back to upstream

We have had a few people ask for something akin to ng-dev pr check <pr-number>, which would return the pr title, number, if it needs approvals, what branches it would land in etc. I think we should transform the check-target-branches into this command.

I would propose that we then separate out a few pieces that can be reused both literally in other files/commands and conceptually.

ng-dev/pr                   
├── checkout                │ Stays the same
├── info                    │ Leverage the validation logic and PullRequest object to get all PR info
├── common                  │ 
│   ├── checkout-pr         │ Stays the same
│   ├── get-pr              │ Common util to get PR from github as a consistent PullRequest object
│   ├── targeting           │ Target labels and utils to get a target branch for a PR, etc
│   └── validation          │ Validate that a PR meets all of the expected criteria for the repo
├── discover-new-conflicts  │ Stays the same
├── merge                   │ Merges PR, using the new common utils
└── rebase                  │ Stays the same

• config.ts should move up one level into ng-dev/pr
• MergeConfig should be renamed to something like PullRequestConfig

Most of the time, people create a pull request and forget about approving/updating the API golden files. This is commonly seen on community PRs because creating a merge-ready PR involves a lot of steps.

It would be helpful if there is a way to update/approve the goldens through the Github UI. That way, one doesn't have to go back to a failing PR to update the goldens, and it can be useful for community PRs where goldens need to be updated (saving time; so that one doesn't need to fetch&push the PR)

• Framework
• CLI
• Components

I would like a markdown lint for the components repo, and we probably want this for other repos as well. Bonus points for a markdown formatter as good as (or close to) the one we have inside Google.

Some lints I care about:

• Using the correct headers (especially for integration with our docs site)
• Code fences have a valid language
• Max line length (100)
• Certain HTML tags (e.g. mat-, cdk-) used in paragraphs without code formatting

• Set up for Framework
• Set up for Componentse
• Set up for CLI

Blocked by #15

• Set up on framework
• Set up on components
• Set up on cli

• Set up on framework
• Set up on components
• Set up on cli

For the components repo, we want to be able to lint Angular templates. CLI would probably benefit from this as well, and maybe framework just for tests.

Context: angular/components#18588

Create script to change the dist-tag values on a set of NPM packages. Usage is for situations like releasing to @next initially and then wanting to just promote the package to @latest

Example: One script that based on repo config would automatically set the tag on all of Components packages - @angular/{material,cdk,material-experimental,cdk-experimental,etc} all at one

Security Policy SECURITY.md is out of compliance, status:
SECURITY.md not found.
Go to https://github.com/angular/dev-infra/security/policy to enable.

Issue created by Allstar. https://github.com/ossf/allstar

We've been doing a lot of manual porting from Github to Jira, which is probably not a good use of time. In the past, we had a Github label that we could apply if we wanted to sync something to Jira, which was super convenient. I think there may have been permissions issues that prevented us from doing this long-term, but it would be great if we could revisit how this might be possible.

Example: feat: make mocha a zone module. (#34719)

All feature commits should have a scope. This has been problematic in angular/angular because some scopes should be omitted from the CHANGELOG (e.g. zone.js), but they can't be if the scope isn't listed.

The validation task that we use should catch this case and throw.

Security Policy Outside Collaborators is out of compliance, status:
Found 1 outside collaborators with push access.

Issue created by Allstar. https://github.com/ossf/allstar

If the presubmit diff edits the ng_module.bzl file in some way, the diff from the flip CL isn't applied to the file, and the presubmit runs with VE instead of Ivy.

We used to have this for components, but it's still super useful. It helps non-Googlers know who to contact if there are issues with getting PRs merged.

• Move everything on framework
• Move everything on components
• Move everything on cli

• Set up on framework
• Set up on components
• Set up on cli

When I apply "PR action: rerun CI at HEAD" label to a pr on a/a repo, I see that the ng-bot removes the label (as expected), but doesn't trigger a rebuild of the PR on CircleCI.

Is there a known reason why this fails? Could this be fixed?

The merge script currently requires developers to add BREAKING CHANGES: , or the breaking changes label when there are breaking changes. We should automatically add the label through a Github action if a breaking changes marker is found in a commit message.

On components, we manually label issues from Googlers. It would be great if this were automated, though it would require cooperation with Google's OSPO.

Security Policy Branch Protection is out of compliance, status:
PR Approvals not configured for branch main

Issue created by Allstar. https://github.com/ossf/allstar

During any usage of actions based off of BranchOffNextBranchBaseAction we should prompt the user to select whether the newly created branch should be a major or minor.