In the above, only the pre-build group run concurrently, but the binaries and docker-images groups do not run concurrently.
Ideally, we’d want the binaries group to run first, and then the docker-images group to run. Any idea why this is not happening? Does it have something to do with the ordering of the steps? Do you have to co-locate the groups, i.e binaries have to all be right after the other? Same with docker-images?
So, steps are sequential, pipelines are parallel by default it seems.
Yup, I’m not disagreeing. I’m just trying to understand if the group functionality that existed in 0.8.0 still exists in 1.0.0 and if so - where is it documented. I don’t have much control over our Drone deployment, therefore I’m not even sure whether there are multiple Drone agents running on multiple machines. So ideally, if I could use group to cause multiple steps to run concurrently, that’d be the simplest solution for us at this moment.
I don’t think you can replicate the behaviour using groups in 1.0.0, someone more knowledgeable than me might correct me in case I’m wrong. However, you should be able to achieve the same results rewriting the .drone.yml for the new version, without changing the deployment.
- name: test
- go build
- go test ./... -v
- name: vet
- go vet ./...
- name: binary 1
- go build -o cmd/service-1/service-1 ./cmd/service-1
- name: image 1
custom_dns: <ip1>, <ip2>
I’m not sure how workspace was translated, I believe you need to share volumes if you want persistance between pipelines.
Sounds good. Thanks for the help @devstar. I’m going to hold-off for a bit and see if anyone else will comment on this to confirm it’s not possible with 1.0.0 and that the new format needs to be used (I mean the 1.0.0 docs do mention parallel pipeline steps, so I’d be curious to know if that was accidental or whether it really is part of 1.0.0).