Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Platform-releng/Checklist"

m (/* Build Calendar and reminders)
m (/* Build Calendar and reminders)
Line 40: Line 40:
 
=== Build Calendar and reminders ===
 
=== Build Calendar and reminders ===
 
* Be sure build calendar is up to date (ideally, a few weeks before the milestone).
 
* Be sure build calendar is up to date (ideally, a few weeks before the milestone).
* Send a reminder note to platform-releng-dev with the following information. A good time is right after the next-to-last I-build before stabilization begins, so there is about 10 days "notice".  
+
* Send a reminder to platform-releng-dev with the following information. A good time is right after the next-to-last I-build before stabilization begins, so there is about 10 days notice.  
:- the build schedule link
+
:- The [https://www.eclipse.org/eclipse/platform-releng/buildSchedule.html build schedule]. [<nowiki>https://www.eclipse.org/eclipse/platform-releng/buildSchedule.html</nowiki>]
:- a reminder about "all teams, all day" test (typically on Tuesday, unless it is a vacation) and sign-off day, typically on Thursday.  
+
:- Remember that "stabilization week" means "code freeze" (except for regression fixes) with a link to [[Eclipse/Rhythm#Milestones]] [<nowiki>https://wiki.eclipse.org/Eclipse/Rhythm#Milestones</nowiki>].
:- a reminder what "stabilization week" means with a link to [[Eclipse/Rhythm#Milestones]]:  
+
:- The "all teams, all day" test on Tuesday should be taken seriously by all Platform committers. Testing is more important than writing code during stabilization week -- we are, after all, the Platform! Our quality effects nearly every other Eclipse project.
 +
: - Sign-off day is on Thursday. Project leads or their delegate should be sure to reserve time to handle that in a timely fashion.
 +
* From time to time, can expand on the above with a more detailed version:
 
::* The rule is that on Monday we have the last day of development (and even then, no "big changes"). The goal to have a good build for the full day test pass on Tuesday. After Monday, no feature work or unrelated fixes are allowed -- only regression fixes.  
 
::* The rule is that on Monday we have the last day of development (and even then, no "big changes"). The goal to have a good build for the full day test pass on Tuesday. After Monday, no feature work or unrelated fixes are allowed -- only regression fixes.  
::* On Tuesday no one should develop or fix anything, but spend the entire day testing -- not only their own component but also "Eclipse as a whole". Ideally, project leads will have a brief list of test activities, such as new features to test, bugs to verify, etc.
+
::* On Tuesday no one should develop or fix anything, but literally spend the entire day testing. Ideally, this would not be only their component but also Eclipse as a whole. Ideally, project leads will have a brief list of test activities, such as new features to test, bugs to verify, etc. (but, admittedly, each component is different).  
 
::* Wednesday is the fix-day with a focus on fixing regressions found during the test-day.  
 
::* Wednesday is the fix-day with a focus on fixing regressions found during the test-day.  
::* The last Wednesday build is the release candidate every team signs-off on Thursday. Signing-off may involve some re-testing, or at least confirming no changes made since the last time the component was tested well.  
+
::* The last Wednesday build is the release candidate every team signs-off on Thursday. Signing-off may involve some re-testing, or at least confirming no changes have been made to your components code since the last time the component was tested well.  
::* No new code changes can be made until the milestone is officially declared (i.e. it is not enough that your component was signed off). There is always a chance a re-build will be required at the last minute.
+
::* No new code changes can be made until the milestone is officially declared. That is, it is not enough that your component has signed off. There is always a chance a re-build will be required at the last minute.
 +
::* Also, while not stabilization week specific, all Platform committers must subscribe to platform-releng-dev and eclipse-dev (as well as their own component's mailing lists). Component leads should communicate this to new committers. Please spread the word if you think there are current committers do not know this.
 +
::: - The platform-releng-dev list is used to routinely communicate information about builds, timing, rebuilds, off-schedule builds, special activities that must be coordinated, etc.
 +
::: - The eclipse-dev list is where we officially announce milestones, release candidates, and releases, in addition to our official plans, and other information the community needs to know.
  
 
=== Stabilization Week ===
 
=== Stabilization Week ===

Revision as of 00:20, 14 April 2016

This page is to provide a checklist of "release engineering" tasks that must be done at various stages of development.

Note: this page is "just getting started" and will be added to incrementally, as phases are gone through and new things remembered to document. Also, as it develops the structure may change substantially, so "header links" may not stabilize for a while, and hence would be best not to use headers in links ... at least for a while, until it takes it's final form.

Before Major (June) release

lots to come, for this section

After Major (June) release

Update no-version-in-url repository composites

  • Update the 4 repo composites that have no version in URL (I-builds, M-builds, N-builds, milestones)

After any Release

  • Prepare bugzilla to guide and remind us to "Tag a Release".
  • Prepare bugzilla (and code) to update the parent pom to "next version". That is, when a "next version" is planned. For example, after "4.5.2" we do not automatically change to "4.5.3". Any long term maintenance is done is seen as "patch builds" of 4.5.2 (usually denoted 4.5.2+ in bugzilla) -- it is not a "new release stream".
  • Update any "info center" bugs with our latest collection of 'doc bundles'. As one example of one, see bug 477616.
And since I have made this error several times, the correct pattern to copy our doc bundles in a "p2 repo" plugins directory is (thanks to Markus Keller):
- *.doc.*.jar is the pattern that picks the right 5 bundles
- Not *.doc*.jar, which picks up a 6th one, org.eclipse.ua.tests.doc_1.0.x.q.jar, which is literally "tests", not "docs".
  • Add the N&N, acknowledgments and readme links to the download page. These are automated in the "promote script" to avoid manual edits, but will describe here in case there are issues. In short, the promote script adds three variables to the buildproperties.php file when it is renaming/promoting to an "R-build" : $NEWS_ID, $README_ID, $ACK_ID. And, from those, the index.php file has conditions based on 'isset' that will compute the full URL. For example, for any Release in the 4.5.x stream, the promote script adds the following variable=value pairs buildproperties.php:
 $NEWS_ID = "4.5";
 $ACK_ID = "4.5";
 $README_ID = "4.5";
  • Copy the release to "archives". While it would seem not to be required until it is removed from "downloads" page, it is a good idea to do it early. This is partially just so it does not have to be done later when it is removed from DL page. But more important, some adopters may like to use the "archives" URL in their own builds simply so that their build script never has to change. This, I have heard, is a common practice at Apache sites. [Note: this is automated for Equinox, so it is done by the same script that promotes Equinox releases but is not yet automated for Eclipse.]
  • There are a few places in our builds where "previous release" is specified. That should be updated to the new "previous release". (It is best to search the aggregator project for the previous release version to find the spots that need to be updated.)
The following are the files that needed modifying after the 4.5.2 release (but, things may change over time). See this commit log entry for more details of this specific case.
eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/resources/equinoxp2tests.properties
eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/resources/label.properties
eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/scripts/getPreviousRelease.sh
eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/scripts/runtests.sh
production/build-functions.shsource
production/sdk/miscTools/proxyRelated/getBaseBuilderAndTools.xml
production/testScripts/configuration/sdk.tests/testScripts/runtests.sh
production/testScripts/configuration/streamSpecific.properties
production/testScripts/updateTestResultsPages.sh

Milestones

Build Calendar and reminders

  • Be sure build calendar is up to date (ideally, a few weeks before the milestone).
  • Send a reminder to platform-releng-dev with the following information. A good time is right after the next-to-last I-build before stabilization begins, so there is about 10 days notice.
- The build schedule. [https://www.eclipse.org/eclipse/platform-releng/buildSchedule.html]
- Remember that "stabilization week" means "code freeze" (except for regression fixes) with a link to Eclipse/Rhythm#Milestones [https://wiki.eclipse.org/Eclipse/Rhythm#Milestones].
- The "all teams, all day" test on Tuesday should be taken seriously by all Platform committers. Testing is more important than writing code during stabilization week -- we are, after all, the Platform! Our quality effects nearly every other Eclipse project.
- Sign-off day is on Thursday. Project leads or their delegate should be sure to reserve time to handle that in a timely fashion.
  • From time to time, can expand on the above with a more detailed version:
  • The rule is that on Monday we have the last day of development (and even then, no "big changes"). The goal to have a good build for the full day test pass on Tuesday. After Monday, no feature work or unrelated fixes are allowed -- only regression fixes.
  • On Tuesday no one should develop or fix anything, but literally spend the entire day testing. Ideally, this would not be only their component but also Eclipse as a whole. Ideally, project leads will have a brief list of test activities, such as new features to test, bugs to verify, etc. (but, admittedly, each component is different).
  • Wednesday is the fix-day with a focus on fixing regressions found during the test-day.
  • The last Wednesday build is the release candidate every team signs-off on Thursday. Signing-off may involve some re-testing, or at least confirming no changes have been made to your components code since the last time the component was tested well.
  • No new code changes can be made until the milestone is officially declared. That is, it is not enough that your component has signed off. There is always a chance a re-build will be required at the last minute.
  • Also, while not stabilization week specific, all Platform committers must subscribe to platform-releng-dev and eclipse-dev (as well as their own component's mailing lists). Component leads should communicate this to new committers. Please spread the word if you think there are current committers do not know this.
- The platform-releng-dev list is used to routinely communicate information about builds, timing, rebuilds, off-schedule builds, special activities that must be coordinated, etc.
- The eclipse-dev list is where we officially announce milestones, release candidates, and releases, in addition to our official plans, and other information the community needs to know.

Stabilization Week

Cronjobs

  • For milestone stabilization week, the nightly cron jobs are disabled, twice daily I-build cron jobs enabled.
[TODO: perhaps provide copy of "current cron jobs" for illustration?]

Repo Information for Gerrit jobs

  • A maven variable, eclipse-p2-repo.url, is defined in the build-individual-bundles profile. Normally, by default, this variable points to I-builds, so that Gerrit jobs can "use the latest" of things it does not build. But, during a typical development week, we do only one I-build per week, so in those cases it is better to use an N-build repo as the prereq repository. Then, during "milestone stabilization week" and RCs weeks, when we stop doing N-builds and do frequent I-builds instead, the value should be changed back to the default of using I-builds.
- NOTE: This does not require a republish of the parent pom which should always use the I-build by default, as that is anticipated to be the most suitable for the most people for most of the time.
- On the Platform HIPP at Eclipse.org, we use a property file to set this value, for all Hudson jobs running there on the Platform HIPP. It is manipulated by the Hudson job named A Job to set Eclipse prereq repo.
- People running outside "Eclipse.org" that desire this level of control either have to pass the property in on the command line, or make use of a similar properties file.
- A command line example, might looks like this:
-Declipse-p2-repo.url=http://download.eclipse.org/eclipse/updates/N-builds/
- If the property file is desired, it must be in and named as the following
${HOME}/.m2/build-individual-repository.properties

And its contents would be similar to the command line (just no -D).

 eclipse-p2-repo.url=http://download.eclipse.org/eclipse/updates/N-builds/

Create and monitor "sign-off" bug

  • Typically created after last I-build is complete, but can be created earlier.
  • Project leads are added to CC
  • Typically note is sent to platform-releng-dev, as added reminder, and so everyone can know, if interested.

Do special releng tests

Some of these may be automated eventually ... but, until then ...
  • Run b3 aggregator, at least locally, to see if any issues
  • Confirm all jars are signed
  • sanity check version numbers, names, etc. (i.e. run "repo tests" locally, until automated)
  • confirm can "update" from previous milestone

Promote the milestone

Happens after signed off ... though some initial steps can be done early if fairly confident all is well because the build remains "hidden" until the deferred steps are performed.

Initial step

  • add "testNotes.html" to buildDirectory, with sign-off bug number. [TODO: automate]
  • Initial step: run the "promote" job from appropriate directory, with appropriate changes for the I-build to promote, what labels should be. This puts artifacts "in place" but, "invisible" until deferred step. (This allows the promotion to be done "early" possible before all sign-offs, but also to allow some mirroring to occur, before being made visible.)

Deferred step

  • Deferred step: run the "deferred steps" script (which would have been created as part of the initial promotion job). This makes things visible and tags the aggregator.

After milestone promotion

Cronjobs

  • Change cron jobs back to their normal schedule (nightly N-builds, weekly I-builds).

Gerrit jobs reference

Back to the top