chore: remove zenhub from release process (#25701)

Co-authored-by: Matt Schile <mschile@cypress.io>

.circleci/workflows.yml

@@ -1443,6 +1443,8 @@ jobs:
       - update_known_hosts
       - run: yarn test-npm-package-release-script
       - run: node ./scripts/semantic-commits/validate-binary-changelog.js
+      - store_artifacts:
+          path: /tmp/releaseData
 
   lint-types:
     <<: *defaults

.github/PULL_REQUEST_TEMPLATE.md

@@ -32,6 +32,5 @@ DO NOT DELETE the PR checklist.
 -->
 
 - [ ] Have tests been added/updated?
-- [ ] Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
 - [ ] Has a PR for user-facing changes been opened in [`cypress-documentation`](https://github.com/cypress-io/cypress-documentation)? <!-- Link to PR here -->
 - [ ] Have API changes been updated in the [`type definitions`](https://github.com/cypress-io/cypress/blob/develop/cli/types/cypress.d.ts)?

CONTRIBUTING.md

@@ -476,8 +476,6 @@ We do not continuously deploy the Cypress binary, so `develop` contains all of t
     - `test` - Adding missing or correcting existing tests
 - For user-facing changes that will be released with the next Cypress version, be sure to add a changelog entry to the appropriate section in [`cli/CHANGELOG.md`](./cli/CHANGELOG.md). See [Writing the Cypress Changelog Guide](./guides/writing-the-cypress-changelog.md) for more details.
 - Fill out the [Pull Request Template](./.github/PULL_REQUEST_TEMPLATE.md) completely within the body of the PR. If you feel some areas are not relevant add `N/A` as opposed to deleting those sections. PRs will not be reviewed if this template is not filled in.
-- If the PR is a user facing change and you're a Cypress team member that has logged into [ZenHub](https://www.zenhub.com/) and downloaded the [ZenHub for GitHub extension](https://www.zenhub.com/extension), set the release the PR is intended to ship in from the sidebar of the PR. Follow semantic versioning to select the intended release. This is used to generate the changelog for the release. If you don't tag a PR for release, it won't be mentioned in the changelog.
-  ![Select release for PR](https://user-images.githubusercontent.com/1271364/135139641-657015d6-2dca-42d4-a4fb-16478f61d63f.png)
 - Please check the "Allow edits from maintainers" checkbox when submitting your PR. This will make it easier for the maintainers to make minor adjustments, to help with tests or any other changes we may need.
 ![Allow edits from maintainers checkbox](https://user-images.githubusercontent.com/1271181/31393427-b3105d44-ada9-11e7-80f2-0dac51e3919e.png)
 - All Pull Requests require a minimum of **two** approvals.
@@ -561,10 +559,6 @@ Below are guidelines to help during code review. If any of the following require
 - [ ] There is no irrelevant code to the issue being addressed. If there is, ask the contributor to break the work out into a separate PR.
 - [ ] Tests are testing the code's intended functionality in the best way possible.
 
-#### Internal
-
-- [ ] The original issue has been tagged with a release in ZenHub.
-
 ### Code Review of Dependency Updates
 
 Below are some guidelines Cypress uses when reviewing dependency updates.
@@ -579,7 +573,6 @@ Below are some guidelines Cypress uses when reviewing dependency updates.
 
 - [ ] Code using the dependency has been updated to accommodate any breaking changes
 - [ ] The dependency still supports the version of Node that the package requires.
-- [ ] The PR been tagged with a release in ZenHub.
 - [ ] Appropriate labels have been added to the PR (for example: label `type: breaking change` if it is a breaking change)
 
 ## Releases

cli/CHANGELOG.md

@@ -30,7 +30,7 @@ _Released 02/14/2023 (PENDING)_
 
 ## 12.5.1
 
-_Released 02/10/2023_
+_Released 02/02/2023_
 
 **Bugfixes:**
 

guides/release-process.md

@@ -13,7 +13,6 @@ The `@cypress/`-namespaced NPM packages that live inside the [`/npm`](../npm) di
 - Ensure you have the following permissions set up:
   - An AWS account with permission to access and write to the AWS S3, i.e. the Cypress CDN.
   - Permissions for your npm account to publish the `cypress` package.
-  - Permissions to update releases in ZenHub.
 
 - [Set up](https://cypress-io.atlassian.net/wiki/spaces/INFRA/pages/1534853121/AWS+SSO+Cypress) an AWS SSO profile with the [Team-CypressApp-Prod](https://cypress-io.atlassian.net/wiki/spaces/INFRA/pages/1534853121/AWS+SSO+Cypress#Team-CypressApp-Prod) role. The release scripts assumes the name of your profile is `prod`. Make sure to open the "App Developer" expando for some necessary config values. Your AWS config file should end up looking like the following:
 
@@ -27,19 +26,17 @@ The `@cypress/`-namespaced NPM packages that live inside the [`/npm`](../npm) di
     ```
 
 - Set up the following environment variables:
-  - For the `release-automations` steps, you will need setup the following envs:
+  - For the `release-automations` step, you will need setup the following envs:
     - GitHub token - Found in 1Password.
-    - [ZenHub API token](https://app.zenhub.com/dashboard/tokens) to interact with Zenhub. Found in 1Password.
     - The `cypress-bot` GitHub app credentials. Found in 1Password.
     ```text
     GITHUB_TOKEN="..."
-    ZENHUB_API_TOKEN="..."
     GITHUB_APP_CYPRESS_INSTALLATION_ID=
     GITHUB_APP_ID=
     GITHUB_PRIVATE_KEY=
     ```
 
-  - For purging the Cloudflare cache (part of the `move-binaries` step), you'll need `CF_ZONEID` and `CF_TOKEN` set. These can be found in 1Password.
+  - For purging the Cloudflare cache (needed for the `prepare-release-artifacts` script in step 6), you'll need `CF_ZONEID` and `CF_TOKEN` set. These can be found in 1Password.
       ```text
       CF_ZONEID="..."
       CF_TOKEN="..."
@@ -78,13 +75,14 @@ In the following instructions, "X.Y.Z" is used to denote the [next version of Cy
         - [cypress-realworld-app](https://github.com/cypress-io/cypress-realworld-app) uses yarn and represents a typical consumer implementation.
     - Optionally, do more thorough tests, for example test the new version of Cypress against the Cypress Cloud repo.
 
-2. Confirm that every issue labeled [stage: pending release](https://github.com/cypress-io/cypress/issues?q=label%3A%22stage%3A+pending+release%22+is%3Aclosed) has a ZenHub release set. **Tip:** there is a command in [`release-automations`](https://github.com/cypress-io/release-automations)'s `issues-in-release` tool to list and check such issues. Without a ZenHub release issues will not be included in the right changelog. Also ensure that every closed issue in any obsolete releases are moved to the appropriate release in ZehHub. For example, if the open releases are 9.5.5 and 9.6.0, the current release is 9.6.0, then all closed issues marked as 9.5.5 should be moved to 9.6.0. Ensure that there are no commits on `develop` since the last release that are user facing and aren't marked with the current release.
+2. Ensure all changes to the links manifest to [`on.cypress.io`](https://github.com/cypress-io/cypress-services/tree/develop/packages/on) have been merged to `develop` and deployed.
 
 3. Create a Release PR Bump, submit, get approvals on, and merge a new PR. This PR Should:
-  - Bump the Cypress `version` in [`package.json`](package.json)
-  - Bump the [`packages/example`](../packages/example) dependency if there is a new [`cypress-example-kitchensink`](https://github.com/cypress-io/cypress-example-kitchensink/releases) version
-  - Follow the writing the [Cypress Changelog release steps](./writing-the-cypress-changelog.md#release) to update the [`cli/CHANGELOG.md`](../cli/CHANGELOG.md).
-4. Once the `develop` branch is passing for all test projects with the new changes and the `linux-x64` binary is present at `https://cdn.cypress.io/beta/binary/X.Y.Z/linux-x64/develop-<sha>/cypress.zip`, and the `linux-x64` cypress npm package is present at `https://cdn.cypress.io/beta/npm/X.Y.Z/linux-x64/develop-<sha>/cypress.tgz`, publishing can proceed.
+    - Bump the Cypress `version` in [`package.json`](package.json)
+    - Bump the [`packages/example`](../packages/example) dependency if there is a new [`cypress-example-kitchensink`](https://github.com/cypress-io/cypress-example-kitchensink/releases) version
+    - Follow the writing the [Cypress Changelog release steps](./writing-the-cypress-changelog.md#release) to update the [`cli/CHANGELOG.md`](../cli/CHANGELOG.md).
+
+4. Once the `develop` branch is passing in CI and you have confirmed the `cypress-bot` has commented on the commit with the pre-release versions for `darwin-x64`, `darwin-arm64`, `linux-x64`,`linux-arm64`, and `win32-x64`, publishing can proceed.
 
 5. Log into AWS SSO with `aws sso login --profile <name_of_profile>`. If you have setup your credentials under a different profile than `prod`, be sure to set the `AWS_PROFILE` environment variable to that profile name for the remaining steps. For example, if you are using `production` instead of `prod`, do `export AWS_PROFILE=production`.
 
@@ -142,36 +140,29 @@ In the following instructions, "X.Y.Z" is used to denote the [next version of Cy
     yarn binary-release --version X.Y.Z
     ```
 
-15. If needed, push out any updated changes to the links manifest to [`on.cypress.io`](https://github.com/cypress-io/cypress-services/tree/develop/packages/on).
-
-16. Merge the documentation PR from step 11 and the new docker image PR created in step 12 to release the image.
-
-17. If needed, deploy the updated [`cypress-example-kitchensink`][cypress-example-kitchensink] to `example.cypress.io` by following [these instructions under "Deployment"](../packages/example/README.md).
+15. Merge the documentation PR from step 11 and the new docker image PR created in step 12 to release the image.
 
-18. Update the releases in [ZenHub](https://app.zenhub.com/workspaces/test-runner-5c3ea3baeb1e75374f7b0708/reports/release):
-    - Close the current release in ZenHub.
-    - Create a new patch release (and a new minor release, if this is a minor release) in ZenHub, and schedule them both to be completed 2 weeks from the current date.
-    - Move all issues that are still open from the current release to the appropriate future release.
+16. If needed, deploy the updated [`cypress-example-kitchensink`][cypress-example-kitchensink] to `example.cypress.io` by following [these instructions under "Deployment"](../packages/example/README.md).
 
-19. Once the release is complete, create a Github tag off of the release commit which bumped the version:
+17. Once the release is complete, create a Github tag off of the release commit which bumped the version:
     ```shell
     git checkout develop
     git pull origin develop
     git log --pretty=oneline
-    # copy sha of the previous commit
+    # copy sha of the version bump commit
     git tag -a vX.Y.Z -m vX.Y.Z <sha>
     git push origin vX.Y.Z
     ```
 
-20. Create a new [GitHub release](https://github.com/cypress-io/cypress/releases). Choose the tag you created previously and add contents to match previous releases.
+18. Create a new [GitHub release](https://github.com/cypress-io/cypress/releases). Choose the tag you created previously and add contents to match previous releases.
 
-21. Inside of [cypress-io/release-automations][release-automations], run the following to add a comment to each GH issue that has been resolved with the new published version:
+19. Add a comment to each GH issue that has been resolved with the new published version. Download the `releaseData.json` artifact from the `verify-release-readiness` CircleCI job and run the following command inside of [cypress-io/release-automations][release-automations]:
 
     ```shell
-    cd packages/issues-in-release && npm run do:comment -- --release X.Y.Z
+    cd packages/issues-in-release && npm run do:comment -- --release-data <path_to_releaseData.json>
     ```
 
-22. Confirm there are no issues with the label [stage: pending release](https://github.com/cypress-io/cypress/issues?q=label%3A%22stage%3A+pending+release%22+is%3Aclosed) left
+22. Confirm there are no issues from the release with the label [stage: pending release](https://github.com/cypress-io/cypress/issues?q=label%3A%22stage%3A+pending+release%22+is%3Aclosed) left.
 
 23. Check all `cypress-test-*` and `cypress-example-*` repositories, and if there is a branch named `x.y.z` for testing the features or fixes from the newly published version `x.y.z`, update that branch to refer to the newly published NPM version in `package.json`. Then, get the changes approved and merged into that project's main branch. For projects without a `x.y.z` branch, you can go to the Renovate dependency issue and check the box next to `Update dependency cypress to X.Y.Z`. It will automatically create a PR. Once it passes, you can merge it. Try updating at least the following projects:
     - [cypress-example-todomvc](https://github.com/cypress-io/cypress-example-todomvc/issues/99)

scripts/semantic-commits/get-binary-release-data.js

@@ -70,7 +70,7 @@ const getReleaseData = async (latestReleaseInfo) => {
       return
     }
 
-    const { data: pullRequest } = await octokit.request('GET /repos/{owner}/{repo}/pulls/{pull_number}', {
+    const { data: pullRequest } = await octokit.request('GET /repos/{owner}/{repo}/pull/{pull_number}', {
       owner: 'cypress-io',
       repo: 'cypress',
       pull_number: references[0].issue,
@@ -92,6 +92,20 @@ const getReleaseData = async (latestReleaseInfo) => {
     })
   }))
 
+  console.log('Next release version is', nextVersion)
+
+  console.log(`${prsInRelease.length} pull requests have merged since ${latestReleaseInfo.version} was released.`)
+
+  prsInRelease.forEach((link) => {
+    console.log('  -', link)
+  })
+
+  console.log(`${issuesInRelease.length} issues addressed since ${latestReleaseInfo.version} was released.`)
+
+  issuesInRelease.forEach((link) => {
+    console.log('  -', link)
+  })
+
   return {
     nextVersion,
     changedFiles,
@@ -112,23 +126,5 @@ if (require.main !== module) {
 (async () => {
   const latestReleaseInfo = await getCurrentReleaseData()
 
-  const {
-    changelogData,
-    issuesInRelease,
-    prsInRelease,
-  } = await getReleaseData(latestReleaseInfo)
-
-  console.log('Next release version is', changelogData.nextVersion)
-
-  console.log(`${prsInRelease.length} user-facing pull requests have merged since ${latestReleaseInfo.version} was released.`)
-
-  .prsInRelease.forEach((link) => {
-    console.log('  -', link)
-  })
-
-  console.log(`${issuesInRelease.length} user-facing issues addressed since ${latestReleaseInfo.version} was released.`)
-
-  issuesInRelease.forEach((link) => {
-    console.log('  -', link)
-  })
+  await getReleaseData(latestReleaseInfo)
 })()

scripts/semantic-commits/get-current-release-data.js

@@ -7,17 +7,20 @@ const childProcess = require('child_process')
 const getCurrentReleaseData = (verbose = true) => {
   verbose && console.log('Get Current Release Information\n')
 
-  const stdout = childProcess.execSync('npm info cypress --json')
-  const npmInfo = JSON.parse(stdout)
+  const stdout = childProcess.execSync('yarn info cypress --json')
+  const { data: npmInfo } = JSON.parse(stdout)
 
   const latestReleaseInfo = {
     version: npmInfo['dist-tags'].latest,
+    distTags: npmInfo['dist-tags'],
     commitDate: npmInfo.buildInfo.commitDate,
     buildSha: npmInfo.buildInfo.commitSha,
   }
 
   verbose && console.log({ latestReleaseInfo })
 
+  latestReleaseInfo.versions = npmInfo.versions
+
   return latestReleaseInfo
 }
 

scripts/semantic-commits/validate-binary-changelog.js

@@ -1,12 +1,14 @@
 /* eslint-disable no-console */
+const fs = require('fs')
+const path = require('path')
 const { validateChangelog } = require('./validate-changelog')
 const { getCurrentReleaseData } = require('./get-current-release-data')
 const { getReleaseData } = require('./get-binary-release-data')
 const checkedInBinaryVersion = require('../../package.json').version
 
 const changelog = async () => {
   const latestReleaseInfo = await getCurrentReleaseData()
-  let hasVersionBump = checkedInBinaryVersion !== latestReleaseInfo.version
+  const hasVersionBump = !latestReleaseInfo.versions.includes(checkedInBinaryVersion) // account for branches behind develop
 
   if (process.env.CIRCLECI) {
     console.log({ checkedInBinaryVersion })
@@ -18,13 +20,23 @@ const changelog = async () => {
     }
   }
 
+  const releaseData = await getReleaseData(latestReleaseInfo)
+
+  const dirPath = path.join(path.sep, 'tmp', 'releaseData')
+
+  if (!fs.existsSync(dirPath)) {
+    fs.mkdirSync(dirPath)
+  }
+
+  fs.writeFileSync(path.join(dirPath, 'releaseData.json'), JSON.stringify(releaseData, null, 2))
+
+  console.log('Release data saved to', path.join(dirPath, 'releaseData.json'))
+
   const {
     nextVersion,
     changedFiles,
     commits,
-  } = await getReleaseData(latestReleaseInfo)
-
-  console.log({ nextVersion })
+  } = releaseData
 
   return validateChangelog({
     nextVersion,