Commit 5df74f9
doc: remove outdated ARM information from release guide
We no longer produced ARMv6 builds, and the ARMv7 builds are now
cross compiled and are as quick as builds on the other platforms.
PR-URL: #39544
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>1 parent 8eccb11 commit 5df74f9
1 file changed
Lines changed: 0 additions & 25 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -475,26 +475,6 @@ minutes which will prevent Jenkins from clearing the workspace to start a new | |||
| 475 | 475 | one. This isn't a big deal, it's just a hassle because it'll result in another | |
| 476 | 476 | failed build if you start again! | |
| 477 | 477 | ||
| 478 | - ARMv7 takes the longest to compile. Unfortunately ccache isn't as effective on | ||
| 479 | - release builds, I think it's because of the additional macro settings that go in | ||
| 480 | - to a release build that nullify previous builds. Also most of the release build | ||
| 481 | - machines are separate to the test build machines so they don't get any benefit | ||
| 482 | - from ongoing compiles between releases. You can expect 1.5 hours for the ARMv7 | ||
| 483 | - builder to complete and you should normally wait for this to finish. It is | ||
| 484 | - possible to rush a release out if you want and add additional builds later but | ||
| 485 | - we normally provide ARMv7 from initial promotion. | ||
| 486 | - | ||
| 487 | - You do not have to wait for the ARMv6 / Raspberry PI builds if they take longer | ||
| 488 | - than the others. It is only necessary to have the main Linux (x64 and x86), | ||
| 489 | - macOS .pkg and .tar.gz, Windows (x64 and x86) .msi and .exe, source, headers, | ||
| 490 | - and docs (both produced currently by an macOS worker). **If you promote builds | ||
| 491 | - _before_ ARM builds have finished, you must repeat the promotion step for the | ||
| 492 | - ARM builds when they are ready**. If the ARMv6 build failed for some reason you | ||
| 493 | - can use the | ||
| 494 | - [`iojs-release-arm6-only`](https://ci-release.nodejs.org/job/iojs+release-arm6-only/) | ||
| 495 | - build in the release CI to re-run the build only for ARMv6. When launching the | ||
| 496 | - build make sure to use the same commit hash as for the original release. | ||
| 497 | - | ||
| 498 | 478 | ### 10. Test the build | |
| 499 | 479 | ||
| 500 | 480 | Jenkins collects the artifacts from the builds, allowing you to download and | |
@@ -678,11 +658,6 @@ SHASUMS256.txt.sig. | |||
| 678 | 658 | directory. | |
| 679 | 659 | </details> | |
| 680 | 660 | ||
| 681 | - If you didn't wait for ARM builds in the previous step before promoting the | ||
| 682 | - release, you should re-run `tools/release.sh` after the ARM builds have | ||
| 683 | - finished. That will move the ARM artifacts into the correct location. You will | ||
| 684 | - be prompted to re-sign `SHASUMS256.txt`. | ||
| 685 | - | ||
| 686 | 661 | **It is possible to only sign a release by running `./tools/release.sh -s | |
| 687 | 662 | vX.Y.Z`.** | |
| 688 | 663 | ||
0 commit comments