This commit introduces a new `pnpm run devtools:release` command to streamline the Angular DevTools release process.
The command automates the entire release workflow, including checking for new commits, updating version numbers, creating a release commit, and guiding the user through the publishing steps for both Chrome and Firefox extensions.
The `devtools/docs/release.md` documentation has been updated to reflect the use of this new command, providing a single entry point for the release process.
A new script `devtools/tools/release.mts` has been added to implement the release logic, and `package.json` has been updated to include the new script.
PR Close#63599
This makes few edits based on feedback and observations from a previous release:
1. Moves `git pull` command before initial `git log` to make sure we're up to date before checking if a release is necessary.
2. Updates both `git log` commands to limit to `fix`, `feat`, and `perf` changes. This ignores more than just `refactor`, such as `build`, `ci`, etc. and should be more meaningful to end users.
* I considered doing something with `Revert` commits, but opted not to. Instead, it will treat this just like their original commit. This does mean we might send a slightly more complicated changelog than it needs to be, but it's not worth making these commands even weirder.
3. Removes install step prior to bumping the version numbers, as its just not needed and we have to reinstall later anyways.
4. Switches PR target from `patch` to `minor`. We only need to merge this to the `main` branch, and it's not worth the effort to keep the `patch` branch in sync.
5. Switches source code zip command to `git archive`. This is more portable than `zip *`, which depends on the shell configuration to determine what is included in `*` (mainly whether or not that includes dotfiles such as `.nvmrc` and `.bazelrc`).
PR Close#62352
This seems to be helpful for Mozilla reviewers to reproduce the build without encountering Bazel errors like:
```
Server terminated abruptly (error code: 14, error message: 'Socket closed', log file: '/home/parallels/.cache/bazel/_bazel_parallels/ae710c6507eb251f9511ac4228641059/server/jvm.out')
```
`--local_ram_resources` is also useful, but I'm not sure what to set it to by default or how necessary it is, so let's just start with `--jobs 4` for now. The 4 is arbitrary as I don't have insight into how many jobs are actually appropriate, but we can go with this for now and tweak the number later if it still causes issues.
PR Close#62015
This makes a few changes to try to smooth over the process:
1. Updates changelog commands to filter out `refactor` commits.
2. Tweaks the changelog command to generate a markdown list for easy copy-pasting.
3. Links directly to the store pages to cut down on clicks.
4. Moves the source code section a bove the reviewer note and changelog, to match the ordering of the Firefox Add Ons form.
PR Close#61883
The release process overview is out of date and does not accurately reflect section headers. It's not worth the maintenance effort of keeping it in sync with the rest of the doc.
Added a step 0 to check if there's actually anything to release, reusing the command from later in the doc.
Also makes a few random small corrections to reflect the new release process.
PR Close#60892
This moves the commit step to the start of the process and releases after merging it. This has two key benefits:
1. The commit history now reflects the actual release (ex. any DevTools commits before the release commit are actually included in that release). Previously the changes in a release were dictated by the release PR branch, which is an ephemeral target. Other PRs may be merged to `main` before the release PR, and those changes would not be included in that DevTools release.
2. We can now compute a changelog based on this more accurate history.
The downside to this change is that release PRs are now blocking releases in a way they weren't before (which is likely desirable in the grand scheme of things), meaning we need to be more diligent about merging them in a timely manner.
I added a short script for listing DevTools commits since the last release, taking advantage of the more accurate commit history. This should make changelog generation a lot easier, even if there's still a manual process of rewriting the commit message into a line item in release notes.
Also made a few minor cleanup changes such as escaping the markdown in the suggested reviewer note so it can be more easily copy-pasted from the rendered format of this doc.
PR Close#60646
`-x dist/` never worked for reasons I don't really understand. Historically I've just deleted `dist/` before zipping. I tried a few different approaches, but all of them lead to some form of "Name not matched" error in `zip` of the `dist/` directory. Instead I just opted to delete `dist/` as part of the zipping command.
The link to recent DevTools commits seems good enough to manually write a changelog. All relevant commits should be using `refactor(devtools)`, so the string "devtools" should definitely be in there.
PR Close#59792
Mozilla requires add-ons to have reproducible builds and this is managed directly by human reviewers and need to understand how to build Angular DevTools correctly. This commit defines a reproducible way of building Angular DevTools which is useful for reviewers and contributers.
The actual changes I made include:
1. Moving local development content into `devtools/README` (deleting `devtools/DEVELOPING.md`) and explicitly stating the Node version as well as global Yarn install to be clear about the correct way to build the extension. This should make it easier for reviewers to understand and reproduce builds.
2. Moving release instructions to a separate doc to reduce noise as well as making some minor clean ups there.
I briefly considered pointing reviewers at a new `devtools/docs/reviewers.md` doc, but decided against it because I want these instructions to be maintained in a single location where contributors and reviewers use the same content. This way any changes don't miss one of these sets of users. If reviewers have trouble with this format (dev builds isn't useful to reviewers and some content is repeated from other docs for contributors) then we can consider splitting out to a separate `reviewers.md` file. But until then, I'd like to try sharing this content and see how it works out in practice.
PR Close#55406
