Are release builds reproducible?

[ewillink]

Migrating my MoDisco/OCL/QVTd/QVTo builds to explioit JustJ required the former ability to produce N/I/S/R builds to be replaced by N/S/R builds. Throwing out I-builds was no great loss. But the changes to R-builds as a rebadging of the latest S-build set me thinking.

A number of distinguished committers have made comments to the effect that builds, particularly release builds should be reproducible. This seems eminently sensible and an obvious releng responsibility.

But consider a +2 project such as QVTo. It's milestones should be built 3 days before the SimRel milestone is promoted,
so the S-build Tycho target definition must refer to the milestone builds of +0/+1 dependencies and the release builds of +2/+3 dependencies. This S-build may not reproduce even a day later if some +2/+3 dependency updates. It certainly isn't reproducible six months later when almost all milestone dependencies have vanished.

The above transience is not really a problem for a milestone. But when the final milestone is rebadged as a release, something must be done to make it reproducible.

JustJ is better than my former apprioach, since JustJ can automatically capture the commit ID and directly display the actual dependencies. In principle a reproducing build just needs to replace the Tycho target definition file to refer to the equivalent releases.

Since it is very rare that a build is actually reproduced, it is not unreasonable that the effort fall on the occasional reproducer rather than the releng for every build, so today we can show the reproducer the JustJ page with commit and dependencies and tell them to edit the target definition appropriately.

A really diligent releng might commit an edit of the target definition after the final milestone and then rebuild the milestone
and then declare it as a JustJ release so that the commit refers to GIT with reproducible release dependencies. The releng can then commit a reversion to stable dependencies.

JustJ could be more helpful if there was a facility to convert from:

• a JustJ release page
• target definition file name(s)

to

• revised target definition file(s)

The revised dependencies resolve to the minimal SimRel / project releases. So long as projects do reliable rebadging this conversion can be run on e.g. GA day once all the contributions have stabilized. Committers could perhaps commit the results or JustJ could persist at the release repo site.

Problem: The platform, at least, and perhaps a project or two may provide a hopefully 100% compatible update at RC2 or later. These do not require dependent projects to rebuild, but may make precise inference of SimRel release equivalents difficult. Perhaps all updates after RC1 are assumed to be build-compatible with the contribution aggregated at RC1 .

[merks]

Reproducible builds would be great. That's simply outside the scope of JustJ p2.manager tool which is focused purely on managing update sites. The commit ID, which is actually stored in the repository itself as a property:

<?xml version='1.0' encoding='UTF-8'?>
<?metadataRepository version='1.2.0'?>
<repository name='JustJ Tools 0.1.0 Nightly' type='org.eclipse.equinox.internal.p2.metadata.repository.LocalMetadataRepository' version='1'>
  <properties size='3'>
    <property name='p2.timestamp' value='1709823917477'/>
    <property name='p2.compressed' value='true'/>
    <property name='commit' value='https://github.com/eclipse-justj/justj.tools/commit/1b8c9c8d127eaa86c8eb370ed02e868c8f1bc1b8'/>
  </properties>

is somewhat helpful in that direction, but managing a reproducible target platform is a challenge at best. I know folks asked for this of BIRT; doing that when all the dependencies have stable final release repository is manageable, but is yet more work when there is already too much work and not enough time.

[ewillink]

The commitID is clearly very important to support reproducibility wrt the source code, but for reproducibility we need a further column perhaps below the commit to show P2 repo usage. An entry for "EMF" might link to https://download.eclipse.org/modeling/emf/emf/builds/milestone/S202402110927 identifying the source for e.g. org.eclipse.emf.ecore etc. Without that information the build page only indicates org.eclipse.emf.ecore [2.5.0,3.0.0) which is just a friendly debug rendering of what is in the MANIFEST.MF. Nothing indicates what actual version of org.eclipse.emf.ecore was built against or which of possibly many P2 sites it was loaded from.

JustJ could infer some of the origin by scanning plausible SimRel sites against a target platform directory list, but this is just reverse engineering what the Tycho target-platform-configuration did during the build. For reproducibility we surely require the target-platform-configuration to drop a 'log' of loaded IU versions wrt P2 / ... sites? JustJ could then fold the 'log' in with the commitId and display it below the commitId.

Tooling attempting to reproduce, on discovering that https://download.eclipse.org/modeling/emf/emf/builds/milestone/S202402110927 is no longer available, could offer the user plausible successors.

(The repo entries below the commitId might be foldable to reveal referencers, thus opening a pair of "Orbit" entries might reveal both https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/release/4.31.0 and http://download.eclipse.org/tools/orbit/downloads/drops/R20201118194144/repository/. Expanding the latter could reveal that it was solely there to support javax.annotation and might even reveal where an obsolete reference comes from.)

[merks]

Reproducible builds is outside of the scope of the p2.manager. One needs a reproducible set of build tools using reproducible sources, including stable unchanging update sites as binary sources. The p2.manager can help only with making stable binary sources available and well documented. I have no plans beyond that scope.

[ewillink]

https://github.com/eclipse-tycho/tycho/issues/3571 suggests that the Tycho target-platform-configuration drop a 'log' file.

[Bananeweizen]

If I understand you right, we are talking about target platform definitions either containing installable units with exact versions or with version 0.0.0 instead, like in this screenshot from the egit target (above exact versions, below unspecified versions).

And there the 0.0.0 entries are a problem, because they are resolved only at build time of the overall Tycho product.

I believe there is another workaround than enhancing Tycho: If the target platform is specified using the TPD project, then the version of an IU can be left unspecified (e.g. just the name of the unit is listed), and the TPD to .target conversion can be invoked from the command line, producing a .target file with concrete versions. Afterwards the normal build via Tycho can happen, and the .target file can be archived to be able to reproduce the build.

That same workflow might work even when not using TPD, as long as some command line exists to convert a target platform with 0.0.0 into one with specific versions before the Tycho build. However, I'm not sure what exists there, as I use TPD in all my projects. (BTW: This goes into the same direction as the suggestion of laeubi to manually use the "Update" button of the PDE target platform editor at eclipse-tycho/tycho#3571 (comment))