Is it possible to use drone to build projects when I am unable to maintain a .drone.yml in the actual project’s repository?
Namely, my usecase is doing continuous integration of the Linux kernel, whereby I would like to run every time a particular repo+branch is updated at git.kernel.org.
This is not currently possible, however, we are working on support for using plugins to fetch the .drone.yml file, allowing you to override the default behavior. The specific use cases we are trying to support are
teams that want to use default yaml files when none exist
teams that want to generate yaml files on-the-fly
teams that want to augment the yaml on the-fly (add default steps, etc)
teams that want to use their own dialects, and return a transpiled .drone.yml
I think this would satisfy your use case.
This feature is should be available in the 0.9-alpha.3 release (we are currently on alpha.1). I do not have a planned release date, but should be available in a few weeks. Let me know if you are interested in helping beta test the feature once available.
I am evaluating - we currently use jenkins with jjb to build, deploy, and test the linux kernel across a wide variety of devices. This is rather different than I think drone’s normal usecase (building and deploying apps). So, it may be a long shot.
Sounds like a fun challenge. I realize that the kernel cannot have a .drone.yml in the repository, but for testing purposes, have you tried setting up a .drone.yml to see if Drone can support your use case? If yes, I can try to fast track a feature that allows you to source the .drone.yml from an alternate source (via plugins as I mentioned above). Let me know how else I can help.
I haven’t tried, but I think the rest is possible. Certainly the docker context is not a problem. The other thing that comes to mind is being able to do a matrix type build whereby some build steps are done in parallel on separate machines (our builds take about 25 minutes each on a dedicated host, and we do about 6 builds per git push).
Drone version 0.9 (alpha, coming soon) supports multi-machine pipelines with fan-in and fan-out capabilities, so this will not be a problem.
Example of what you can expect the configuration to look like:
---
metadata:
name: frontend
pipeline:
- build:
image: node
commands:
- npm install
- npm test
---
metadata:
name: backend
pipeline:
- build:
image: golang
commands:
- go build
- go test
services:
redis:
image: redis
---
metadata:
name: after
pipeline:
- notify:
image: plugins/slack
depends_on:
- frontend
- backend
The biggest issue with the above configuration is that it can get a little verbose. This can be solved by using a tool like Jsonnet to simplify your configuration and generate the yaml.
I’d also be interested in using drone with the .drone.yml being in a different repo than the tested/built code. @bradrydzewski, Is there an update to the feature you mentioned in post 2 ?
Is there any news about this feature in 1.0.0?
I’d be particularly interested in external file, option 1 mentioned here > External or periodic triggers?
Example use-case could be triggering builds for external repositories without a .drone.yml file.