iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/dev-infra/pr/merge/BUILD.bazel

60 lines
1.8 KiB
Python
Raw Normal View History

build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#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. PR Close #39182
2020-06-25 04:32:41 -04:00
load("@npm//@bazel/typescript:index.bzl", "ts_library")
feat(dev-infra): provide organization-wide merge-tool label configuration (#38223) 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
2020-07-24 11:47:30 -04:00
load("//tools:defaults.bzl", "jasmine_node_test")
feat(dev-infra): integrate merge script into ng-dev cli (#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
2020-05-15 11:21:01 -04:00
ts_library(
name = "merge",
feat(dev-infra): provide organization-wide merge-tool label configuration (#38223) 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
2020-07-24 11:47:30 -04:00
srcs = glob(
["**/*.ts"],
exclude = ["**/*.spec.ts"],
),
feat(dev-infra): integrate merge script into ng-dev cli (#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
2020-05-15 11:21:01 -04:00
module_name = "@angular/dev-infra-private/pr/merge",
refactor(dev-infra): create ng-dev executable locally in the repo (#39089) 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
2020-10-01 19:06:56 -04:00
# prodmode target must be set to es5 as the Ora class, which is extended is not a proper
# prototyped object.
prodmode_target = "es5",
feat(dev-infra): integrate merge script into ng-dev cli (#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
2020-05-15 11:21:01 -04:00
visibility = ["//dev-infra:__subpackages__"],
deps = [
"//dev-infra/commit-message",
refactor(dev-infra): move common versioning tooling to shared location (#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
2020-09-09 08:42:34 -04:00
"//dev-infra/release/config",
"//dev-infra/release/versioning",
feat(dev-infra): integrate merge script into ng-dev cli (#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
2020-05-15 11:21:01 -04:00
"//dev-infra/utils",
"@npm//@octokit/rest",
"@npm//@types/inquirer",
"@npm//@types/node",
feat(dev-infra): provide organization-wide merge-tool label configuration (#38223) 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
2020-07-24 11:47:30 -04:00
"@npm//@types/node-fetch",
feat(dev-infra): expose script for determining merge branches (#37217) 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
2020-05-20 06:50:18 -04:00
"@npm//@types/semver",
feat(dev-infra): integrate merge script into ng-dev cli (#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
2020-05-15 11:21:01 -04:00
"@npm//@types/yargs",
"@npm//chalk",
refactor(dev-infra): use graphql to query PRs in merge tooling (#41459) Migrate to use graqhql to query for PR information during the validation and preperation portions of the pr merge tooling. PR Close #41459
2021-04-06 10:43:21 -04:00
"@npm//typed-graphqlify",
feat(dev-infra): integrate merge script into ng-dev cli (#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
2020-05-15 11:21:01 -04:00
],
)
feat(dev-infra): provide organization-wide merge-tool label configuration (#38223) 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
2020-07-24 11:47:30 -04:00
ts_library(
name = "test_lib",
testonly = True,
srcs = glob(["**/*.spec.ts"]),
deps = [
":merge",
refactor(dev-infra): move common versioning tooling to shared location (#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
2020-09-09 08:42:34 -04:00
"//dev-infra/release/config",
"//dev-infra/release/versioning",
feat(dev-infra): provide organization-wide merge-tool label configuration (#38223) 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
2020-07-24 11:47:30 -04:00
"//dev-infra/utils",
"@npm//@types/jasmine",
"@npm//@types/node",
"@npm//@types/node-fetch",
"@npm//nock",
],
)
jasmine_node_test(
name = "test",
# Disable the Bazel patched module resolution. It always loads ".mjs" files first. This
# breaks NodeJS execution for "node-fetch" as it uses experimental modules which are not
# enabled in NodeJS. TODO: Remove this with rules_nodejs 3.x where patching is optional.
# https://github.com/bazelbuild/rules_nodejs/commit/7d070ffadf9c3b41711382a4737b995f987c14fa.
args = ["--nobazel_patch_module_resolver"],
deps = [
":test_lib",
"@npm//node-fetch",
"@npm//semver",
],
)