No, they do not have to be in the same file. Not even in the same directory. We, for example, always have them in different places.
It seems like you have some other problem it your definitions do
Hi, I found that in jenkins-job-builder the template definition and the job defintion have to be in the same file, while in my case I have a monorepo that I hope the each projects can define their jobs in their project folders. Does jjb supports to define job this way? --
You received this message because you are subscribed to the Google Groups "jenkins-job-builder" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkins-job-bui...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkins-job-builder/23c7a334-c131-47dd-8186-7a3352d2bbbbn%40googlegroups.com.
Thank you for the sharing, those real world examples do help me a lot.
Now I totally understand how JJB works. I think it just treats configurations as a database. The command line tool merges items in different files into a list as a database, and uses name/id as foreign key to reference to other items. The command line tool will process those references and turn them into the final job definitions to create jobs in Jenkins.
It's really smart to use the idea of a database to make it possible to reuse configurations, as yaml doesn't provide such features. However, if you change the id/name of an item, or use a duplicate name/id accidentally, or refactor names of variable placeholders, it will be horrible to ensure all of the existing configuration files are still valid. IMO lack of support in code refactoring and strict type checking would be a nightmare for large projects.
I think nowadays we may use cue-lang to achieve the same result more elegantly. It can use spec to define the schema of complicated items like #Job, #SCM, and reuse configuration by importing packages and data merge instead of id reference. I don’t know if there are already attempts to use such ideas. Personally I believe cue-lang + jjb would be a perfect combination for CI management.
As for large projects. We support > 12,000 jobs across multiple Jenkins
servers using JJB and our global-jjb library. So, yes it can be hard to
deal with sometimes, it's actually really workable. We've been using it
like this for well over 5+ years now