Ok circling back to this.
Thanks for the suggestion about using a local repo Marques.
TLDR: it worked!
Long form:
I created a bogus local repo (as a GKE PVC). I mounted the PVC on both the server and the agent as ReadOnlyMany (only way to get a PVC mounted on multiple pods).
With this, I configured the pipeline git material to point to the bogus local repo. This allows me to bypass the pipeline material restriction which requires a pipeline to have some sort of material.
Since the same disk is also mounted on the agent, I was able to clone the bogus repo. Now, i've successfully bypassed the material restriction of the pipeline and the CI builds on the agents does not fail!
Now for the fun part, how do I get my actual large repo in the agent?
So I dug through the jenkins source code to see how they handle reference repos.
This is what they do (which is what i'm doing as a job within the pipeline)
$ git init <repo>
$ cd <repo>
$ echo "/path/to/reference/repo/.git/objects" > .git/objects/info/alternates
$ git config remote.origin.url <repo url e.g
https://github.com/gocd/somerepo>
$ git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master
$ git checkout master
# Now I have a checked out repo & can run my builds!
You may ask instead of using a bogus repo, why not just mount the actual reference repo on the server and agent?
Well, the reference repo needs to be updated (daily). Since the reference repo is mounted as ReadOnlyMany, it can't be updated when it is in use.
Update entails:
- Creating a new PV/PVC
- Updating pod template to use the new PV/PVC
- Delete the old PV/PVC
The agents are elastic - a build creates a new pod - so every new pod get the latest pod template with the latest PVC.
The issue is with updating the PVC for the server. The server is a long running pod and the PV/PVC can not be swapped while it is running.
It needs to be recreated which is quite disruptive to service. So I decided to mount a PV which does not change frequently hence the bogus repo.
IMHO, the condition that a pipeline needs to have a material is too restrictive. There are limited available materials and those materials don't cover all CI use cases. I think either have material that supports a robust amount of CI use cases OR make materials optional to pipelines.
Thank again for the suggestion Marques!