build/test and test pipelines

[Alan Sparks]

I have a couple of pipelines I’ve built for building and testing AMIs.  Both the build and the test sides of the coin are complex enough that I don’t want to duplicate the code.  I’ve used a couple of shared libraries to centralize the logic. 

 

My previous version used a couple of MB pipelines, branch per OS type, one pipeline for build and the other for test.  I liked this from the standpoint that I could run the test pipeline by itself on an object, as well as having the build pipeline spin up a test job on the just-built artifact.

 

But I’m trying to change the repo/branch structure, one OS type per repo, and master/feature/merge branch builds.  I’m looking at how a merge request would be implemented… I have the build pipeline that can merge the master and feature branch and build the AMI as a pre-merge test, but that pipeline triggers the test one (a build step) and that has no idea there’s a merge to do, so it tests the wrong thing.

 

All the branches and pipelines in this case are created with the Gitlab Source Plugin, to trigger stuff on the push and merge request hooks.   

 

I’d take any level of specifics, but has anyone had experiences with such an arrangement, particularly the best way to factor the build and the test to make pre-merge work, and yet keep the build and test able to work apart as well as in sequence?   If there’s an RTFM for these sorts of patterns, I’d appreciate a pointer to them.

 

Sorry if this was tl;dr, or too vague.  If there’s any info wanted, I’ll be happy to provide.  Thanks in  advance.

-Alan