Review/revisit for qualifier updates

The force qualifier updates build step is a little brittle, this step:

Line 59 in cdbc520

    
           - [ ] Update the build qualifiers to ensure that packages are all updated. See this [gerrit](https://git.eclipse.org/r/#/c/161075/) for an example. To do this run `releng/org.eclipse.epp.config/tools/setGitDate` ([link](https://github.com/eclipse-packaging/packages/blob/master/releng/org.eclipse.epp.config/tools/setGitDate)) script. This script will make a local commit you need to push.

Because if you squash or amend the commit so the commit time is overridden the effect goes away as the commit time, not the author time is used.

This results in the following manual check to potentially fail:

packages/RELEASING.md

Line 76 in cdbc520

    
           - [ ] `org.eclipse.epp.package.*` features and bundles have the timestamp of the forced qualifier update or later

The utility of the force qualifier updates is to make sure that we don't publish content with the same version + qualifier but produced at different times.

Perhaps it would be easier to simply remove these steps and stop using the jgit timestamp plug-in and always use build time for the bundles qualifier. I think that would achieve the goal without the overhead.

PS I think there was also the desire to have the timestamps be "pretty" in the past, i.e. org.eclipse.epp.package.common_4.32.0.20240530-1200 instead of org.eclipse.epp.package.common_4.32.0.20240530-0533/

Note that the RC1 (see #166) shows the inconsistency (the build is still ok) because the commit that set the timestamp has different commit and author times. The setGitData script sets the commit date:

packages/releng/org.eclipse.epp.config/tools/setGitDate

Line 7 in 54cfc2a

export GIT_COMMITTER_DATE="${GIT_DATE}"

But the commit for RC1 was different cdbc520

Yes, I wondered about that. If you want each build to produce new artifacts, why use the commit time and need to make a commit to change it... Of course there is the issue of reproducible builds too...

It's funny but despite the very exact git commit time stamp, the bundle versions are always off by some number of seconds:

Anyway, I think it's good that the bundles are all the same version qualifier and for the day of the build and it's probably good that each build does not produce new versions. So I'm not sure we should change anything...

It's funny but despite the very exact git commit time stamp, the bundle versions are always off by some number of seconds:

Its actually off by a few hours. This is because PRs like #473 are merged with the GitHub UI which is doing a rebase, which resets commit time and actually undoes part of what setGitDate script does, which forces commit time by committing with GIT_COMMITTER_DATE env var.

Compare commit 59f493a which was what you pushed to your fork and 64db42a which is what is on master.

$ git log --pretty=fuller -1 64db42a699b26f9df4156e32f0ba9daab7917023
commit 64db42a699b26f9df4156e32f0ba9daab7917023
Author:     Ed Merks <ed.merks@gmail.com>
AuthorDate: Thu Oct 8 12:00:00 2026 +0000
Commit:     Ed Merks <Ed.Merks@gmail.com>
CommitDate: Thu Oct 8 08:39:02 2026 +0200

    Set version qualifiers for 2026-12 M1 with setGitDate script

I do create PRs when I do this, but I merge the PR by pushing to master directly. The last time I did it the commit 9eec7a6 is in both master and in the PR 9eec7a6

$ git log --pretty=fuller -1 9eec7a6a7107b69e0a8b09b6c6b3b657032ef113
commit 9eec7a6a7107b69e0a8b09b6c6b3b657032ef113 (tag: 2025-06_R)
Author:     Jonah Graham <jonah@kichwacoders.com>
AuthorDate: Thu Jun 5 13:00:00 2025 +0000
Commit:     Jonah Graham <jonah@kichwacoders.com>
CommitDate: Thu Jun 5 13:00:00 2025 +0000

    Set version qualifiers with setGitDate script

With the above in mind, this issue is to consider:

Perhaps it would be easier to simply remove these steps and stop using the jgit timestamp plug-in and always use build time for the bundles qualifier. I think that would achieve the goal without the overhead.

this part of the setGitDate instruction is the part that was supposed to mean do a direct commit and push of that commit:

  This script will make a local commit you need to push; **do not amend it** because the timestamp is relevant.

I see! Well, I didn't amend and I did a push, but I try to be a good citizen and create PR and push to my fork and do a verification build, which is not really so relevant for the time stamp thing. But there's also the commit for the repository URL and with two separate commits it's likely there will be two builds being kicked off.

So we could just use the buidl time, but then every day the staging build will necessarily produce new artifacts, but I could we could make the time step prettier with some rounding around the current time. And in the end, but content does tend to change from build to build very often.

So I'm starting to think perhaps this is a better approach...

So we could just use the buidl time, but then every day the staging build will necessarily produce new artifacts

I don't think that is a problem because the staging is always different than the last release and so we never benefit from compare and replace anyway. The current scheme means that subsequent days of staging has the same version number, but different contents.

I try to be a good citizen

You are! This flow worked better in Gerrit where we had "fast forward only" on, an option that is sorely missed in GitHub.

Let me try a PR that removes the setGitDate step.

Stop using setGitDate and rely on buildtime for qualifiers

Stop using setGitDate and rely on buildtime for qualifiers (eclipse-p…

@jonahgraham

@jonahgraham

In Oomph's Jenkinsfile it uses this to set the build time stamp:

BUILD_TIMESTAMP = sh(returnStdout: true, script: 'date +%Y%m%d-%H%M%S').trim()

Maybe we could use something like this

BUILD_TIMESTAMP = sh(returnStdout: true, script: 'date +%Y%m%d-%H00').trim()

or

BUILD_TIMESTAMP = sh(returnStdout: true, script: 'date +%Y%m%d-0000').trim()

Or maybe that's overly fussy? (I haven't tested it.)

Most of our builds for the last couple of years have not had a "rounded" qualifier and no one complained or seemed to care, so I vote leave it on Tycho default of build time.

13. Most of our builds for the last couple of years have not had a "rounded" qualifier and no one complained or seemed to care, so I vote leave it on Tycho default of build time.

I know. The point is just that this determines the version of the IUs. Of course no one complained about those either. I only mentioned it because we tried to make those pretty. But I think no one cared when that failed, so why bother?

Navigation Menu

Repository navigation

Review/revisit for qualifier updates #169

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Review/revisit for qualifier updates #169

Description

Activity

merks commented on May 30, 2024

merks commented on Oct 13, 2026

jonahgraham commented on Oct 15, 2026

jonahgraham commented on Oct 15, 2026

merks commented on Oct 15, 2026

jonahgraham commented on Oct 15, 2026

jonahgraham commented on Oct 15, 2026

merks commented on Oct 15, 2026

jonahgraham commented on Oct 15, 2026

merks commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions