Difference between revisions of "Releng-Tasks"

Revision as of 08:15, 6 December 2019

Page contains instructions for carrying out regular Eclipse Release engineering tasks. If you still have a query, please post the query in Releng Faq.

Routine releng tasks

Build failures

https://wiki.eclipse.org/Platform-releng-faq

Monitoring of JIPP jobs

Test Jobs

Linux GTK2 running on CentOS
Linux GTK3 running on CentOS
Linux GTK3 running on CentOS Java9
Mac OS X
Windows 

Deployment jobs to repo.eclipse.org. If these fail gerrit jobs will fail

Deploys eclipse parent pom for use in gerrit
Deploys prereqs
Deploys JDT compiler

Cleanup and monitoring jobs

Verifies whether derby data base is working used in testing
Removed old builds based on the retention policy and updates download page
Verifies the I-build, M-build composites
Cleans up equinox builds
Mark any IBuild as unstable when "Unanticipated comparator errors" occurs, you need to pass below Job args:
- Eclipse IBuild ID
- Bugzilla bug ID

Email Notification list:

P-build
Y-build
Note: The lists are comma separated. You can add/remove individual mail-ids here.

Run JUnits test with newer Java version:

So, we need below things to be done e.g. let's consider Java12:
1. We need to installation of java12 on the test build machine, see bug: 544037

2. We need to have new releng configuration changes[Note we don't publish the newer Java version JUnits until officially supported by Eclipse], see bug: 543770

3. We need to have the new Jenkins Jobs for IBuild and YBuild configuration created. So we cloned any of the existing Job e.g. Java11 and updated the JDK path in the script configuration.

Create new Y Builds

Every time there's a new version of Java Language, the JDT and PDE teams work on adding the tooling support to Eclipse. This usually happens in a beta branch until it is time to merge the changes in master stream. For testing purposes as well as enabling dependent projects to use Gerrit, we need to create builds from the beta work. Here's the basic steps that need to be carried out:

1. Start with branching for project that contribute to the new language version.

2. Make the release changes as documented in Bug 548663: [13] Start creating Y builds from BETA_JAVA13
The commits has the details, but the three important changes are:
- creating a new index page for the Y builds
- listing the beta branches for the contributing repositories.
- Update the mb4Y_hudson.sh with the appropriate branch information. (Make sure this is the script file used in the following Y build configuration in the shell command section.

3. Configure the Y build job [1]
- Usually, nothing much needs to change, except the names of the branches, version etc.
- As of now, maven has issues with > 8 JDK. Hence, make sure the job is configured with jdk 8
- Schedule if required

How to deal with MAC signing failure?

We have a new flag setting w.r.t. MAC signing which is never disabled. We only enable/disable the failing nature of IBuild.

Sharing more details on what exactly the flag does: Current flag value: <macSigner.forceContinue>true</macSigner.forceContinue>

false: means the IBuild will try to do MAC signing and if MAC signing step fails the complete IBuild is declared as failure which can be noticed with: [2]
Major drawback: Builds for all platform fails because of missing MAC signing step, even when the IBuild is testable but not releasable.

true: means the IBuild process try to sign the MAC build(if it woks we get a .dmg file extension for a signed build) e.g. [3] and if it fails we will force continue with the build which you can notice with: [4] and we will end up with .tar.gz(extension for un-signed build).
Note: When MAC signing fails the MAC download link will not work in the download page as it continues to point to .dmg file, to make the download link work, rename it to .tar.gz

Related bugs: bug 542843, bug 544555 and bug 544798