Angular Development Infrastructure
angular / dev-infra Goto Github PK
View Code? Open in Web Editor NEWAngular Development Infrastructure
License: MIT License
Angular Development Infrastructure
License: MIT License
The problem
Currently, the angular/dev-infra repository relies on a pre-commit git hook for building the lock-closed
action, in order to ensure that the changes made in the source code (e.g. src/main.ts) will also be included in the built script that is actually used when running the action (i.e. lib/bundle.js).
However, it is easy to miss this step (for example if someone submit a PR via the GitHub UI or commits review suggestions via the GitHub UI or has git hooks disabled, etc.).
This can result in issues such as angular/angular#39358, where the fix is in the source code but not in the built script (that is actually used).
The solution
Introduce CI checks to angular/dev-infra
that would ensure that the built script (lib/bundle.js
) is indeed up-to-date with the source code (src/main.ts
).
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.
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?
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.
profile_all.js --write baseline.json
profile_all.js --read baseline.json
For now this is enough to see if the number are stable/predictable.
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)
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/..."],
)
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:
angular-package-validator
tool that we could use for all Angular-related projects.Other related checks
cdk/testing
or material/testing
Open to other ideas here.
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.
We should check bash scripts for problematic patterns, particularly patterns that are inconsistent between macOS and Linux.
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.
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.
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.
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
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:
mat-
, cdk-
) used in paragraphs without code formattingDuring 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.
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
When a new release is published, it includes information in the changelog about which PRs are included and which issues are fixed in the new version. The publishing process should include automated notification hooks so that those following the issues/PRs will see the message and know that it's resolved.
I'm making an issue for this per this comment from @IgorMinar.
In pr/merge/defaults/labels.ts > getDefaultTargetLabelConfiguration(), there should be a check to ensure that we don't try to merge a PR to latest/rc/next branches if the PR is targeting a specific branch (for example, here).
This was originally discussed in angular/angular#38656 (comment).
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
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
Blocked by #15
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
This is a migration away from the check being done in the ngbot
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.