The original Jenkins git plugin drops the case where the repo string it’s parsing for doesn’t exist in a Jenkins job. To use this all by itself we would have to by hand configure and maintain jobs in Jenkins and in a large CICD environment that’s not workable.
It’s possible that in the Jenkins architecture we could also listen for that notifyCommit http request to Jenkins – and act on it without disrupting what the git plugin already does. I’m saying possibly – RootActions and ExtensionPoints documentation suggest that Jenkins gets the notifyCommit and passes it to any plugin that has that url string configured. Testing that to see if both the original git plugin and a new cicd plugin can both act on the same notifyCommit url submission.
If true we have the first case, where the notifyCommit comes from a repo Jenkins does not know of and has no job for, solved. We create a separate plugin that also handles the original git notifyCommit payload and does the job create in in Jenkins, “discovers” the job, leaving the git plugin completely alone. The second case, where the job does exist, git plugin handles – IF we can create a standard config.xml that then points to a jenkinsfile and a pipeline job that encompasses all of the variations we need for building applications and from that packaging as AMIs. That’s the second piece of design to test. If this works we don’t need to disrupt a config.xml on Jenkins to change the job as the developers move it forward – the jenkinsfile can definitely come from the appropriate repo and be specific to that individual build.
I think that aligns closer with the overall conceptual architecture of Jenkins as well…
—doug