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

[Peter Palaga]

Yes, sha1s do not solve reproducibility, they just enable basic 
traceability (what is inside of a SNAPSHOT based kettle build). They are 
fast and easy to add. That is all. -- P

On 2015-05-11 19:49, Lukas Krejci wrote:
> 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
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>