[Hawkular-dev] Adding git SHA1 & Co. to manifest.mf to improve traceability

[Lukas Krejci]

I'm not sure adding git sha's to manifests helps the situation much.

For future evidence, I agree with Thomas H. that we need reproducible builds 
and strongly versioned components.

The only disagreement we had was when to introduce them. Thomas' point for 
introducing strong versioning now is Kettle. Being the sum of the moving 
parts, it can break at random points with no traceability when using SNAPSHOTs 
of the components.

My point for not introducing strong versioning YET is that the parts are so in 
flux that introducing such formal workflow would slow the development down 
with little added benefit (the benefit being no unpredictable unrelated 
breakages in Kettle at random points in time coming from the components that 
messed up).

Of course there is a couple of questions here: 

1) is the interdependence of the individual components so great that we really 
would have to release every other day?

2) is the UI willing to work in branches for long time to track unreleased 
progress in individual components? UI, really, is the biggest concern for me, 
because it usually needs the cutting edge functionality from the components.

3) can the release process be somehow sped up so that stuff appears in some 
public maven repos soon after the release is cut? (i.e. NOT 12-24 hrs)

4) is Kettle of big interest to the community? Currently it does much LESS 
than the individual components are capable of doing. Pinger really only 
scrapes the surface in the terms of the functionality being developed across 
the board.

For me, the real question is whether we can afford 2) or solve 3). I am not 
100% convinced 1) is that big of a problem anymore (despite claiming that 
during our f2f discussions - I've thought about it more since).

Lukas

On Monday, May 11, 2015 10:44:43 Peter Palaga wrote:
> Hi *,
> 
> citing from https://issues.jboss.org/browse/HAWKULAR-176 :
> 
> == Motivation
> 
> The proposed changes should improve the traceability of the components
> delivered with kettle. Because we use SNAPSHOTs to build kettle ATM,
> there is no way to find out which state of the individual component's
> git repos underlie the given kettle distribution.
> 
> In a situation when Lukáš has a working kettle distro and Thomas H.
> cannot succeed to build one, they can go through the SHA1 hashes listed
> in the manifest.mf files of the kettle components to find out where is
> the difference.
> 
> This proposal is not a proper solution of the problem that kettle builds
> are not reproducible. It just picks some low hanging fruits to soften
> the possible negative impact of our irreproducible builds.
> 
> == Changes
> 
> Maven should be configured in such a way that .jar, .war and *.ear files
> will have the following new entries added to their manifest.mf files:
> Built-From-Git-SHA1 - the last git commit's hash
> Built-On - the time when the build has started
> Built-From-Git-Branch - the git branch being built from
> 
> Further, when the release profile is active, the build should fail, in
> case there are uncommitted local changes.
> 
> See https://github.com/hawkular/hawkular-parent-pom/pull/21
> 
> 
> Best,
> 
> Peter
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev