[git] regarding qualifiers...

[Eric Gwin]

Hi,

This is a question for all those who went before...

We are in the process of converting from SVN to Git. One major difference is that Git doesn't use revision numbers, and we had solved a potential issue with qualifiers by making use of them:

When the bundles are built, .qualifier is replaced by the actual qualifier usually .v<builddate><time> the issue is that if my code is four days old the bundles would still be built using the current system timestamp, so tracking nightly builds vs engineering bundles becomes an issue.

We opted to set the qualifier to .v<builddate>-r<svn revision>, so that we'd always be able to tie the build to the codebase. After the move we won't be able to. I could generate a tag for every build but I'd rather not deal with the overhead, I could ignore the issue (I'm certain it'll bite us eventually though), or I could try to stamp based on the date/time of last check-in.

I'm wondering what other teams have done, and if anyone more familiar with git can tell me if option 3 is even possible, and if so how it was accomplished.

Thanks.

-Eric

[Paul Webster]

Post by Eric Gwin
We opted to set the qualifier to .v<builddate>-r<svn revision>, so that we'd
always be able to tie the build to the codebase. After the move we won't be
able to. I could generate a tag for every build but I'd rather not deal with
the overhead, I could ignore the issue (I'm certain it'll bite us eventually
though), or I could try to stamp based on the date/time of last check-in.

I think we are close to your option 3: We update the map qualifiers
based on the v<UTC timestamp> of the last commit to touch that bundle,
and tag the commit with its matching qualifier [1]. We do it in a
special auto-tagging step at the beginning of the build that updates
all of the releng map files [2]. We also tag the build input with
the build qualifier, I20120123-2200 for example.

It works fine with our current map based build system, but has the
advantage that the qualifier is determined by the commits, which means
in theory for the same build input you'll generate the same qualifiers
for the contained bundles.

Later,
PW


[1] http://git.eclipse.org/c/e4/org.eclipse.e4.releng.git/tree/org.eclipse.e4.builder/scripts/git-map.sh
[2] http://git.eclipse.org/c/e4/org.eclipse.e4.releng.git/tree/org.eclipse.e4.builder/scripts/git-release.sh

[Eric Gwin]

Paul,

Thanks for the reference! A little experimenting and I found a that "git log -1 --format=%ai" will basically get me what I need (except for OS specific reformatting).

We are currently building everything based on the latest rev. That may need to change later, but this gives me what I need for now.

Thanks much.

-Eric

Post by Paul Webster

Post by Eric Gwin
We opted to set the qualifier to .v<builddate>-r<svn revision>, so that we'd
always be able to tie the build to the codebase. After the move we won't be
able to. I could generate a tag for every build but I'd rather not deal with
the overhead, I could ignore the issue (I'm certain it'll bite us eventually
though), or I could try to stamp based on the date/time of last check-in.

I think we are close to your option 3: We update the map qualifiers
based on the v<UTC timestamp> of the last commit to touch that bundle,
and tag the commit with its matching qualifier [1]. We do it in a
special auto-tagging step at the beginning of the build that updates
all of the releng map files [2]. We also tag the build input with
the build qualifier, I20120123-2200 for example.
It works fine with our current map based build system, but has the
advantage that the qualifier is determined by the commits, which means
in theory for the same build input you'll generate the same qualifiers
for the contained bundles.
Later,
PW
[1] http://git.eclipse.org/c/e4/org.eclipse.e4.releng.git/tree/org.eclipse.e4.builder/scripts/git-map.sh
[2] http://git.eclipse.org/c/e4/org.eclipse.e4.releng.git/tree/org.eclipse.e4.builder/scripts/git-release.sh

[Matthias Sohn]

Post by Eric Gwin
Hi,
This is a question for all those who went before...
We are in the process of converting from SVN to Git. One major difference
is that Git doesn't use revision numbers, and we had solved a potential
When the bundles are built, .qualifier is replaced by the actual qualifier
usually .v<builddate><time> the issue is that if my code is four days old
the bundles would still be built using the current system timestamp, so
tracking nightly builds vs engineering bundles becomes an issue.
We opted to set the qualifier to .v<builddate>-r<svn revision>, so that
we'd always be able to tie the build to the codebase. After the move we
won't be able to. I could generate a tag for every build but I'd rather not
deal with the overhead, I could ignore the issue (I'm certain it'll bite us
eventually though), or I could try to stamp based on the date/time of last
check-in.
I'm wondering what other teams have done, and if anyone more familiar with
git can tell me if option 3 is even possible, and if so how it was
accomplished.

If you want a qualifier describing the source version you may consider to
use
git describe [1]. It allows to describe the distance from the last tag and
to identify the
built commit without tagging each built version.

[1] http://schacon.github.com/git/git-describe.html

[Steffen Pingel]

Has anyone successfully used qualifiers that are based on Git
revisions in a Tycho build? I am looking for a solution that manages
versions and qualifiers based on revision history to avoid increasing
versions in each build even when artifacts haven't changed.

Thanks,

Steffen


On Tue, Jan 24, 2012 at 10:47 PM, Matthias Sohn

Post by Matthias Sohn

Post by Eric Gwin
Hi,
This is a question for all those who went before...
We are in the process of converting from SVN to Git. One major difference
is that Git doesn't use revision numbers, and we had solved a potential
When the bundles are built, .qualifier is replaced by the actual qualifier
usually .v<builddate><time> the issue is that if my code is four days old
the bundles would still be built using the current system timestamp, so
tracking nightly builds vs engineering bundles becomes an issue.
We opted to set the qualifier to .v<builddate>-r<svn revision>, so that
we'd always be able to tie the build to the codebase. After the move we
won't be able to. I could generate a tag for every build but I'd rather not
deal with the overhead, I could ignore the issue (I'm certain it'll bite us
eventually though), or I could try to stamp based on the date/time of last
check-in.
I'm wondering what other teams have done, and if anyone more familiar with
git can tell me if option 3 is even possible, and if so how it was
accomplished.

If you want a qualifier describing the source version you may consider to
use
git describe [1].  It allows to describe the distance from the last tag and
to identify the
built commit without tagging each built version.
[1] http://schacon.github.com/git/git-describe.html
--
Matthias
_______________________________________________
git mailing list
http://dev.eclipse.org/mailman/listinfo/git

[Paul Webster]

On Sun, Mar 11, 2012 at 9:46 AM, Steffen Pingel

Post by Steffen Pingel
Has anyone successfully used qualifiers that are based on Git
revisions in a Tycho build? I am looking for a solution that manages
versions and qualifiers based on revision history to avoid increasing
versions in each build even when artifacts haven't changed.

I don't believe that possible yet, but they're looking at it in the CBI
prototype:

*Bug 370707* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=370707> -
reproducible
build version qualifiers
*Bug 367581* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=367581> - do
not generate new version qualifier unless there are actual code changes

Later,
PW