Closes [#47557](https://github.com/sourcegraph/sourcegraph/issues/47557)
This is a somewhat gruesome PR to read, so sorry for that. I wanted to
keep this change atomic so it's easy to revert if we need.
So, I set out to automate the dates in the release config and realized
that fundamentally the architecture of the release tool was coupled to
this config in a way that was making life more difficult than it needed
to be.
This PR refactors the release config in the release tool. It uses an
entirely new schema, and for the most part automates every interaction
anyone will have with the config. The new schema is designed to do a few
things:
1. Deprecate the annoying cached version by specifying two sections of
the release config, both a definition and an active releases field.
Anything in the active releases is considered in progress.
2. Sets up some architecture to support multi-release functionality from
the release tool. There are guard rails right now since this isn't fully
supported.
Also,
* Automatically detect and suggest versions
* Automatically generate release dates from a specified date or current
time
* QOL changes to flow to the appropriate commands if the release config
is in the wrong state. For example it will prompt for input if the
config is empty for a given version for commands that require a valid
state
* Guardrails around every interaction I could find that causes problems
* New commands to interact with the release config (activate-release,
deactivate-release, util:previous-version)
## Usage
To set a release as active, either use the activate command directly
```
pnpm run release release:activate-release
```
or transitively through another dependent command.
All release commands that interact with the _current_ release will read
from the active release in the release config.
All release commands that interact with _future_ releases will read and
write to the release definitions in the release config.
To deactivate the release:
```
pnpm run release release:deactivate-release
```
Most of these steps are not explicitly mandatory, and are coupled into
other relevant commands (for example closing the release will deactivate
the release also).
To add new scheduled release definitions:
```
pnpm run release release:prepare
```
To remove scheduled releases:
```
pnpm run release release:remove
```
To determine previous versions:
```
pnpm run release util:previous-version 4.2.1
Getting previous version from: 4.2.1...
4.2.0
```
or
```
pnpm run release util:previous-version
Getting previous version...
4.4.2
```
## Test plan
I did a lot of manual testing since so many commands were impacted. Some
example output is below, and here is an example of a fake issue that was
generated from the release tool:
https://github.com/sourcegraph/sourcegraph/issues/47760
Example of how the input will flow if the config is not in the correct
state, including version suggestions:
```
> @sourcegraph/dev-release@0.0.1 release /Users/coury@sourcegraph.com/Documents/code/sourcegraph/dev/release
> ts-node --transpile-only ./src/main.ts "release:status"
No active releases are defined! Attempting to activate...
Next minor release: 4.5.0
Next patch release: 4.4.3
Enter the version to activate:
```
```
> @sourcegraph/dev-release@0.0.1 release /Users/coury@sourcegraph.com/Documents/code/sourcegraph/dev/release
> ts-node --transpile-only ./src/main.ts "release:status"
No active releases are defined! Attempting to activate...
Next minor release: 4.5.0
Next patch release: 4.4.3
Enter the version to activate: 4.4.3
Attempting to detect previous version...
Detected previous version: 4.4.2
Release definition not found for: 4.4.3, enter release information.
Enter the release date (YYYY-MM-DD). Enter blank to use current date:
Using current time: 2023-02-16T11:01:34.710-08:00
Enter the github username of the release captain: coury-clark
Enter the slack username of the release captain: coury
Version created:
{
"codeFreezeDate": "2023-02-09T10:01:34.710-08:00",
"securityApprovalDate": "2023-02-09T10:01:34.710-08:00",
"releaseDate": "2023-02-16T10:01:34.710-08:00",
"current": "4.4.3",
"captainGitHubUsername": "coury-clark",
"captainSlackUsername": "coury"
}
Release: 4.4.3 activated!
```
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
## App preview:
-
[Web](https://sg-web-cclark-refactor-release-config.onrender.com/search)
Check out the [client app preview
documentation](https://docs.sourcegraph.com/dev/how-to/client_pr_previews)
to learn more.
Bazel's rules_js rely on the pnpm package manager. To simplify the integration, we're migrating to pnpm from our current package manager — yarn. Another reason to migrate is that pnpm is cool and fast. 😉
* Use TypeScript project references
* Use JS for config files
* Lint only ts to work around crash on JS files
* Fix codeowners
* Tune VS Code config
* skipDefaultLibCheck
* Add Buildkite grouping to foreach-ts-project.sh
* Add better logs for pre-build.sh
* Export interface to fix private name error
* Add top-level catch-all owner for new TS files
* Add dev/release to linted projects
* Standardize on the same dependencies
This reduces the amount of packages needing to be updated.
* Configure @beyang as owner for Renovate PRs
* Add TSLint
* Add yarn
