Research: Migrating to github actions or circleCI

[aelsabbahy]

Describe the feature:

Find a new CI provider other than travis-ci.org. Queue times have been 45m-1hr as of late.

Describe the solution you'd like

A CI provider with reasonable queue time

Added bonus if easy to reproduce locally, Ex: Github Actions + https://github.com/nektos/act ?

Describe alternatives you've considered

Turning it off and back on again

[petemounce]

Can I recommend https://cirrus-ci.org/ ?

I'll happily do the work to experiment so we can compare side-by-side.

I'm motivated to suggest it because I think it looks more capable than travis and github.

I'm also happy to be disagreed with and the experiment discarded if once I've wired it, it doesn't look like the best choice for some reason.

[aelsabbahy]

Never heard of cirrus-ci to be honest. But the cirrus-cli looks interesting.

There are many layers to this issue.. and maybe it needs to be broken up into multiple tickets.

High-level thoughts on things that need changing:

1. Simplification of build/test - This needs a big re-write... and maybe deserves its own ticket
2. Ability to isolate 1 in a way that provides consistency between local and CI (as much as possible)
3. Finding the best CI provider to run 1,2 above

So For 2 and 3, my high-level thoughts:
The way goss is today doesn't reflect how I typically like to do CI/CD. I have a strong bias towards single responsibility as much as possible. So:

• CI engine should be nothing more than a generic orchestrator of things.
  • Basically nothing more than a list of "what to run" and "when to run", ideally those things are one-liners.
  • Support secrets management
  • The only other requirement is that it's fast, so caching & short queue time.
• CI build/deploy tools - This should be a set of tools that work consistently between local and CI. This is what the CI engine will call

For 1 - the current build/test/release scripts are a mess.. Very verbose, lots of bash code stringing it all together. High-level thoughts on changes:

• Need a simple target for all lint related stuff (maybe get rid of codeclimate for now.. not sure, I don't like that it's "remote"/SAAS)
• Simple target for building binaries
• Docker image tests should be limited to OS-specific tests, there's currently lots of duplication here that make this brittle. Ex: rpm vs deb, systemd vs initv
• Remote dependencies need to go. So DNS, httpbin, tinyproxy, etc.. maybe docker-compose is a good solution here.
• More unit tests, less reliance on integration tests

Some tools of interest so far:

• https://github.com/nektos/act
• https://github.com/cirruslabs/cirrus-cli
• https://github.com/go-task/task
• https://3musketeers.io/ - KISS, battle-tested tools
• docker-compose
• https://github.com/testcontainers/testcontainers-go - Keep it in go

At a high level, I want it to be super simple next time the need to switch CI tools arises again.

[aelsabbahy]

At a high level can you give me a quick sales pitch on cirrus-ci and what it does better than circle, github-actions, https://semaphoreci.com/, etc..?

semaphoreci is one I've always been interested in. Especially when I was trying to build my own CI engine (long story) due to its speed. I don't think windows is supported though :(

[aelsabbahy]

The priority on this just got a lot lower. Switching from travis-ci.org -> travis-ci.com made the queue go from 45min-1.5hrs down to seconds.

I'm leaving this ticket open as a good discussion regarding different CI options that are out there and can look into what they offer compared to travis-ci.

[mbainter]

I think it might be work looking at github actions. If you're open to it I may put together a proposal there that we could test and compare. You're right that there's a lot of heavy lifting to do in the build and test process generally though, and I may start taking a look at that. The faster and more painless we can make that the more people who try to help will stick around.