Commit Graph

8 Commits

Author SHA1 Message Date
Joey Perrott 3d7e207a25 fix(dev-infra): detect multiple target labels as invalid (#40156)
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
2021-01-11 09:56:22 -08:00
George Kalpakas 6947ceaf44 refactor(dev-infra): several code style and typo fixes (#39135)
This commit addresses comments from [my review][1] on PR #38656 (which
was merged without comments addressed). The changes are mostly related
to code style and typos.

[1]: https://github.com/angular/angular/pull/38656#pullrequestreview-482129333

PR Close #39135
2020-10-12 10:47:13 -07:00
Paul Gschwendtner 9dccaa9570 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-28 16:11:40 -04:00
Paul Gschwendtner c1b47bcfaa refactor(dev-infra): expose logic for dealing with LTS branches (#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
2020-09-28 16:11:40 -04:00
Paul Gschwendtner d7ff8d765c refactor(dev-infra): use shared github repo interface (#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
2020-09-28 16:11:40 -04:00
Paul Gschwendtner b041c118e3 refactor(dev-infra): expose version for determined release trains (#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
2020-09-28 16:11:39 -04:00
Paul Gschwendtner ebc0e46501 refactor(dev-infra): improve error message for unexpected version branches (#38622)
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
2020-08-31 09:29:58 -07:00
Paul Gschwendtner f0766a4474 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-08-05 10:53:17 -07:00