Comments (6)
If you go for an optional solution using golangs build tags im happy with it. Is that ok for you?
from drone-tree-config.
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.
from drone-tree-config.
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.
from drone-tree-config.
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.
from drone-tree-config.
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.
from drone-tree-config.
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.
from drone-tree-config.
Related Issues (20)
- Failed SCM connections should be handled properly HOT 4
- Auth server for BitBucket client is not specified HOT 6
- Gitlab support? HOT 4
- v0.3.4 fails to trigger builds on master branch in monorepo HOT 8
- Add support for root folder files changing - trigger multiple pipelines HOT 2
- Git tags / Release support HOT 3
- How to use it on k8s HOT 2
- The plugin omit "..." in commands in steps HOT 2
- Documentation: Timeouts of consideration HOT 1
- Drone rebuilds everything every time HOT 7
- Rate limit hit HOT 1
- did not find a .drone.yml HOT 4
- Docker images for ARM
- bitbucket cloud authorization error
- BitBucker Server(previously known as Stash) support?
- Add GitLab self-hosted support? HOT 1
- Wait the end of all pipelines? HOT 7
- Gitea support? HOT 7
- Multiple commits HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from drone-tree-config.