Currently we still cannot cut the Github release automatically because
the publish script does not have API access. Though it's sometimes
not quite clear for the caretaker what he needs to do manually. In
the meanwhile we make this _slighty_ more clear by adding a
note that indicates where the release notes should be copy-pasted
to.
Currently the publish script prints an error if the release tag does not exist locally yet. This is not expected since the function
that calls `git` to check if a given tag exists, returns a boolean and should not additionally print the git `stderr`.
Note we can also look into attaching the release notes automatically, but since the release notes are making the URL too large and Github denies too large URL's, this is something we can explore in a follow-ups.
* build: fix version bumps not detected in release script
* build: allow recovering from failed publish script
* Currently if anything fails after the creating the local git tag, it's not possible to just re-run the release script because the script fails with an error saying that the local tag already exists. We can be smart about this and just use the existing tag if it refers to the expected SHA.
* Additionally if anything fails after pushing the release tag to the remote, it's not possible to re-run the release script because the tag exists remotely. We can be smart about this and just use the remote tag if it refers to the expected SHA.
**Note**: In a follow-up I want to wire up the release output validations as part of a CircleCI job. It just makes sense to keep all of these release output validations in the same place.
References https://github.com/angular/material2/issues/12877
* Based on request from Vivian and the comments on the last changelog
PR, we don't want to report experimental package changes (yet). In order
to make this easier for the caretaker when doing releases, we just
filter these out automatically.
* Since we filter out duplicate changelog entries it can happen that a `commitGroup` shows up without any commits. e.g. there would be an empty section for `"Features"`.
* Based on a recent chat with Miles, it would be good if we default the `Is pre-release?` question to `false` and also print an URL if the status checks for a given branch fail (this should be just more convenient to see what failed)
* Converts the changelog script into plain TypeScript. This makes it easier to integrate it into the _interactive_ staging script
* Fixes that the "Is this is a pre-release" prompt is not returning a boolean.
* No longer runs the staging script with Bazel because `ts-node` is more convenient and also we can be more context-aware (e.g. paths)
Paul Gschwendtner