Bash workflows are broken — I built a tool to make them predictable again

артем — Sat, 09 May 2026 08:54:08 +0000

If you’ve ever debugged a broken CI pipeline at 2 AM, you probably know this feeling:

“It works locally, but fails in CI”
“What changed since last deploy?”
“Why does this script behave differently on another machine?”

Shell workflows are powerful, but they have a fundamental problem:
they are not reproducible, not observable, and not structured by default.

I kept running into the same issues across different projects, so I decided to experiment with a small tool to fix this at the CLI level.

The problem: shell workflows are invisible systems

Bash and CLI tools are great, but they share a few weaknesses:

❌ No built-in logging

Once a command runs, it disappears unless you explicitly log everything.

❌ No reproducibility layer

Two developers running the same script can still get different outcomes.

❌ CI/CD setups drift over time

YAML configs, scripts, and environment assumptions slowly diverge.

❌ Debugging is mostly guesswork

You reconstruct what happened instead of observing it directly.

The idea: what if the terminal had a “trace layer”?

I wanted something simple:

every command is logged
workflows are reproducible
pipelines are predictable
debugging is deterministic instead of reactive

So I started building a small CLI toolkit called OLS (Open Linux Shell).

What OLS does

OLS is not a shell replacement.
It’s a toolkit layer on top of CLI workflows.

It focuses on three things:

1. Observability for CLI workflows

Every action is recorded so you can trace what actually happened.

2. Predictable environment checks

Instead of “it works on my machine”, you can validate setups explicitly.

3. Pipeline-first design

Tools are designed to work cleanly in CI/CD environments.

Example: CI/CD setup in one command

Instead of manually configuring GitHub Actions or copying templates:

cicd init

This generates a ready-to-use CI/CD pipeline.

Example: environment validation

ols doctor

Checks your system and highlights issues like:

missing dependencies
misconfigured environment
potential runtime problems

Why this matters

Most teams don’t fail because of code.

They fail because of:

inconsistent environments
unclear system state
missing visibility into what actually happened

OLS tries to reduce that gap by making CLI workflows more observable and reproducible.

Philosophy behind OLS

The design is based on a few principles:

1. Everything must be traceable

All actions should leave a clear trace so debugging becomes deterministic.

2. Minimal cognitive overhead

Commands should be simple and predictable, without unnecessary flags or complexity.

3. Pipeline-first thinking

Every tool should work naturally in CI/CD environments and support stdin/stdout workflows.

4. Offline-first usage model

Packages are downloaded once and cached locally for reuse.

Current status

OLS is an early-stage MVP.

It is:

experimental
evolving quickly
open to feedback and contributors

The goal is to explore whether adding a lightweight “observability layer” to CLI workflows actually improves developer experience in practice.

What I’m looking for

Right now, I’m mainly interested in:

feedback from DevOps / backend engineers
real-world edge cases
ideas for improving CLI observability
whether this approach is useful beyond personal workflows

Closing thought

We already have observability for systems, logs for applications, and metrics for infrastructure.

But our terminal workflows are still mostly invisible.

OLS is an attempt to change that — starting with something simple.

If you’ve worked with CI/CD, bash automation, or messy shell scripts, I’d really appreciate

I stopped guessing in CLI — logging changed everything

артем — Wed, 25 Mar 2026 13:41:44 +0000

I used to guess at the commands, typing in the console: ls /var/log | grep "EE" But that didn't help. At some point, I started logging everything, and now I can see everything I do. Errors appear immediately. You can filter them right in the pipeline.

lslog | grep EE

I compiled this into a small tool: https://github.com/artemkolba321-spec/OLS

Why I built OLS for predictable CLI workflows

артем — Wed, 25 Mar 2026 12:12:58 +0000

Every time I worked with pipelines and logs in Linux, I found it difficult to keep track of what was happening inside scripts. Bugs would sometimes show up too late, and debugging could take hours.

To solve this, I created OLS — Open Linux Shell. All actions are now logged clearly and predictably, and the tools are designed for pipelines, so complex command chains run smoothly without surprises.

There are built-in commands to check dependencies or search logs for errors, all included in OLS without needing extra scripts.

# Check dependencies
ols doctor

# Trace a script and filter output
ols ./myscript.ols | grep "$HOME"

For those interested, the code is available as artemkolba321-spec/OLS.

Forem: артем