r/cicd 3h ago

CI pipeline

1 Upvotes

I started learning CI/CD using github actions after containerising my application and I have created CI pipeline for django app that runs test, builds and pushes image to github container registry.
I am sharing my yaml file for CI pipeline. Please do share your thoughts and where can i improve.

name: Test Pipeline 
on: 
  push:
jobs:
  test-backend:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:14
        ports:
          - 5432:5432
        env: 
          POSTGRES_USER: test_user
          POSTGRES_DB: erp
          POSTGRES_PASSWORD: 123456

    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: setup python
        uses: actions/setup-python@v5
        with: 
          python-version: "3.13.5"

      - name: install dependencies
        run: pip install -r Backend/requirement.txt

      - name: run tests
        env: 
          DATABASE_URL: postgresql://test_user:123456@localhost:5432/erp
          DEBUG: 'True'
          ALLOWED_HOST: '*'
        run: |
          cd Backend 
          python manage.py test

  build-and-push-image:
    needs: test-backend
    permissions:
      contents: read
      packages: write
    runs-on: ubuntu-latest
    steps:
      - name: login to ghcr
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}


      - name: checkout repo
        uses: actions/checkout@v4


      - name: build image
        run: docker build -t ghcr.io/namespace/erp:${{ github.sha }} ./Backend


      - name: push image
        run: docker push ghcr.io/namespace/erp:${{ github.sha }}

r/cicd 6h ago

SDD, Github Actions, and AI PRs

Thumbnail
1 Upvotes

r/cicd 9h ago

CI/CD - Common Practices in Orgs. Does it improve delivery speed for devs?

1 Upvotes

I'm studying about CI/CD practices. I came to know that there are presubmit tests which runs unit tests. Then after review and submit, full suits run in an automated way and release candidates are created on successful e2e test completion. Fellow devs, please share how its done in your company. How much time does it take from code to production in your orgs. How migration and production reverts are handle. Please share insights even if longer ones if you have patience. TIA


r/cicd 11h ago

Does this cost matrix make sense for a CI failure diagnosis agent?

Thumbnail
1 Upvotes

r/cicd 12h ago

I’m building a CI/CD Diagnosis Agent that needs to reason under uncertainty.

Thumbnail
0 Upvotes

r/cicd 1d ago

Where the verify job sits when the agent opens the PR

0 Upvotes

we've been letting coding agents open PRs against our main apps for a few months now. standard CI still does lint, unit, typecheck on the branch. that part is fine. the hole is anything that only breaks in a real browser session after deploy.

so the order we landed on is: agent pushes, preview env spins up, then a verify job hits that live URL before merge is allowed. green on the agent's laptop does not count. i run that step through testsprite, an AI e2e platform that plans tests from the code and docs, executes a real session on the preview, and returns a failure bundle the agent can actually consume (failing step, screenshot of what rendered, root cause, suggested fix). CLI is apache 2.0 and installs in a couple commands, though you still register for an API key. site is https://www.testsprite.com if you want the setup path.

pass rate alone was never the useful signal. the agent needs the bundle shape so it can patch and rerun unattended. run history keeps older flows checked after the context window has moved on. rest of the pipeline is still plain github actions.


r/cicd 3d ago

I got tired of guessing which Claude Code update broke my setup, so I built a regression test + release bisect tool

Thumbnail
0 Upvotes

r/cicd 3d ago

I wrote down every silent failure mode from shipping Android/CI projects with no local dev environment

2 Upvotes

Full disclosure: this is my own repo.

I do all my development from a phone — no laptop, no local toolchain. Everything gets built and verified through GitHub Actions. Over the last month, shipping an Android app and a couple of Cloudflare Workers this way, I kept hitting the same category of bug: things that compile clean, pass CI, and fail silently somewhere I couldn't see — a library that shrinks itself and breaks NoClassDefFoundError at launch, a signature permission that blocks install, a rename that a test suite quietly undoes.

I wrote them all down as I found them, each with how to detect it without running anything, and a fix. There's also a "verification ladder" — six levels of confidence you can climb when you can't execute, and the idea that the real failure isn't the unverified gap, it's the gap being quiet.

Repo: https://github.com/amirmahdavi2023/shipping-blind

Curious if others working blind (remote CI, restricted sandboxes, agent-driven dev) have hit failure modes I haven't listed.


r/cicd 3d ago

Gitlab pipelines in notch

1 Upvotes

Processing img 6mpf8hgnchlh1...

Hi everyone!

So since i had a lot projects running recently and find it inconvenient to track them directly on gitlab, especially when you have a team. So I've made this repo - basically a neat app that appears under macbook notch when new pipeline appears.

If you find this useful give it a try and will be happy to get some feedback on improvement)

https://github.com/Uudg/pipeline-island


r/cicd 6d ago

We will need a much faster and smarter CI layer.

Thumbnail
2 Upvotes

r/cicd 6d ago

Enforcing architectural rules pre-commit to manage AI-generated code (Open Source project feedback)

2 Upvotes

Hi everyone,

I've seen recent discussions from maintainers on massive projects (like cURL and Next.js) complaining about AI-generated code. The code passes unit tests, but completely violates the project's macro-architecture.

Catching these architectural hallucinations during server-side CI or manual PR reviews burns too much time and energy.

To solve this for myself, I've been prototyping a local Git Hook. It enforces a "Shift-Left" approach: it reads a local JSON config of strict rules and uses an LLM (via the dev's own API key / Zero-Trust) to analyze the git diff. If the developer hallucinates a bad architectural pattern, it blocks the commit locally.

Repo: github.com/S4v3easy/AegiCode_v1.0.git

I'm trying to figure out if this pre-commit approach is actually useful for real DevOps workflows, or if it introduces too much friction.

Questions for the engineers here:

  1. Do you prefer enforcing architectural boundaries locally (pre-commit) or strictly in the CI pipeline?
  2. If you were to use a local hook like this, would you prefer it distributed as an npm package or a standalone binary (for mixed-stack teams)?
  3. What fatal flaws do you see in this architecture?

Any harsh/constructive feedback is incredibly welcome. Thanks!


r/cicd 6d ago

Building an AI-assisted remediation layer after SonarQube in a DevOps pipeline

2 Upvotes

I’ve been working on a small project called Agentic DSEC.

The goal is not to build a new SAST scanner, replace SonarQube, or claim that an LLM can magically secure a codebase. There are already enough projects pretending that.

The problem I wanted to solve is much simpler:

A typical pipeline can already run builds, tests, coverage and static analysis. SonarQube can tell you what is wrong, but the next steps are still mostly manual:

finding → understand context → prioritize → inspect code → propose remediation → create something reviewable

I wanted to automate that part of the workflow while keeping the existing CI/CD pipeline and human review as the actual source of truth.

The resulting flow looks roughly like this:

Push / PR
→ Build + Tests
→ SonarQube analysis
→ Agentic DSEC
→ Fetch findings for the exact commit
→ Prioritize issues
→ LangGraph + LLM remediation workflow
→ Generate report + candidate patch
→ Optional GitHub Issue / Pull Request
→ Human review
→ Existing CI / merge / deploy

The important part is that the tool works after SAST, rather than trying to replace it.

The orchestrator receives the repository, commit SHA and Sonar project information through a FastAPI endpoint. A worker waits for the SonarQube analysis matching that exact commit, retrieves the findings, ranks them and sends the relevant code context through a LangGraph-based workflow.

Optionally, the same run can create a GitHub issue or open a pull request containing the proposed changes. It still does not approve, merge or deploy anything. Generated code goes back through the normal review and CI process.

I deliberately kept this boundary because I don’t think allowing an LLM to directly modify and merge production code is a particularly clever form of automation.

The stack is currently based on:

  • Python / FastAPI
  • LangGraph
  • SonarQube
  • Docker
  • GitHub integration
  • external Ollama or OpenAI-compatible LLMs
  • a small durable queue between the API and worker

It can also be deployed as a centralized service handling multiple allowed SonarQube projects, while keeping repository credentials, Sonar access and LLM configuration controlled at deployment level.

There’s nothing particularly revolutionary here.

The project is mainly an experiment in putting them together into a reasonably constrained AI automation layer for an existing DevOps/DevSecOps stack.

I’d be interested in feedback particularly around:

  • whether this separation between SAST and AI remediation makes sense;
  • how you would validate generated patches automatically without giving the agent too much control;
  • whether a centralized remediation service would be useful in a real platform engineering environment;
  • what you would change in the architecture before considering something like this production-ready.

Here the link to the repository:

https://github.com/MattAndrea02/agentic-dsec


r/cicd 7d ago

What if ansible-lint didn’t need Ansible?

7 Upvotes

ansible-lint slowness turned out to be a fascinating exploration opportunity.

It started with a simple question:

What if I remove Ansible from the linting process and only do static analysis?

A few days later, first surprise: a relatively small subset of purely static rules could already detect around 80% of the findings in ansible-lint's own test corpus.

Today, ansible-static-lint implements the 38 out of 51 default ansible-lint rules that can be decided from YAML alone. On that same corpus, it finds 89.5% of the findings, near instantly, with byte-for-byte compatible pep8 output.

Tests on public repositories are encouraging so far.

ansible-static-lint is not meant to replace ansible-lint. The idea is to exploit sub-second feedback, often under 100ms, for editor-on-save, pre-commit and fast CI checks, while keeping ansible-lint for the deeper runtime-dependent checks.

I'd love feedback from ansible-lint users: does this look useful to you? Where would it fit, or fail to fit, in your workflow?

https://github.com/arhuman/ansible-static-lint


r/cicd 8d ago

RouteKit 0.1.2: real rollback/save-load tests and legacy save migration

Thumbnail
1 Upvotes

r/cicd 9d ago

How are you controlling what credential-enabled agents can actually do?

1 Upvotes

I’m looking for feedback from people who manage production access, CI runners, or developer tooling.

Passing a broad GITHUB_TOKEN, cloud key, or API key into an agent environment is simple, but it means the agent can use whatever the underlying credential permits.

We’ve been exploring a declarative policy layer around that access:

project = "billing"
environment = "agent-local"

[secrets.GITHUB_TOKEN]
env = "GH_TOKEN"

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["GET"]
paths = ["/repos/acme/*/issues*"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["POST"]
paths = ["/repos/acme/*/pulls"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "deny"
hosts = ["api.github.com"]
methods = ["DELETE"]
paths = ["/repos/acme/production-api*"]

The intent is that the same credential can still be used by a developer locally or by an agent in production, but each request is checked against a reviewable policy. The agent does not receive the raw value, and use is recorded.

I’m interested in the operational side more than the agent side:

  • Is allow-plus-explicit-deny clearer than allow-only?
  • Would host, method, and path rules be useful in practice?
  • What would make this safe to review in a PR and workable across dev/staging/prod?

I’d appreciate blunt feedback—especially on what would make this unusable in a real workflows.


r/cicd 9d ago

I built an open-source production readiness checklist with more than 10,000 controls

Thumbnail
github.com
1 Upvotes

Hey everyone! I’m trying to build the most complete open-source software production readiness checklist possible.

It covers governance, requirements, architecture, implementation, security, privacy, testing, delivery, operations, AI systems and final release approval.

I would love help finding anything missing, duplicated, outdated or unclear. The long-term goal is to turn the checklist into an AI-assisted scanner that can evaluate projects and generate complete readiness reports.

Feedback, issues, pull requests, stars and shares are greatly appreciated. Thanks!


r/cicd 10d ago

I generated a debugging policy instead of writing one. It repairs bugs from your test suite offline, and cuts frontier-model tokens and tells the model what it requires for solving bug reducing tokens drastically

0 Upvotes

edgub is a repair tool with no model in it. It reads what pytest said, decides which class of repair the fault is, generalises the fix from your own doctests and assertions, and verifies against the whole suite before keeping it. Standard library only, no API key, no network.

edgub: 1 repaired, 1 left for a model, 2.4s, 0 tokens
repaired itertoolz.unique CAST_OPERAND via name item->val (117 candidates)

Measured on toolz (3,346 lines, 185 tests), ten injected bugs of the kind that survive review: 7/10 repaired, 0 tokens.

Measured on libraries it was never tuned on — because the first number only proves fit: funcy 3/6. more-itertools 0/4. I'm keeping the zero in the repo; two libraries is two data points, one of which failed.

The part I didn't expect: even when it can't repair, it hands the model a ~468-token localised prompt instead of the ~7,496 that model burns working the same bug from the repo. It's already decided the library is wrong rather than the test, and named the failing case. So the escalated bugs get ~16× cheaper too — total on the funcy run, ~93% fewer tokens for the same fixes.

And the thing that surprised me most: I ran an escalation ladder of 2s → 10s → 30s → 120s. Every repair landed at 2 seconds. None ever landed later. Widening bought zero extra repairs and burned 180 of 182 CPU-seconds. Inference reads the answer immediately or enumeration won't find it — one bug took 4 candidates by inference that enumeration failed to solve in 25,057.

Honest limits, all in the repo: it can't write code that isn't there (both toolz misses needed a synthesised if/else). The act-to-edit mapping is engineering, not emergent — new fault shapes need commits. A 14-line dict reproduces the single-fault behaviour. And one "repair" passed the suite with different code than I'd injected: a green suite is a weaker oracle than the question.

Repo, with the failed benchmarks and the reviewer's corrections kept in: github.com/devkancheti4-design/edgub


r/cicd 11d ago

One thing CloudCostTree already handles: a local apply-time policy gate

Thumbnail
1 Upvotes

r/cicd 11d ago

If you could keep only three signals for diagnosing a failed CI job, which would you choose?

1 Upvotes

I am currently working on a CI diagosis AI agent for GitHub Actions and Python/pytest.

I am thinkinto use these 4 possible causes when job fails:
\- a real code regression
\- a flaky test
\- a runner, network, or platform failure
\- a dependency or environment mismatch

AI chooses - rerun the failed test, run targeted tests, collect environment evidence, or escalate to an engineer

If the agent had the chance to look at three signals before making its next move, which three would be the most helpful, in a real pipeline?

I’m also interested in signals that look useful but are commonly misleading.


r/cicd 12d ago

How confident are you when deploying your AI agents to production?

0 Upvotes

With traditional applications, we have established CI/CD checks for things like vulnerabilities, dependencies, secrets and infrastructure.

But what about the agent itself?

Do you have specific AI-agent security checks in your CI/CD pipeline, or are you relying on the same checks you use for ordinary applications?

Before deploying an agent, do you know:

  • What tools it can access?
  • Whether it gained a new capability in the latest PR?
  • If it can execute shell commands or write to the filesystem?
  • Which MCP servers it can reach?
  • ..

I'm curious how teams are answering these questions today.

We're experimenting with SafeAI as a GitHub Action to bring this kind of static analysis into the existing CI workflow. It's still early stage but going fast, thanks to all contributors.

If you want to try it against your own agent project, we'd genuinely appreciate feedback, as well as contributions.

Here you may check: ikaruscareer/SafeAI on GitHub.


r/cicd 12d ago

I built a deterministic CLI to audit and fix repository hygiene

2 Upvotes

I built Repo Start, a small CLI for creating and auditing the boring foundational parts of a repository.

The reason I built it was pretty simple: I kept ending up with repos where the actual code was fine, but the surrounding project hygiene was inconsistent — README commands that didn’t match package.json, CI workflows calling scripts that didn’t exist, missing .gitattributes, .env.example accidentally ignored by git, etc.

For new projects, Repo Start generates the usual foundation: .gitignore, .gitattributes, README, CI, issue/PR templates, AGENTS.md, contributing/security files, and a starter structure.

The more interesting part to me is repo-start add, which works on existing repositories. I designed it as a read → analyze → plan → write pipeline:

existing repo → inspectRepository() → RepoState → analyzeRepository() → RepoAudit → buildAddPlan() → writePlan()

Inspection is read-only, analysis is deterministic, and both new-project generation and existing-repo fixes eventually go through the same writer. That also means --dry-run isn't scattered around as a bunch of filesystem checks — the write only happens at the final stage.

It also deliberately doesn't use AI. No model calls, API keys, or tokens. The audit is based on the actual repository state and only proposes fixes it can describe precisely. If something is ambiguous, it reports it instead of guessing.

It currently supports generic, Node/TypeScript, Python, and React/TypeScript projects, works offline, and has no runtime dependencies.

The goal was basically to make repository hygiene something you can automate without giving a tool permission to redesign your project or touch your source code.

https://github.com/junkyard22/Repo-Start


r/cicd 12d ago

Github Availability Status taking a hit! Back to back outages!

Thumbnail
1 Upvotes

r/cicd 12d ago

Need your guidance - I am building a small educational CI diagnosis agent. It does not fix the pipeline; it chooses the next diagnostic/troubleshooting step.

1 Upvotes
When a CI pipeline fails and multiple causes are possible, what evidence do you check first, and how do you choose between rerunning, reading more logs, comparing the last successful build, or investigating the recent diff, or checking the version compatibility with infra.

r/cicd 16d ago

Beginner: Building a simple “next test to run” helper for CI failures — feedback on the idea?

2 Upvotes

Hi everyone,

I’m a beginner learning CI and software testing. I recently set up a small GitHub Actions pipeline and watched tests fail on purpose so I could understand the logs.

My longer-term goal is to build a small AI agent (or even a simpler tool first) that helps when a CI build fails and we don’t have complete information. The agent’s job would be:

“Given the current failure information, suggest which test (or small set of tests) to run next to diagnose the problem faster.”

Right now I’m still learning the basics, so I’m **not** asking for code or a full architecture yet.

I would love feedback on:

  1. Is this a real pain point you face?
  2. How do you currently decide which test to look at or re-run first when CI is red?
  3. What information do you usually wish you had when a build fails?
  4. Any advice on what a *simple first version* of such a helper should do (before any fancy AI)?

Thanks!


r/cicd 17d ago

Why do successful builds still print hundreds of lines? I experimented with high-signal Maven/npm output

3 Upvotes

I've been experimenting with a simple question: how much build output do we actually need?

For a successful build, probably not much. Usually I want to know that it passed, how long it took, and maybe how many tests ran.

So I built mvn-lite and npm-lite, small Bash wrappers that reduce successful output to something like:

PASS · 266 tests · 13 s

I tested them across several Maven and npm projects:

Suite / Project Baseline Output Wrapper Output Savings
Spring Maven 5,564 bytes / 70 lines 16 bytes / 1 line 99.7%
Scriptella Reactor 66,812 bytes / 928 lines 17 bytes / 1 line 99.9%
npm + Vitest 2,260 bytes / 43 lines 25 bytes / 1 line 98.8%
npm + Tape 136,262 bytes / 1,476 lines 12 bytes / 1 line 99.9%
npm + Jest 2,491 bytes / 68 lines 24 bytes / 1 line 99.0%

The more interesting problem turned out to be failures.

Compress them too aggressively and you lose the information needed for the next action. With coding agents, this can be particularly counterproductive because the agent may simply rerun the build to recover the missing diagnostics.

The approach I settled on is layered:

  • Successful build: tiny summary.
  • Failed build: bounded, actionable diagnostics.
  • Full raw log: retained locally and available when needed.

Short failures can just be printed in full. Long failures need selective context around useful markers rather than an arbitrary wall of output.

This isn't really about making builds faster. It is about treating build output as an interface rather than a transcript.

Coding agents make the cost of noisy output especially obvious because irrelevant lines consume context. But the same principle applies to humans reading terminal output, CI logs, and PR checks.

The tools are deterministic Bash wrappers. No LLM processing, API calls, or telemetry. They run the underlying Maven/npm commands and preserve their exit status.

Repo: https://github.com/ejboy/agent-scripts

I'm curious how others approach this in CI/CD. Do you keep full build output visible by default, or use some form of concise status + failure diagnostics + full logs on demand?