Non-web-based CI tool for CLI

I need help and ideas

George Shuklin
OpsOps
3 min readJul 5, 2021

--

Today it’s not a ‘happy discovery’ post, I have nothing to share. Instead, I’m asking for advice and for ideas, no matter how daring they are.

The problem

I want to have a tool to work like CI. Take a ‘pipeline’/’workflow’ declaration, run foobar-ci job.yaml , and you have everything normally happened on CI servers, but in your own consoles. Jobs, dependencies, artifacts, cleanup code, etc.

I don’t want it to have some external servers, as I want it to be local to terminal I’m running it on. If ‘terminal’ is a remote server, that it’s a remote server. If terminal is my laptop, it’s a laptop. Home PC is home PC, and so on.

Moreover, and it would be a +50% success, I want to be able to use --pdb option of pytest (open interactive Python shell if test fail).

Not-a-solutions

Make

The very old tool which sounds almost promising, but has issues with syntax (use TAB LEVER G-4 on your TABULATOR MACHINE to set TABULATIONS for you PUNCH CARD), and it’s heavily dependent on local file artifacts to decide what to do and what not (the most usual ‘test-deploy’ combination of stages for CI).

Gradle

It’s too much java, and it’s file-based tracking. I just don’t want too much java (syntax including) to get close to me.

CI-in-docker/localhost

There are some reasonable ideas about ‘run CI server in docker and use it’. I’ll study them, but I’m not a big fan of servers-under-the-hood, and they definitively does not have --pdb option available. For now I was named three:

  • drone-io
  • circle-ci Local-CLI
  • concouse-ci
  • jenkins

Out of those two concourse sounds the most attractive (open governance, lack of vendor-cloud-locking, nice CLI to ‘pull’ logs and display them locally). Jenkins is too big and too javy (even I have tons of expirience with it). Drone.io is a bit dubious based on their business model, circle-ci allows to do local run, but only for jobs (not workflows).

Ansible, chef-solo, etc

Any mangling orchestrator (one, which heavily annotate output, adding a lot of own test, or compresses it, or even hide output) is big no-no. Ansible can’t run Ansible with reasonably readable output in case of errors. Same goes for pytest or any fancy testing framework.

Molecule

For simple CI-testing jobs molecule is love-hate system. It has certain advantages (mostly in Ansible integration), and it gives some niceness to results. It keeps output intact, but not to --pdb level (there is issue on this).

The main downside of Molecule is that it strictly testing system. It follows create-converge-test-destroy pattern, and whilst it’s possible to fight against it (f.e. ignoring create/destroy stages), the general idea of ‘ephimeriality’ persists. Moreover, there is zero considerations for job linking (f.e. you can’t do ‘deploy’ after successful test).

A cloud

Just in case if it wasn’t clear from the problem description, any cloud-based solution (github, gitlab, circle-ci, you name it) is not an option 100%, because I can’t run in on my laptop (in the mountain trip where even 2G may be a luxurious offer available sparsely).

Conclusion: I need ideas and names

If you have your favorite tool, now it’s a perfect time to scream the name in the comments. If you are not medium commenter, but committed to write me, use my email: george.shuklin@gmail.com.

If you feel I missed something, please say. I’ll update this post as I sieve through low-key sources, or if I get any insights from commenters.

--

--

George Shuklin
OpsOps

I work at Servers.com, most of my stories are about Ansible, Ceph, Python, Openstack and Linux. My hobby is Rust.