From 1f72505356a93285a129e5dda838fdce0e5ca074 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Thu, 29 Oct 2026 18:10:55 +0100 Subject: [PATCH] doc: remove CI lockdown steps from security releases The CI is no longer locked down for security releases. The pre-release paragraph describing the lockdown procedure was already dropped from releases.md in nodejs/node#64198, but the release day steps and two inline notes still told stewards and releasers to wait for it. Remove the remaining references: * Drop 'Lock down the CI' and 'Unlock the CI' from the release day checklist in security-release-process.md and renumber the steps. * Drop the note in releases.md telling releasers not to run CI on nodejs-private pull requests until the lockdown. * Drop the security release details block under the CI step that deferred to the lockdown coordinated with the Build Working Group. Refs: https://github.com/nodejs/node/pull/64198 Signed-off-by: Ulises Gascon --- doc/contributing/releases.md | 12 ------------ doc/contributing/security-release-process.md | 12 +++--------- 2 files changed, 3 insertions(+), 21 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index f10407720f3b..9663c594d73a 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -341,9 +341,6 @@ known, additionally include `CVE-ID: CVE-XXXX-XXXXX` in the commit metadata. Make sure to sign and push to resulting commit to the private repository and not the public one. -**Note**: Do not run CI on the PRs in `nodejs-private` until CI is locked down. -You can integrate the PRs into the proposal without running full CI. - ### 2. Create a new branch for the release @@ -714,15 +711,6 @@ A number of the modules tested by CitGM are not completely reliable so differences shown by the comparison are not immediately cause for concern. -
-Security release - -If there are private security patches, do not run any CI jobs on the proposal -until CI has been locked down. The security steward should be coordinating this -with the Build Working Group. - -
- #### 7.1 Updating the release _(optional)_ Sometimes a release might be deferred to the subsequent day due to several diff --git a/doc/contributing/security-release-process.md b/doc/contributing/security-release-process.md index 7444707774fb..07e75bf24810 100644 --- a/doc/contributing/security-release-process.md +++ b/doc/contributing/security-release-process.md @@ -147,20 +147,14 @@ security announcements for more information. ## Release day -* [ ] 1\. **Lock down the CI:** - * Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`. - -* [ ] 2\. **Release:** +* [ ] 1\. **Release:** * Verify the CI is green on all release proposals (test-V8, CITGM, etc). * Follow the [release process](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md). -* [ ] 3\. **Unlock the CI:** - * Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`. - -* [ ] 4\. **Publish Post-Release Blog Post:** +* [ ] 2\. **Publish Post-Release Blog Post:** * Publish the post-release blog post on the `nodejs/nodejs.org` repository. -* [ ] 5\. **Notify the community:** +* [ ] 3\. **Notify the community:** * Notify the community that the security release has gone out: * [ ] Slack: `#nodejs-social` * [ ] [docker-node](https://github.com/nodejs/docker-node/issues)