[Starlingx-discuss] [Build] Trying to outline RC and Release Builds - Please review
Build Team and any interested parties: Please review this outline of the RC and Release build preparations. After the latest release, I wanted to make sure that we document what needs to be done and update the tools we have to make this process as automated as possible. This is very rough, I probably forgot a step or 5! I do not include any Jenkins/Cengn related steps since I was not involved in those. I hope that we can also discuss in tomorrow's Build team meeting, but let's get comments here on the email list. Thanks Sau! For the Initial Release Candiate Branch Creation: 1) Branch for Release Candidate (RC) only, no tagging initially. This includes adjusting the .gitreview files (this is currently handled by the stx-tools/release scripts. 2) Update Manifest repo (both default and layered xml files) to point to newly created RC branch via default revision branch name (not a tag) 3) Build RC branch, continues to use master for Layer configuration - This generates all the initial artifacts that can then be used for future rc builds. 4) Wait for Sanity test results 5) Use generated CONTEXT.sh file to update the manifests (as above) to point to all the correct and "static" git repo HEADS. 6) Update the tools/centos-mirror-tools/config/centos layer configuration and repo files to point to the newly created RC location on cengn. 7) Tag all repos with RC tag, we need to clarify format of this tag we are using vX.Y.Z.rc0 vs Release tag X.Y.Z no "v" prefix, I think we need to be more consistent here. (all repos includes manifest) RC builds should now be using RC artifacts Final Build / Tagging for Release Builds: 1) Build from RC branch using RC Artifact (probably need sanity test results) 2) artifacts are copied to release/<relnum> are when approved 3) Update manifest repo with default revision pointing to the release tag (not the branch name), update any static git reference is needed. 4) Update the stx-tools layer configuration and repo files to point to the release/<relnum>/... artifacts 5) Tag source repos with release version tag 6) A final rebuild should be done to verify artifacts
participants (1)
-
Saul Wold