Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] jgit timestamp provider ignores local changes

What about this use case?

0. check out from origin
1. fork to local repo
2. build to verify compiles / resolves before making changes
3. make some change / apply some patch or PR
4. commit to local topic branch
5. build again to verify PR
6. test installable (using director or by hand)

7. THEN if satisfied, push to origin (git.eclipse.org, github, bitbucket, etc.)

In that case, would the jgit provider use the timestamp of the locally committed (but not *pushed*) code? Or would it still look at the origin?

I suppose the alternative is to have all Jenkins CI builds use the jgit provider (enabled by an optional profile), while all local builds would continue to use the default one.

Nick

On 03/05/2013 11:10 AM, Igor Fedorenko wrote:
Just to clarify, jgit timestamp for a dirty working tree does not make
sense because it is impossible to know if the changes will be committed
or not. So the patch should fail the build if the working tree is dirty.
The same applies to staged commits, btw.

If you want to test your changes before you commit, you need to switch
to default timestamp provider... or maybe add configuration parameter to
jgit provider to use current time.

--
Regards,
Igor

On 2013-03-05 10:51 AM, Igor Fedorenko wrote:
https://git.eclipse.org/c/tycho/org.eclipse.tycho.extras.git/tree/tycho-buildtimestamp-jgit/src/main/java/org/eclipse/tycho/extras/buildtimestamp/jgit/JGitBuildTimestampProvider.java?id=tycho-extras-0.16.0#n82



I'll be willing to review a quality patch... but if somebody with good
jgit knowledge did that it'd be even better.


--
Regards,
Igor

On 2013-03-05 10:28 AM, Mickael Istria wrote:
Hi all,

For our project, I gave a try to
http://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers . It's
working well, but in the case a local change happen on the module, the
timestamp provider doesn't detect it and still uses timestamp of the
latest commit. So in the end, we can have several different artifacts
(with different content) using the same fully-qualified versions, built
on the same machine. This seems to me totally dangerous since we expect
OSGi bundles with same qualifiers to contain the same thing. Here we
cannot rely any more on qualified version to compare bundles.
This is pretty common use-case that running a "mvn verify" before a
commit and then generating multiple artifacts with same version and
different content, so it's not a corner-case.
Ideally, I would have expected the git timestamp provider to set the
timestamp to the current build timestamp in case it detects a local
change. What would you think of this behaviour? Should I open a feature
request?

Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>


_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user

_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user

--
Nick Boldt :: http://nick.divbyzero.com


Back to the top