I’ve been testing my pipeline changes locally by using drone exec (I think it is brilliant to have a way to verify pipeline changes before checking in!). However, when I finally pushed my changes, I had three successive errors on drone server (fix first, see second, fix second, see third).
One of the services in my pipeline had commands, ports, and depends_on. The first error: Cannot configure both commands and custom attributes [ports]
I removed ports and pushed. The second error: Cannot configure both commands and custom attributes [depends_on]
I don’t know if the client was honoring ports or depends_on because it executed the same with and without these values…but, despite errors on the server, there were no validation errors on the client. I removed [depends_on] and pushed.
The third error was with detach: true (again, defined on one of my services). When running locally, the behavior I observed showed that drone exec was indeed honoring this flag. However, when I pushed the change with detach: true, drone server didn’t complain about the tag or value, but the pipeline failed because drone server was ignoring or unaware of this flag.
I am using drone 0.8 on my client (and I believe that it is the same version on the server). Does drone client and server use the same lib to read, validate, and execute the pipeline yaml?
The server and CLI use the same execution library. The two primary differences between the CLI and the server are the following:
the server clones your code from a remote repository and the CLI mounts your code from the local filesystem.
the server has more metadata automatically available (commit sha, branch, etc) from the github webhook. All of this data can be provided to the CLI via command line flags, but is often left blank by the end user.
These are the two notable differences between the the CLI and server. The server and CLI can never behave exactly the same because of these differences, but will behave mostly the same as they share the same code.
One of the services in my pipeline had commands, ports, and depends_on. The first error: Cannot configure both commands and custom attributes [ports]
I don’t know if the client was honoring ports or depends_on because it executed the same with and without these value
Neither the ports or depends_on are supported. Newer versions of the Drone runtime library will throw an error when trying to use these unsupported fields, and older versions will ignore.
The third error was with detach: true (again, defined on one of my services). When running locally, the behavior I observed showed that drone exec was indeed honoring this flag.
All services are detached: true by default. So setting this value in the services section will not make any difference.
To me it sounds like a version mismatch, with the newer version returning an error when attempting to use unrecognized fields, and the older silently ignoring these fields. This is just a best guess. Sample configurations and steps to reproduce would provide additional insight.
Thanks again, @bradrydzewski. we found the issue and appreciate your help and patience as we’re still new to drone and still understanding how things work. As you said, the problem wasn’t with detach: the issue was that three separate containers, based on the same image (redis:3), were all configured to use the same cluster config file. an error was thrown by redis because each cluster node needs its own cluster file (this file cannot be shared). I believe that drone mounts the same virtual volume for all containers in the pipeline by design (this is very likely the way drone shares the working directory across pipeline steps). we fixed the issue simply by specifying a different cluster config file name for each redis container.
I also agree that the other two inconsistencies could be a version mismatch. I’m running OSX (El Cap); when I do a brew install drone, I get version 0.8.0. our drone agents are running version 0.8. looking at docker hub, (at the time of this writing), drone/agent:0.8.0 was updated ~3 months ago whereas drone/agent:0.8 was updated five days ago. based solely on version numbers (as I understand brew install doesn’t pull from docker hub), my drone client could be running an earlier version than my drone agents. is there a way for me to sync my drone client to guarantee that it is running the same version as the agent?