search

bitsbeats / drone-tree-config

Drone helper for mono repositories.
Apache License 2.0
103 stars 24 forks source link

Jsonnet support #3

Closed chrismellard closed 4 years ago

chrismellard commented 5 years ago

Are you open to this plugin being extended to support Jsonnet? With multiple .drone.yaml files in a repo it's likely you're using something like Jsonnet to reduce redundant build config. So built in support would save on some pre-commit processing.

foosinn commented 5 years ago

If you go for an optional solution using golangs build tags im happy with it. Is that ok for you?

chrismellard commented 5 years ago

Couldn't we just define the precedence between a .drone.jsonnet file alongside a .drone.yaml file (i.e. if .drone.jsonnet exists ignore .drone.yaml or vice-versa) and leave the optional solution based around whether you have one of these files defined?

It might be some parts of the tree are defined with yaml files and others with Jsonnet files and this approach would support having both files at different points of the hierarchy.

foosinn commented 5 years ago

Right now the plugin is using the file described in drone.

One issue we run into: the github api is quite slow. We are checking with a deph of 2. Some repositories go up to 30+ directories that need to be checked.
Would it make sense to allow a separator based list in drones configuration? That way one could configure in drone which files should be checked.

Do you plan to have a single jsonnet file for each subproject, one for multiple or a mixed scenario?

We could go for something like a droneProvider interface, that is selected based on the filename.

chrismellard commented 5 years ago

For our use case I'm not sure a delimited list of drones configuration files is necessary. I suspect you're either using Jsonnet across the board or YAML, not a mixture of both - and like I already mentioned I suspect with multiple drone configs in the same repo there is a very high probability of redundant config copied all over the place and if this irks you then surely you'd look to move to a pure Jsonnet set of definitions?

To keep it simple to start how about just taking the config in Drone as the file to search recursively for in GitHub, i.e. if .drone.jsonnet then it purely calls GitHub API looking for this file. Would be easy to extend down the line to a delimited list if someone found a need for this.

How I would envisage it would be one .drone.jsonnet file per subproject/component to build and then likely a central set of libsonnet files that they import. These libsonnet imports would also need to be factored in to the design to produce the final drone config. This library functionality is something that even the main drone project is lacking currently, i.e. it supports a single .drone.jsonnet file but imports do not function. Some potential we could take some of this import library logic and create a PR for the main drone repo.

foosinn commented 5 years ago

I suspect you're either using Jsonnet across the board or YAML, not a mixture of both

That could be done by setting the filename to drone.jsonnet, it would still walk through the directories.

How I would envisage it would be one .drone.jsonnet file per subproject/component to build and then likely a central set of libsonnet files that they import.

Why not go from a central jsonnet file and import per subfolder? That way you may get a solution that works only based on jsonnet.

foosinn commented 4 years ago

I just saw this ticket is still open. If you really want you can try to implement this and submit a pull. Other options would be using only jsonnet, since your sub build are a lot more similar than ours.