Firstly I’d like to just say that Drone is pretty damn awesome. I got it set up yesterday so fast, and had a build running in no time with very little configuration. That being said, I cannot help but compare it to other systems I aim to move away from. There are only a few areas that are stopping me from doing so already, though I’m not sure if at least one of them will steer too far from Drone’s core ideals.
Matrix Groups: I think it’d be nice to be able to say “these steps should run with these different values for these variables, but these others should not”. Right now I have a very, very simple pipeline that’s just testing some Go code, then notifying me on Slack. I get the notification twice! Maybe I’ve just missed that this is possible already though.
Standalone Jobs: Coming from Jenkins (and also having tried Concourse) I really appreciate the ability to sometimes run arbitrary jobs on their own. For example, bumping SemVer versions, or syncing environments. This might be too much to ask though - perhaps you have some other recommended way of handling this kind of thing in that case?
Multiple “Resources”: À la Concourse resources, that is. Right now a Git repository is cloned at the start, but what if your project has multiple repositories and you want them all in one pipeline? Would you have to just use something like Git sub-modules in a repository that aggregates those other repositories?
I think those are pretty much my main concerns right now coming from other tools. It’s not an easy problem to solve, and definitely not easy to keep everyone happy. I just want to say how impressive it is that the configuration is so small for a custom pipeline. At one point my pipeline was shorter than my Travis one!
You can emulate this behavior in Drone. The difference is that Drone mandates you store your configuration in version control. So if you want to setup a job, you need to create a repository for that job, from which Drone can fetch your configuration.
Keep in mind that Drone tightly integrates with version control. This leads to a more integrated experience (in my opinion) compared to Jenkins but also means that Drone is more focused on continuous delivery as opposed to generic cron and task management (there was a time Jenkins called itself a task manager for the web). It is unlikely we would ever change this about Drone, but it is very likely we would take the core drone libraries (pipeline, etc) and create a separate, light weight, standalone task runner without any direct link to a repository.
You could use git submodules or you could add a step to your pipeline that clones your repositories. There are also plugins for launching downstream builds, similar to Jenkins.
pipeline:
setup:
image: docker:git
commands:
- git clone https://github.com/foo/bar.git
- git clone https://github.com/foo/baz.git
- git clone https://github.com/foo/qux.git
build:
image: golang
commands:
- go build
- go test
That does cover off most things very well. My only remaining question is still about the matrix support - just a quick one. The documentation you linked to does show how it would be possible to achieve almost what I want, but in the case shown, wouldn’t it mean that if; for example, I was testing against 2 versions of Go, then if one failed and the other succeeded that I’d only know about one of those results? It’d be nice to say “at the end of all matrix variations, then do this thing, so we have the result for the job as a whole” so you can have a more definitive way of getting a single, valid result.
Right now the only way I can see to do that specifically is with separate entries for each version without matrices, and instead use fanning out and back in with parallel task execution.
tldr; this can be implemented as plugin. There has been a good amount of interest in this capability, and creating plugins for drone is dead simple, however, there are currently no community volunteers to build and publish such a plugin.
Hmmm, that is an interesting idea, though I think it may still be a tad inflexible. The only way to continue onward after that point with more tasks would be to specify that same environment in a when clause, which would also prevent you from using other matrix values later on too. Each task following task would be both restricted, and have to have more information associated with it.
What if you had something where you could specify which matrices to run against a task with? So, if you could group them up and apply them to specific tasks:
This would mean you wouldn’t have to specify anything extra on any further tasks, and Drone would automatically run the task with the matrices on in parallel. Once all of them were successful (or however else you want to apply when at that point) you could move on and just do that aforementioned single-run task (or in the examples case, tasks).
The general policy is that these sort of things need to be implemented and prototyped as plugins first, before being considered for drone core. The benefit of plugins is that we can iterate independently from drone core, and it also allows other teams to fork / alter the logic and play with alternate approaches.
We are also very conservative with yaml changes, which is another reason this would need to be flushed out using plugins.
Also, I should mention, the challenge with the proposal above is that we do not store steps as structured data. If you consider that matrix jobs can execute on multiple nodes, this limitation makes it impossible for drone to notify an agent that an individual step has completed because this information is buried inside a stream of logs.
There is an open issue to store steps as structured data, but it will be a breaking change, and will take a few weeks to complete (I am working on it now) https://github.com/drone/drone/projects/1
Even when this capability exists, the agents will need to use REST endpoints to poll or receive notification of step completion. For this reason I still believe this capability could be prototyped as a plugin first, since plugins can access the API.