Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #24284 Fixed git.build.time #24316

Merged
merged 1 commit into from
Feb 25, 2023
Merged

Conversation

dmatej
Copy link
Contributor

@dmatej dmatej commented Feb 24, 2023

- was overriden by a value from eclipse project 1.0.8

Signed-off-by: David Matějček <[email protected]>
@dmatej dmatej added the bug Something isn't working label Feb 24, 2023
@dmatej dmatej added this to the 7.0.3 milestone Feb 24, 2023
@dmatej dmatej self-assigned this Feb 24, 2023
@pzygielo
Copy link
Contributor

I'd rather have ever-changing git.build.time removed from build.id than move away from reproducible builds goal (I understand it's centuries of work to do to have it here, and such goal is not even established yet...).

IMO - the timestamp in signature file is enough.

@dmatej
Copy link
Contributor Author

dmatej commented Feb 25, 2023

I'd rather have ever-changing git.build.time removed from build.id than move away from reproducible builds goal (I understand it's centuries of work to do to have it here, and such goal is not even established yet...).

IMO - the timestamp in signature file is enough.

I have yet another changes prepared, but I wanted to push this first before somebody starts screaming that I did too many changes again :D (revisited branding.properties, related documentation and implementation)

Also - the commit is useful when you start arguing what was the source commit of the build. That's what I did in my next PR (yet after one with plugin updates).

I don't understand the reason for eclipse-ee4j/ee4j#71 - it doesn't make builds reproducible at all. I think it should work exactly opposite - to be able to run the build with -Dproject.build.outputTimestamp with one concrete time stamp for several executions, but this change made it mandatory.

@dmatej
Copy link
Contributor Author

dmatej commented Feb 25, 2023

But maybe we could even abandon the build id and rather replace it with more readable information instead of generating "magical" id:

  • the source commit
  • the timestamp

Then in the log output instead of this:
Running GlassFish Version: Eclipse GlassFish 7.0.2 (build updates-b43-g6276a24 2020-12-19T18:24:00+0100)]]
would be this:
Running GlassFish Version: Eclipse GlassFish 7.0.2-SNAPSHOT (commit ec1ce24934f0bb174333a9886b58a0d2f9e52b44, timestamp 2023-02-25T18:24:00+0100)]]

(My usual issue - do I work with snapshot or with a released version? How old is it?)

The current versioning and build id idea comes yet from SGES2/SJAS9, which used SVN and I have found also some old test for things which were already removed.

@pzygielo
Copy link
Contributor

I'd rather have ever-changing git.build.time removed from build.id.

This would leave other build.id' components like branch, commits since last tag and commit to give: updates-b43-g6276a24. Which by the way - b{xx} is questionable.

I'm all for only-commit (full hash) (and no timestamp).

@pzygielo
Copy link
Contributor

pzygielo commented Feb 25, 2023

I have yet another changes prepared, but I wanted to push this first

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants