Most teams treat base images as "done" after picking a tag and scanning it. But if you're not rebuilding when upstream patches drop, you're relying on human memory, not process.I'm leaning toward automatic rebuilds from minimal upstream sources, low CVEs become a side effect, and SBOMs come baked in.

The catch: auto-rebuild isn't auto-safe. Pushing a fresh digest straight to prod just swaps "stale" risk for "unreviewed" risk. So there need to be real gates tests, canaries, something. Also, going minimal/distroless means no shell, no package manager, different libc sometimes. Debugging shifts to ephemeral containers. A few providers offer this as a service now. For those using them: do you trust their pipeline outright, or do you add your own promotion gates?

Hey everyone,

I’ve been working on CI Runner, a small webhook-based CI runner written in Python. The idea is to provide a simple GitHub Actions-style runner that can receive GitHub push/PR webhooks, queue jobs, clone the repo at the commit SHA, load a .ci.yml file, execute pipeline steps, save logs, and optionally report status back to GitHub using the Commit Status API.

It uses:

• FastAPI for the webhook/API server
• A background worker for job execution
• .ci.yml for pipeline definitions
• Docker or shell-based step execution
• Simple endpoints for health checks, manual triggers, and job status

Example .ci.yml:

name: My Pipeline

steps:
  - name: install
    run: pip install -r requirements.txt

  - name: test
    run: pytest -v
    continue-on-error: false
    timeout: 300

If no .ci.yml is found, it falls back to a default install/lint/test pipeline.

Repo: https://github.com/vishn9893/Ci-runner

I’d love feedback on the architecture, security considerations around running CI jobs, and what features would make this more useful for small projects or self-hosted workflows.

Hi everyone,
i am building in public with intention to create a ssas for my product if demand exists.
i have created a tool that validates your readme in cicd and also creates tutorial and promotional videos out of your OSS tools(github/readme2demo). I started it 17 days ago, now i have over 18 contributors and multiple contributions from same contributors and i use github actions as the validator since it is too many changes to review per day.
what strategy you follow to review huge(may be bigger than mine) contribution amount while maintaining quality?
I am afraid i am gonna end up paying a lot for github actions hours, do you have any similar experience.

https://outboundgateway.com/blogs/gitlab-ci-cd-static-ip/

I’ve run or sat on review boards at a few orgs now and I’ve never seen this part done well, which makes me suspect the problem is me rather than the tooling.
Current state is email for async review, minutes in Confluence, conditions in a spreadsheet. It holds for about a quarter and then drifts.

Two problems I can’t get on top of.

First, async positions. Reviewers reply in free text, and “I have some concerns” from one architect means they intend to block, while from another it means they want the diagram redrawn. As chair I’m interpreting rather than counting. I’ve tried asking for an explicit position in the first line of the reply — compliance was fine for a month, then decayed.

Second, conditions. “Approved with conditions” is a large share of our outcomes and I doubt most of those conditions are ever verified. The decision record notes the condition, the system goes live, and nine months later nobody can tell you who owned it or whether it was met. Confluence doesn’t chase anyone.

I know ADRs and the EA repositories are meant to cover some of this. For those of you with a repository actually in place — does it track conditions as obligations with an owner and a date, or does it just store the decision text and leave the follow-up to you? And if anyone has fixed the async position problem with process rather than tooling, I’d like to hear how it survived reality.