Skip to content

Platform Releng Faq

Jump to bottom
Andrey Loskutov edited this page Apr 16, 2024 · 7 revisions

Where are the basics of the Platform build documented?

In Platform Build.

Does that Platform Build document describe the so-called Production Build?

No, not exactly. It forms the heart of the production build, but there are other things done in the production build. Those are described in Platform Build Automated. So in general, anyone wanting to learn or reproduce our build should first read Platform Build and then read Platform Build Automated.

Trigger builds manually

The builds can be triggered manually or scheduled to run at a specified time. The build jobs are available at releng JIPP instance. We use I-build for integration builds. These jobs can be directly triggered after logging in or can be scheduled by modifying the configuration of the specific job.

Syntax of cron consists of 5 fields separated by TAB or whitespace as below:

   MINUTE HOUR DOM MONTH DOW

   MINUTE  Minutes within the hour (0–59)
   HOUR        The hour of the day (0–23)
   DOM     The day of the month (1–31)
   MONTH   The month (1–12)
   DOW     The day of the week (0–7) where 0 and 7 are Sunday, 1 is Monday, 2 is Tuesday, 3 is Wednesday, 4 is Thursday, 5 is Friday and 6 is Saturday

How to mark a build unstable

Go to https://ci.eclipse.org/releng/job/eclipse.releng.markUnstable/ and trigger new build by clicking "Build with Parameters" action on the left side. You will need a build id (like I20220117-1800) and the bug id that should describe why the build is unstable.

Note: our I-build uses previously built Eclipse for publishing build. This is done using the I-build composite repository, so we need at least 1 working build in the composite before triggering a build.

When we run "markUnstable" job, that particular build will be removed from composite reducing the number builds available in the composite. One can add new builds to composite using markStable job. Please make sure the composite do not go empty. Sometimes we may want to mark multiple builds as unstable. In those cases we may end up with empty composite. Keep at least 1 build in the repository otherwise I-build script will fail.

How to fix unstable build

The build usually marked as "unstable" if tycho detects no source code changes but build will produce a different artifact, compared with the "baseline" (previous stable I-Build).

In such case a file called artifactcomparisons.zip can be found at https://download.eclipse.org/eclipse/downloads/drops4/<IBuild-ID>/buildlogs/comparatorlogs/.

One can download this file, extract it and check "build vs baseline" versions of affected bundles.

Only if the analysis shows, that despite no code change in the bundle the generated binary must be really updated, one should "touch" the bundle in question.

This "touching" process can be automated by using TouchBundles.java.

Best way to run TouchBundles.java is to import org.eclipse.releng.tools project into Eclipse workspace and run TouchBundles.java as a standalone Java application with few extra arguments specified.

Preconditions:

  1. artifactcomparisons.zip is extracted to some directory
  2. All SDK git repositories referenced by aggregator build are locally checked out at some common root directory

One can run TouchBundles.java from IDE with 4 arguments:

  1. first is path to the extracted artifactcomparisons.zip,
  2. path to the root directory with all SDK related repositories,
  3. last SDK release tag (like R4_31)
  4. the ticket message to mention in forceQualifierUpdate.txt file (usually simply link to the related github tiket).

Here is an example .launch file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.jdt.launching.localJavaApplication">
    <booleanAttribute key="org.eclipse.debug.core.ATTR_FORCE_SYSTEM_CONSOLE_ENCODING" value="false"/>
    <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
        <listEntry value="/org.eclipse.releng.tools/src/org/eclipse/releng/tools/TouchBundles.java"/>
    </listAttribute>
    <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
        <listEntry value="1"/>
    </listAttribute>
    <listAttribute key="org.eclipse.debug.ui.favoriteGroups">
        <listEntry value="org.eclipse.debug.ui.launchGroup.run"/>
    </listAttribute>
    <booleanAttribute key="org.eclipse.jdt.launching.ATTR_ATTR_USE_ARGFILE" value="false"/>
    <booleanAttribute key="org.eclipse.jdt.launching.ATTR_SHOW_CODEDETAILS_IN_EXCEPTION_MESSAGES" value="true"/>
    <booleanAttribute key="org.eclipse.jdt.launching.ATTR_USE_CLASSPATH_ONLY_JAR" value="false"/>
    <booleanAttribute key="org.eclipse.jdt.launching.ATTR_USE_START_ON_FIRST_THREAD" value="true"/>
    <stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="org.eclipse.releng.tests.TouchBundles"/>
    <stringAttribute key="org.eclipse.jdt.launching.MODULE_NAME" value="org.eclipse.releng.tests"/>
    <stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="/home/aloskuto/Downloads/artifactcomparisons /data/git ${string_prompt}"/>
    <stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="org.eclipse.releng.tests"/>
</launchConfiguration>

After execution of this task, each affected bundle will have an updated or created forceQualifierUpdate.txt file with the message provided.

All what would be needed after that is to commit changes, create PR's and eventually update bundle versions (if they weren't updated yet for the release).

How to rebuild ecj after unstable build

Assuming the SDK build was marked as unstable after ECJ (compiler) changes, to make sure the github PR validation jobs don't show same warnings one has to deploy & update ECJ snapshot configured. See https://github.com/eclipse-jdt/eclipse.jdt.core/wiki/ECJ#deploying-new-ecj-version-for-use-in-sdk-build

How to add new tests bundles to run during automated tests

Typical test workflow

Triggered by jobs in https://ci.eclipse.org/releng/view/Automated%20tests/. Typical workflow

  1. Download SDK
  2. Launch Eclipse SDK with jdk specified
  3. For each of test plugin
    1. Install plugin along with dependencies
    2. Extract test.xml from the test plugin
    3. Run default target
    4. Convert xml formatted test results to html
    5. Repeat above step for all the test bundles.

What needs to be done to add a new test bundle

  1. To add a new test bundle and run it as part of automated tests
    1. Create new test bundle along with test.xml. for example https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/tests/org.eclipse.jface.tests/test.xml
    2. Update https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/production/testScripts/configuration/sdk.tests/testScripts/test.xml
      1. Added a new target for the new bundle
      2. Make sure newly added target gets called when we call ant target “all”
      3. If the test plugin needs extra plugins not part of SDK, one needs to add them to setup target
  2. To publish test results
    1. Add the new bundle to https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse/publishingFiles/testManifest.xml

What other tasks does Platform Releng do?

Other tasks are described in several other documents, each has various degrees of accuracy or being up do date:

Are there documents that Platform committers should read or be aware of?

The following are good, though some sections may need to be brought up to date.

What are common build problems?

Build failure with "Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:1.5.0-SNAPSHOT:package-plugin (default-package-plugin) on project org.eclipse.swt.gtk.linux.ppc64le:"

Typical error message :

 [ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:1.5.0-SNAPSHOT:package-plugin (default-package-plugin) on project org.eclipse.swt.gtk.linux.ppc64le: /opt/public/eclipse/builds/4I/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.ppc64le/build.properties: bin.includes value(s) [webkitextensions*/] do not match any files. -> [Help 1]
 [ERROR]  To see the full stack trace of the errors, re-run Maven with the -e switch.
 [ERROR]   Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]   For more information about the errors and possible solutions, please read the following articles:
 [ERROR]   [Help 1] <http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException>
 [ERROR] After correcting the problems, you can resume the build with the command
 [ERROR] mvn `<goals>` -rf :org.eclipse.swt.gtk.linux.ppc64le

Problem Analysis and solution:

See discussion here https://bugs.eclipse.org/bugs/show_bug.cgi?id=551810 //TODO conclusion?

Build failure with "Cannot satisfy dependency:"

Typical error message :

 [ERROR] Cannot resolve project dependencies:
 [ERROR]   Software being installed: org.eclipse.equinox.sdk.product 4.9.0.qualifier
 [ERROR]   Missing requirement: org.eclipse.equinox.serverside.sdk.feature.group 3.15.0.v20180803-1236 requires 'org.eclipse.equinox.p2.iu; org.eclipse.equinox.server.p2.feature.group
 [1.5.0.v20180710-1609,1.5.0.v20180710-1609]' but it could not be found
 [ERROR]   Cannot satisfy dependency: org.eclipse.equinox.sdk.feature.group 3.15.0.v20180803-1236 depends on: org.eclipse.equinox.p2.iu; org.eclipse.equinox.serverside.sdk.feature.group
 [3.15.0.v20180803-1236,3.15.0.v20180803-1236]
 [ERROR]   Cannot satisfy dependency: org.eclipse.equinox.sdk.product 4.9.0.qualifier depends on: org.eclipse.equinox.p2.iu; org.eclipse.equinox.sdk.feature.group 0.0.0
 [ERROR]

Problem Analysis and solution:

This happens when we have nested features, in this case we have the following features nested. org.eclipse.equinox.server.p2 org.eclipse.equinox.serverside.sdk org.eclipse.equinox.server.p2 org.eclipse.equinox.sdk In the above case org.eclipse.equinox.server.p2 got modified and other feature did not recognize that. This causes comparator to replace other three features with baseline and causing above problem. Can be rectified by updating forceQualifierUpdate.txt file present alongside those features. Also raised Bug 537718 against Tycho to address this

