Audit the existing fabric8 pipeline library and create a new OSIO pipeline library if need be.

[pradeepto]

https://github.com/fabric8io/fabric8-pipeline-library is huge. We need to audit it, figure out the relevant bits. Extract these relevant, required and important bits into perhaps a new OSIO pipeline library.

For the audit, we need to figure out where the libraries and which parts of it are being used across OSIO. Also, check if they are being used in the booster/launcher projects.

• Audit https://github.com/fabric8io/fabric8-pipeline-library
• Create a new pipeline library with the relevant bits
• Test for feature parity and make sure it works for all known customers.

[bartoszmajsak]

Few observations from my side while working on the fix for Boosters imported through quickstart (so having Fabric8 pipeline library used)

1. only "CI" builds executes integration tests, regular builds on master branch (so "CD" part in the f8-p-l book) runs regular tests unless specified differently (see here
2. f8-p-l locks maven-failsafe-plugin to an arbitrary version which might be different to what actual project assumes to be - see here (fixed in fix: unblocks integration tests by fixing cube properties fabric8io/fabric8-pipeline-library#381)
3. until PR fix: unblocks integration tests by fixing cube properties fabric8io/fabric8-pipeline-library#381 is merged integration tests will be failing on PR builds for all the boosters.
4. we tend to throw in project-specific functions to the library which don't belong there. I doubt this has any relevance or appeal for end-user. More on this here

[bartoszmajsak]

Another interesting bit is that this library assumes that user has certain profile defined in his Maven build [1] [2] [3]. This results in Maven WARNING if profile is not there, so not a big deal, but shows that the flow was done ad-hoc without thinking about implications.

[sthaha]

Closing this as this EPIC would be covered by the work on https://github.com/fabric8io/osio-pipeline