I’d like to share Drone config pieces between many git repos. Back in the day, Drone only consumed .drone.yml, so one option we had was to template the YAML files ourselves and commit them to each repository, where we’d have the “common” base variables/YAML in a common git repo somewhere.
Now that we have jsonnet, I wonder if this could be automated. That is:
common-repo/base.jsonnet: declares env vars, image versions, build steps
repo-one/drone.jsonnet: imports base.jsonnet and generates the CI config
repo-two/drone.jsonnet: imports base.jsonnet and generates the CI config
...
When repo-one or repo-two build, they’d somehow clone common-repo, and then use jsonnet to generate the config json to run the build on. As far as I can tell, that’s not possible with the current jsonnet plugin, or I can’t figure out a way from the docs.
I understand I could write my own Drone plugin for this, but I must be missing something obvious - this use-case seems fairly common to me, at least for large organisations that don’t use monorepos.
Or perhaps the recommended way is to use jsonnet and commit the generated json/yaml files manually?
yes, the recommended approach is to use something like jsonnet-bundler to handle external imports, and to commit the generated file to your repository.
This comes down to personal preference. We find it desirable to push new and experimental features to plugins because it allows individuals to rapidly prototype functionality without the risk of introducing instability into the core project and without having to engage the core maintainers, whose time is limited. A feature can always be adopted in Drone core from a plugin in the future.
Thanks for the quick reply. We’ll go with committing the files for now, which seems reasonable. Perhaps this thread can be useful to others in the future.
I know it is a possibility, but for large organisations is fairly common to have multiple repos with very similar deploy pipelines, and for a frontend-only projects is quite hard to add this jsonnet-bundler flow. @mvdan did you find any alternative to it?