our development team came up with a great idea:
When they create a certain library they gonna (git commit) tag it with a certain version number
Later when Jenkins would start the build process, a “version” file gets red and according to its entries the appropriate “version” (tag) of a lib/file gets pulled from the master branch and build subsequently.
So the task woud be:
- Git sparse checkout a single file named “versions” from the repo
- The versions-file contain all files needed with their corresponding version-tags. (Ya, sometimes an “older” version of a lib is needed so you may choose a different tag)
- Pull the source-code according to the tags mentioned in the versions-file from the repo
- Run the build script
- How to grab a single file (“versions”) from my repo using Jenkins “checkout function”. I haven’t found any sparse option … Or is there a better solution ?
- I can generate a list (or JSON, csv …) from the versions-file, but how to checkout the files with exactly these version tags ? Is there a GIT-Plugin that accepts (kinda) a list of files+tags to download ?
Any help greatly appreciated
AFAIK, there’s no plugin like that. But you could make a shell script run a “git checkout” command for each version and path listed in the version file, e.g. “git checkout v42 – src/component”. This is not a typical way of using Git though, and may cause problems with SDKs or Jenkins features that expect your whole working tree to correspond to one Git commit, e.g. if you are using something like Source Link for .NET, or the Git Forensics plugin in Jenkins. It might be better to make one Jenkins job construct the working tree as specified in the version file, commit the result, and push it to a server; and then trigger a separate Jenkins job to build it. That way, all the files would come from the same commit in the second job, and Jenkins would know which commit it is. Also, investigate whether “git subtree” or “git submodule” fits your requirements.
Thats always a scary sentence.
What your describing is kinda all over the place. I feel like your trying to make some sort of dependancy system, which there are many that exist and are pretty fleshed out depending on what language your using.
If your using declarative, make sure you disable the default checkout, then use the pipeline syntax generator to build a git or checkout statement that has all the flags you want set.
There’s nothing stopping you, and infact probably easier, to just use branches/tags, and use the multibranch pipeline to build a branch every time it needs updating. But failing that, you can use shell statements and just run git yourself.
Honestly this feels like a huge hacky work around to a problem not fully thought out.
Solutions that already do this kind of management for you:
I found GitHub - aerys/gpm: Git-based Package Manager. by searching “git based dependancy mangement” on google.
If you want to go down your described route, I would recommend doing the majority in scripts outside of jenkins, and get jenkins to call them. It’ll make it easier to test and maintain, and even build locally as needed.
Hi all, thanks for all of your replies.
Yes, it’s a tricky situation (to say the least) as we’re dealing with cobol developers who are working +30 ys on a mainframe and now must switch to some new infrastructure.
I tried your suggestions and in the end it all boild down to: I need to checkout a specific file with a specific tag attached.
So far, it seems that Jenkins ‘checkout’ is not capable of doing so. Not sure if the standard ‘git’ is capable of … (my cur. vers. is: 2.21.0)
So actually the only “chance” I see here is to do an external mapping. Kinda: Get all commits and search for correlating filename + tag to get the commit ID. Then pull this specific commit ID.
But that’s gonna be overkill given the size and number of commits (over the years) for that repo/branch
Well, maybe I’m missing something here. So the question is: Is there a way to sparse-checkout a single file with a specifig name + specific tag ?
Jenkis ‘checkout’ might not … but maybe there’s something else …