Disable kyllingstad/zmqd

[Geod24]

Since the new release, it requires a zmq >= 4.3 but the machines have 4.1.4.

A temporary measure to make Buildkite green again...
@wilzbach : I grepped for zmq but I only saw a reference to version 3 (?) in ansible. Any chance you could take a look at this ?
CC @kyllingstad (sorry, didn't foresee that one).

[dlang-bot]

Thanks for your pull request, @Geod24!

[Geod24]

Note: We really, really need to fix this problem. Buildkite breaks way too often thanks to new releases.
I wanted to make progress on DIP25, asked for a release (kyllingstad/zmqd#24 (comment)) and ended up breaking Buildkite because there's no way to know before a release is made if it'll break...

[wilzbach]

I don't have access to the build agents. Sorry.

I'm aware that it breaks often, but except for removing those packages or replicating Travis closer I don't know how we would go for fixing this. Setting up a CI that can be run for all these projects is quite some effort and also consumes resources...

[Geod24]

I'm aware that it breaks often, but except for removing those packages or replicating Travis closer I don't know how we would go for fixing this. Setting up a CI that can be run for all these projects is quite some effort and also consumes resources...

Random ideas, throwing them here to pick your brain:

• Require a Dockerfile.dlang-ci at the root of the tested projects: this would be compatible with Travis, as one can use service: docker in Travis. However it could clash if some projects already require Docker for their tests (because images spawning other images can be complicated).
• Trying to use the Travis image locally. I looked into https://stackoverflow.com/questions/21053657/how-to-run-travis-ci-locally/49019950#49019950 a while back when dub was segfaulting all over the place, but I failed to make it work well.

In any cases, I see the following as issues at the moment:

• Dependencies are global, so two projects cannot have conflicting dependencies;
• Dependencies are set, so projects adding dependencies will break;
• Projects are only tested on our end, not theirs, and often unaware of what is happening;
• Project list is fixed
• Any update require a new tag: I'm a bit on the fence with this. On one hand it's a good way to ensure we don't do too many changes that would break downstream, on the other it means more work on the project's side.

I think dlang/ci is one of the best productivity boost we've had in the last few years, so being able to make it more reliable / extendable would be amazing.

Also: Github CI is pretty good. It has built-in cross-platform testing (on the 3 major OS), is quite reliable (but not as reliable as Travis in my experience), integrates better with Github, and is much faster.
If Github happens to take over the action for it (see https://github.com/mihails-strasuns/setup-dlang/issues/13 ) it will be a no-brainer to use it instead of Travis