See also bug 558213 where a similar error message can be caused by missing version updates in SWT fragments.

Build failure with "Failed to execute goal org.eclipse.tycho:tycho-compiler"

Typical error message :[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.5.1:compile (default-compile) on project org.eclipse.osgi: Fatal error compiling: Timeout 30 s exceeded. Commandline [/opt/public/common/jdk1.7.0-latest/jre/bin/java, -classpath, /shared/eclipse/builds/4I/localMavenRepo/org/eclipse/tycho/tycho-lib-detector/1.5.1/tycho-lib-detector-1.5.1.jar, org.eclipse.tycho.libdetector.LibraryDetector] was killed. Output: -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :org.eclipse.osgi

Problem Analysis and solution:

Problem happens due offline machine ( the machine that had the JDK) See https://bugs.eclipse.org/bugs/show_bug.cgi?id=553513

Build failure in SWT fragments or natives

If SWT version changes, but not all SWT fragments are updated, SDK build may fail. In that case, synchronizing version across all SWT artifacts is the solution.

Sometimes, native code changes but SWT binaries build fails to build & commit libraries and main SDK build fails to find them. In that case one should check what happens with the native build job, and maybe just trigger it again: https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/

Build failure while creating base builder

Typical error message:

 Installing org.eclipse.pde.api.tools 1.1.400.v20180727-1338.
 Installing org.eclipse.releng.build.tools.feature.feature.group 1.0.101.v20170602-0639.
 Installing org.eclipse.wtp.releng.tools.feature.feature.group 1.2.0.v201405010053.
 Installing org.apache.derby.core.feature.feature.group 10.11.1.1-v201411092200.
 Cannot complete the install because of a conflicting dependency.
  Software being installed: API Tools 1.1.400.v20180727-1338 (org.eclipse.pde.api.tools 1.1.400.v20180727-1338)
  Software currently installed: Eclipse Platform 4.8.0.I20180611-0500 (org.eclipse.platform.ide 4.8.0.I20180611-0500)
  Only one of the following can be installed at once:
   Debug Core 3.12.0.v20180509-0959 (org.eclipse.debug.core 3.12.0.v20180509-0959)
   Debug Core 3.13.0.v20180728-0102 (org.eclipse.debug.core 3.13.0.v20180728-0102)
  Cannot satisfy dependency:
   From: Java Development Tools Launching Support 3.11.0.v20180728-0103 (org.eclipse.jdt.launching 3.11.0.v20180728-0103)
   To: osgi.bundle; org.eclipse.debug.core [3.13.0,4.0.0)`
  Cannot satisfy dependency:
   From: Java Development Tools Launching Support 3.11.0.v20180728-2102 (org.eclipse.jdt.launching 3.11.0.v20180728-2102)
   To: osgi.bundle; org.eclipse.debug.core [3.13.0,4.0.0)`
  Cannot satisfy dependency:
   From: API Tools 1.1.400.v20180727-1338 (org.eclipse.pde.api.tools 1.1.400.v20180727-1338)
   To: osgi.bundle; org.eclipse.jdt.launching [3.6.100,4.0.0)`
  Cannot satisfy dependency:
   From: Eclipse Platform 4.8.0.v20180611-0656 (org.eclipse.platform.feature.group 4.8.0.v20180611-0656)
   To: org.eclipse.equinox.p2.iu; org.eclipse.debug.core [3.12.0.v20180509-0959,3.12.0.v20180509-0959]
  Cannot satisfy dependency:
   From: Eclipse Platform 4.8.0.I20180611-0500 (org.eclipse.platform.ide 4.8.0.I20180611-0500)
   To: org.eclipse.equinox.p2.iu; org.eclipse.platform.feature.group [4.8.0.v20180611-0656,4.8.0.v20180611-0656]

Problem Analysis and solution:

We use an eclipse instance for generating different build reports. This instance is created by adding org.eclipse.pde.api.tools, org.eclipse.releng.build.tools.feature.feature.group, org.apache.derby.core.feature.feature.group and org.eclipse.wtp.releng.tools.feature.feature.group to eclipse platform product. If you see the above error message it implies that one of the above feature requires higher version of eclipse platform product. This errors happens because the p2director cannot upgrade through commandline. This can be fixed by changing the base dir and base label here

What are common infrastructure issues affect releng

Infrastructure issues are documented here

Where are the old release engineering faq used till 4.4. release

They are documented here

[Feel free to add more items to this document, when questions are frequently asked.]

Clone this wiki locally