Difference between revisions of "VPP/CommitterTasks/PullThrottleBranch"

From fd.io
< VPP
Jump to: navigation, search
m (formatting)
(Jira versions)
 
(17 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
__TOC__
 
__TOC__
== VPP RC1 Milestone Tasklist ==
+
== VPP RC1 pre-Milestone Tasklist ==
  
 
1. At least a week prior to the RC1 date, email a reminder to vpp-dev@lists.fd.io about VPP RC1 Milestone. See [https://lists.fd.io/g/vpp-dev/message/7780 an example email] or [https://lists.fd.io/g/vpp-dev/topic/rc1_branch_in_one_week/16305776 another example email].
 
1. At least a week prior to the RC1 date, email a reminder to vpp-dev@lists.fd.io about VPP RC1 Milestone. See [https://lists.fd.io/g/vpp-dev/message/7780 an example email] or [https://lists.fd.io/g/vpp-dev/topic/rc1_branch_in_one_week/16305776 another example email].
  
2. Resend reminder a day or two prior to the RC1 date.
+
2. To be done before RC1:
  
== Pulling a VPP Throttle Branch ==
+
:a. Follow-up that ci-management change below is merged
 +
:b. Verify that packagecloud.io repository fdio/YYMM (as corresponding to the branch stable/YYMM that is being created) exists and follow up with Ed Warnicke to ensure it is created and has "lf-fdio" added as a collaborator.
 +
:c. Prepare "first commit of rc0 of next release" commit on master branch so it is ready for merge + tagging at the time of the RC1.
  
'''NOTE''': Steps 3 and 4 can be done any time prior to RC1 branch day. At the very least, discuss the requirements with the individuals ahead of time to set the correct expectations.
+
3. Resend reminder about (1) a day or two prior to the RC1 date.
  
3. Request LF Admin (via fd.io helpdesk) create Nexus repositories
+
== Jira versions ==
  
Have LF admin staff create in nexus new repositories of the form "<code>fd.io.${branchpart}.${distropart}</code>" where ''branchpart'' is of the form ''stable.YYMM'' (example ''stable.1804'') and the ''distropart'' is one of the supported distributions.
+
RC1 milestone involves a fair bit of watching the paint dry, so it is a good use of part of this time to create the next version in Jira. VPP committers should have admin access to Jira.
  
At time of writing, we currently support the <code>ubuntu.xenial.main</code>, <code>centos7</code> and <code>opensuse</code> distributions.
+
From https://jira.fd.io/plugins/servlet/project-config/VPP/summary navigate to ''Releases'' (or ''Versions'', same thing) and fill in the empty boxes labelled ''Version name'' and ''start date'' (which should be the date that RC1 of the current release is created). Then select ''Add''.
  
For example:
+
Additionally, if the previous version was not released (because the previous release manager forgot to), now is a good time to do so. Choose the ''Release'' action for the version and then move still-open issues to the current release. Set the release date for the previous release appropriately.
  
<nowiki>
+
Finally, check that the dates for the current release are accurate; it is likely the release date is empty. By this point we should know the anticipated release date, so it is worth filling it in.
Hello fd.io helpdesk!
+
  
Could you create the Nexus repositories required for the VPP 18.04 release, please?
+
== Pulling a VPP Throttle Branch ==
  
Per https://wiki.fd.io/view/VPP/CommitterTasks/PullThrottleBranch these should be named:
+
'''NOTE''': Steps 3 and 4 can be done any time prior to RC1 branch day. At the very least, discuss the requirements with the individuals ahead of time to set the correct expectations.
  
fd.io.stable.1804.ubuntu.xenial.main
+
3. nexus - no longer needed.
fd.io.stable.1804.centos7
+
fd.io.stable.1804.opensuse
+
  
Note that the Centos repository should be setup as a Yum repository, to enable the task that generates the index files.
+
4. Request Ed Warnicke create the package cloud repos. Send and email to Ed Warnicke (eaw@cisco.com and/or hagbard@gmail.com) reminding him to create the package cloud repositories for the new release, and have lf-fdio as a collaborator.
Please also run the indexing task manually to generate an empty index.
+
Since 21.01RC1 the verify/merge jobs do not require the packages to be present in the deb repos.
  
Thanks,
+
5. '''Jenkins''': (can be done and merged some days <b>before</b> the date of pulling the branch) - In the ci-management Git repo, edit <code>jjb/vpp/vpp.yaml</code>:
&lt;name&gt;</nowiki>
+
 
+
'''NOTE''': In the message to the helpdesk we indicate that the Centos repository is also a Yum repository and needs the indexing task setup. If this is not done then the Centos merge job will fail with a message in the console output that Yum could not retrieve that index.
+
 
+
4. Request Ed Warnicke create the package cloud repos.
+
 
+
Send and email to Ed Warnicke (eaw@cisco.com and/or hagbard@gmail.com) reminding him to create the package cloud repositories for the new release.
+
 
+
'''NOTE''': If these do not exist or the permissions for them are wrong, then the merge jobs will fail after uploading build artifacts to nexus.fd.io
+
 
+
5. '''Jenkins''': In the ci-management Git repo, edit <code>jjb/vpp/vpp.yaml</code>:
+
  
 
:a. https://git.fd.io/ci-management/tree/jjb/vpp/vpp.yaml#n49
 
:a. https://git.fd.io/ci-management/tree/jjb/vpp/vpp.yaml#n49
Line 56: Line 44:
 
:c. '''Example:'''  https://gerrit.fd.io/r/9934/
 
:c. '''Example:'''  https://gerrit.fd.io/r/9934/
  
6. Create a new branch ''stable/YYMM'' (example: ''stable/1801'') in the Gerrit web UI against the point on master you wish to be cutting the branch (usually <code>HEAD</code> at the time you’re cutting).
+
:d. Similarly, edit <code>jjb/vpp/docs.yaml</code>
 +
::add a new 'stream' for your new ''YYMM''. Example for ''stable/1904'':
 +
- '1904':
 +
            branch: 'stable/1904’'
 +
            repo-stream-part: 'stable.1904'
 +
 
 +
:e. '''Example:'''  https://gerrit.fd.io/r/#/c/18982/
 +
 
 +
 
 +
6. (since 22.02) On master branch, edit docs/aboutvpp/releasenotes/index.rst and remove the oldest version designator. Add this same version designator at the top of the docs/aboutvpp/releasenotes/past.rst file. This will be the commit that the next release -rc0 tag is placed on.
 +
:Examples:
 +
::https://gerrit.fd.io/r/c/vpp/+/34967
 +
 
 +
<strike>6. (before 22.02) On master branch, edit vpp/RELEASE.md and add a placeholder for the next release and merge the patch on master and edit vpp/doxygen/test_framework_doc.md and add a new link to the next release's test framework documentation.  This will be the commit that the next release -rc0 tag is placed on.
 +
:Examples:
 +
::https://gerrit.fd.io/r/#/c/18803/1/RELEASE.md
 +
::https://gerrit.fd.io/r/#/c/19292/1/doxygen/test_framework_doc.md
 +
</strike>
 +
 
 +
7. [https://wiki.fd.io/view/VPP/Pushing_and_Testing_a_Tag Lay down a tag] for the next release RC0 (e.g. <code>1804-rc0</code>) on master, using the hash of the above commit as an explicit argument for tagging.
 +
 
 +
:a. Verify that the tag shows up by looking for it at https://git.fd.io/vpp/log/ - it usually takes a few minutes.
 +
:b. Remerge the last merged patch on master - you can see the "to be" version in the build logs for the merge jobs.
 +
:c. When the remerge of the last patch on master is complete, go look for package with the correct versions at packagecloud.io/fdio/master
 +
:d. Follow instructions on [[VPP/Installing_VPP_binaries_from_packages]] and verify that packages with the new versions are installed on packagecloud.io
 +
 
 +
There may be existing patches from others waiting to be merged on master - then instead of a remerge of the patch from step (6), if that patch is being merged, it can be used for sanity check instead of patch from step (6).
 +
 
 +
8. Create a new branch ''stable/YYMM'' (example: ''stable/1801'') in the Gerrit web UI and specify the hash of the commit JUST BEFORE the one you merged in step 6.
  
 
:a. https://gerrit.fd.io/r/#/admin/projects/vpp,branches
 
:a. https://gerrit.fd.io/r/#/admin/projects/vpp,branches
  
7. On ''stable/YYMM'' (example: ''stable/1801'') prepare a commit which updates the <code>.gitreview</code> to reflect the correct branch
+
9. On the new ''stable/YYMM'' branch (example: ''stable/1801'') prepare a commit which updates the <code>.gitreview</code> to reflect the correct branch. (You will need a "git pull" in your local repo to see the ref for the newly created branch).
  
 
:a. Examples:   
 
:a. Examples:   
 +
::https://gerrit.fd.io/r/c/vpp/+/34968
 
::https://gerrit.fd.io/r/#/c/1157/1/.gitreview
 
::https://gerrit.fd.io/r/#/c/1157/1/.gitreview
 
::https://gerrit.fd.io/r/#/c/9937/
 
::https://gerrit.fd.io/r/#/c/9937/
Line 70: Line 87:
 
'''NOTE''': Verify that this patch is in fact on the new stable branch, and not on master!
 
'''NOTE''': Verify that this patch is in fact on the new stable branch, and not on master!
  
8. [https://wiki.fd.io/view/VPP/Pushing_and_Testing_a_Tag Lay down a tag] (<code>v18.01-rc1</code>) on ''stable/1801'' at the point of the patch you just merged.
+
10. [https://wiki.fd.io/view/VPP/Pushing_and_Testing_a_Tag Lay down a tag] (<code>v18.01-rc1</code>) on ''stable/1801'' at the point of the patch you just merged.
 
+
9. Verify that the nexus repos have packages with the correct version and are working
+
  
:a. Remerge the patch from step 7
+
'''NOTE:''' If the verification steps in 11 & 12 don't happen by the end of the day, it is best to send an email re-opening master to commits.
  
:b. When the remerge from step 7 is complete, verify that the correct package versions have been uploaded onto the nexus server
+
11. Verify that the packagecloud.io repos have packages with the correct version and are working
::<pre>https://nexus.fd.io/content/repositories/fd.io.stable.YYMM.centos7/</pre>
+
:a. Remerge the patch from step 9 after you push the tag (you can verify the to-be version of artifacts in the beginning of the VPP build log messages)
::<pre>https://nexus.fd.io/content/repositories/fd.io.stable.YYMM.ubuntu.xenial.main/</pre>
+
  
:c. Examples
+
:b. When the remerge from step 9 is complete, verify that the correct package versions have been uploaded onto the packagecloud.io/fdio/XXYY repository - if the job succeeded, the packages typically will be there. You can verify by visiting the  packagecloud.io web interface and checking there.
::https://nexus.fd.io/content/repositories/fd.io.stable.1801.centos7/
+
::https://nexus.fd.io/content/repositories/fd.io.stable.1801.xenial.main/
+
  
:d. Verify that package like artifacts are present in all the above git repos by looking for:
+
:c. Verify that the packages for the supported OSes are installable from the packagecloud.io/fdio/XXYY repo
::* Non-zero sized ‘Package’ in the apt repos (xenial)
+
::* A repodata/ subdir in the yum repo (centos7)
+
  
:e. Update the [[VPP/Installing_VPP_binaries_from_packages | Installing VPP Binaries from Packages]] Wiki page with instructions for the new branch, and test that you can install packages
+
:d. Update the [[VPP/Installing_VPP_binaries_from_packages | Installing VPP Binaries from Packages]] Wiki page with instructions for the new branch, and test that you can install packages from packagecloud.io
  
10. [https://wiki.fd.io/view/VPP/Pushing_and_Testing_a_Tag Lay down a tag] for the next release RC0 (e.g. <code>1804-rc0</code>) on master.
+
12. Send the all-clear message. [https://lists.fd.io/g/vpp-dev/message/7811 Example].
  
11. Update the package version used by Java generation on master with the next release version in <code>vpp/src/configure.ac</code>
+
13. If the Jira steps from [[VPP/CommitterTasks/ApiFreeze#Jira_versions]] didn't happen yet, do them now.
:a. Example: https://gerrit.fd.io/r/#/c/8578/
+
:b. Merge the patch.
+
  
12. Verify that the nexus repos have packages with the correct version and are working
+
Amend as necessary with any caveats; for example the 1804 RC1 milestone opened master and stable on different days while minor issues were resolved.
:a. Remerge the last merged patch on master
+
:b. When the remerge of the last patch on master is complete, go look for package with the correct versions at:
+
::https://nexus.fd.io/content/repositories/fd.io.master.centos7/
+
::https://nexus.fd.io/content/repositories/fd.io.master.ubuntu.xenial.main/
+
:c. Verify that package like artifacts are present in all the above git repos by looking for:
+
::*Non-zero sized ‘Package’ in the apt repos (xenial)
+
::*A repodata/ subdir in the yum repo (for centos7)
+
:d. Follow instructions on [[VPP/Installing_VPP_binaries_from_packages]] and verify that packages with the new versions are installed
+
  
 
== Historical Recipes ==
 
== Historical Recipes ==

Latest revision as of 08:54, 28 June 2022

VPP RC1 pre-Milestone Tasklist

1. At least a week prior to the RC1 date, email a reminder to vpp-dev@lists.fd.io about VPP RC1 Milestone. See an example email or another example email.

2. To be done before RC1:

a. Follow-up that ci-management change below is merged
b. Verify that packagecloud.io repository fdio/YYMM (as corresponding to the branch stable/YYMM that is being created) exists and follow up with Ed Warnicke to ensure it is created and has "lf-fdio" added as a collaborator.
c. Prepare "first commit of rc0 of next release" commit on master branch so it is ready for merge + tagging at the time of the RC1.

3. Resend reminder about (1) a day or two prior to the RC1 date.

Jira versions

RC1 milestone involves a fair bit of watching the paint dry, so it is a good use of part of this time to create the next version in Jira. VPP committers should have admin access to Jira.

From https://jira.fd.io/plugins/servlet/project-config/VPP/summary navigate to Releases (or Versions, same thing) and fill in the empty boxes labelled Version name and start date (which should be the date that RC1 of the current release is created). Then select Add.

Additionally, if the previous version was not released (because the previous release manager forgot to), now is a good time to do so. Choose the Release action for the version and then move still-open issues to the current release. Set the release date for the previous release appropriately.

Finally, check that the dates for the current release are accurate; it is likely the release date is empty. By this point we should know the anticipated release date, so it is worth filling it in.

Pulling a VPP Throttle Branch

NOTE: Steps 3 and 4 can be done any time prior to RC1 branch day. At the very least, discuss the requirements with the individuals ahead of time to set the correct expectations.

3. nexus - no longer needed.

4. Request Ed Warnicke create the package cloud repos. Send and email to Ed Warnicke (eaw@cisco.com and/or hagbard@gmail.com) reminding him to create the package cloud repositories for the new release, and have lf-fdio as a collaborator. Since 21.01RC1 the verify/merge jobs do not require the packages to be present in the deb repos.

5. Jenkins: (can be done and merged some days before the date of pulling the branch) - In the ci-management Git repo, edit jjb/vpp/vpp.yaml:

a. https://git.fd.io/ci-management/tree/jjb/vpp/vpp.yaml#n49
add a new 'stream' for your new YYMM. Example for stable/1801:
- '1801':
            branch: 'stable/1801’'
            repo-stream-part: 'stable.1801'
b. https://git.fd.io/ci-management/tree/jjb/vpp/vpp.yaml#n87
likewise add a new stream here. Exactly the same idea as the previous step.
c. Example: https://gerrit.fd.io/r/9934/
d. Similarly, edit jjb/vpp/docs.yaml
add a new 'stream' for your new YYMM. Example for stable/1904:
- '1904':
            branch: 'stable/1904’'
            repo-stream-part: 'stable.1904'
e. Example: https://gerrit.fd.io/r/#/c/18982/


6. (since 22.02) On master branch, edit docs/aboutvpp/releasenotes/index.rst and remove the oldest version designator. Add this same version designator at the top of the docs/aboutvpp/releasenotes/past.rst file. This will be the commit that the next release -rc0 tag is placed on.

Examples:
https://gerrit.fd.io/r/c/vpp/+/34967

6. (before 22.02) On master branch, edit vpp/RELEASE.md and add a placeholder for the next release and merge the patch on master and edit vpp/doxygen/test_framework_doc.md and add a new link to the next release's test framework documentation. This will be the commit that the next release -rc0 tag is placed on.

Examples:
https://gerrit.fd.io/r/#/c/18803/1/RELEASE.md
https://gerrit.fd.io/r/#/c/19292/1/doxygen/test_framework_doc.md

7. Lay down a tag for the next release RC0 (e.g. 1804-rc0) on master, using the hash of the above commit as an explicit argument for tagging.

a. Verify that the tag shows up by looking for it at https://git.fd.io/vpp/log/ - it usually takes a few minutes.
b. Remerge the last merged patch on master - you can see the "to be" version in the build logs for the merge jobs.
c. When the remerge of the last patch on master is complete, go look for package with the correct versions at packagecloud.io/fdio/master
d. Follow instructions on VPP/Installing_VPP_binaries_from_packages and verify that packages with the new versions are installed on packagecloud.io

There may be existing patches from others waiting to be merged on master - then instead of a remerge of the patch from step (6), if that patch is being merged, it can be used for sanity check instead of patch from step (6).

8. Create a new branch stable/YYMM (example: stable/1801) in the Gerrit web UI and specify the hash of the commit JUST BEFORE the one you merged in step 6.

a. https://gerrit.fd.io/r/#/admin/projects/vpp,branches

9. On the new stable/YYMM branch (example: stable/1801) prepare a commit which updates the .gitreview to reflect the correct branch. (You will need a "git pull" in your local repo to see the ref for the newly created branch).

a. Examples:
https://gerrit.fd.io/r/c/vpp/+/34968
https://gerrit.fd.io/r/#/c/1157/1/.gitreview
https://gerrit.fd.io/r/#/c/9937/
b. Merge patch onto the new stable branch

NOTE: Verify that this patch is in fact on the new stable branch, and not on master!

10. Lay down a tag (v18.01-rc1) on stable/1801 at the point of the patch you just merged.

NOTE: If the verification steps in 11 & 12 don't happen by the end of the day, it is best to send an email re-opening master to commits.

11. Verify that the packagecloud.io repos have packages with the correct version and are working

a. Remerge the patch from step 9 after you push the tag (you can verify the to-be version of artifacts in the beginning of the VPP build log messages)
b. When the remerge from step 9 is complete, verify that the correct package versions have been uploaded onto the packagecloud.io/fdio/XXYY repository - if the job succeeded, the packages typically will be there. You can verify by visiting the packagecloud.io web interface and checking there.
c. Verify that the packages for the supported OSes are installable from the packagecloud.io/fdio/XXYY repo
d. Update the Installing VPP Binaries from Packages Wiki page with instructions for the new branch, and test that you can install packages from packagecloud.io

12. Send the all-clear message. Example.

13. If the Jira steps from VPP/CommitterTasks/ApiFreeze#Jira_versions didn't happen yet, do them now.

Amend as necessary with any caveats; for example the 1804 RC1 milestone opened master and stable on different days while minor issues were resolved.

Historical Recipes

Steps for cutting Master to XXYY-rc0

VPP 16.09-RC0 cut punchlist