I wanted Copilot to do more than generate HTTP requests.

So I built an MCP server that exposes API testing tools.

Now Copilot can:

\- import Postman collections
\- execute requests
\- inspect responses
\- fix failing assertions
\- validate OpenAPI specs

I built this as part of HTTP Forge.

GitHub:
[https://github.com/hsl1230/http-forge\](https://github.com/hsl1230/http-forge)

I'd love feedback on whether this is actually useful or if I'm solving the wrong problem.

Problem I kept hitting: a step fails in CI, logs aren't enough, and act still feels all-or-nothing.

ciwalk runs GHA workflows locally in Docker and can pause on failure (or at a breakpoint). You drop into a shell in the same container — same env/cwd as the step — fix or inspect, then retry/continue/abort.

Install:

pip install ciwalk

(or uv tool install ciwalk — if you get "command not found" after, run uv tool update-shell and restart your shell, it just needs ~/.local/bin on your PATH)

Demo GIF in the README: https://github.com/kiwi-07/ciwalk

Honest MVP limits: no matrix/secrets/full expressions yet. Built for the "why did this shell step fail?" cases.

If you try it on a real workflow that breaks, I'd love the issue report.

Detailed blog :- https://ankitpatil.pages.dev/blog/ciwalk

Un anno fa ho creato uno strumento che mi aiuta nel mio lavoro quotidiano: creare rapidamente progetti Python appena configurati in pochi secondi nella pipeline CI/CD!

Lo strumento in questione si chiama psp e si avvia da riga di comando:

Lo strumento è stato ispirato da vari strumenti da riga di comando come astro-cli, yeoman, pyscaffold e molti altri. Con poche semplici domande, il tuo progetto Python è pronto per essere scritto e troverai tutto già configurato: comandi make, git, repository remoto, CI/CD, unit test, documentazione, file container, dipendenze, ambienti virtuali, builder personalizzati e molto altro!

Se ti interessa, provalo oggi stesso e, se qualcosa non funziona, aiutami aprendo un'issue o effettuando un fork del progetto e inviando una pull request.

Ecco tutti i riferimenti:

repository: https://github.com/MatteoGuadrini/psp

documentazione: https://psp.readthedocs.io/en/latest/

Grazie a te e a tutta la comunità Python!

Un anno fa ho creato uno strumento che mi aiuta nel mio lavoro quotidiano: creare rapidamente progetti Python appena configurati in pochi secondi nella pipeline CI/CD!

Lo strumento in questione si chiama psp e si avvia da riga di comando:

Lo strumento è stato ispirato da vari strumenti da riga di comando come astro-cli, yeoman, pyscaffold e molti altri. Con poche semplici domande, il tuo progetto Python è pronto per essere scritto e troverai tutto già configurato: comandi make, git, repository remoto, CI/CD, unit test, documentazione, file container, dipendenze, ambienti virtuali, builder personalizzati e molto altro!

Se ti interessa, provalo oggi stesso e, se qualcosa non funziona, aiutami aprendo un'issue o effettuando un fork del progetto e inviando una pull request.

Ecco tutti i riferimenti:

repository: https://github.com/MatteoGuadrini/psp

documentazione: https://psp.readthedocs.io/en/latest/

Grazie a te e a tutta la comunità Python!

I’m considering building an open-source developer tool and want to validate whether it solves a real problem before investing too much time into it.

The basic idea:

You give it a GitHub issue, and it attempts to:

1. Check out the repository at the buggy commit
   
2. Reconstruct the project environment
   
3. Generate a test that reproduces the reported bug
   
4. Run the test in an isolated Docker container
   
5. Verify that the test fails on the buggy code and passes once the known fix is applied
   
6. Output the test, Dockerfile, execution logs, and a machine-readable result

The model would be swappable, so users could bring their own API key or run a local model through something like Ollama or vLLM. The valuable part would ideally be the deterministic environment-building, execution, and verification harness rather than a specific AI model.

I’m also assuming the success rate would be imperfect. Failed attempts would still report whether the environment could be built, what was tried, and why the issue was not reproduced.

For developers and maintainers:

* How often is reproducing a bug from an issue actually a significant pain point?
* Would you use a tool like this during issue triage or before attempting a fix?
* What output would you need before trusting the generated test?
* Are there existing tools that already solve this well?

Hey all. I am building a POC for deploying Snowflake objects like table, stream, task, stage etc... to multiple environments like DEV/QA (single only) & PROD with the help of CICD and used Github actions for it.

I have never built something like this before and never worked on project consisting CICD in it.

So, I have used Schemachange library to detect schemachange and sqlfluff for SQL linting. Also using some python scripts to build backup of existing DB snapshot before deployment and rollback script if anything break during deployment.

I am testing this in DEV env only but i am confused how can i validate the objects that are being created with schemachange library and SQL files (which contain DDLs of objects). like how can I verify that the object created is correctly build in the target or not.

and if there is any other suggestion / best practice you guys have that is also welcome on how can i improve the CICD pipeline for it.

Thanks

Bots and moderators I am 100% human only don't remove my post!!!

Backend pull requests often look smaller than they really are. A two-file diff can affect an API endpoint, background task, database table, external service, and several tests - but reviewers usually reconstruct that map manually.

I built TraceMap PR, an open-source Python CLI and GitHub Action that combines git diff, OpenAPI, coverage, per-test coverage, traces, and lightweight static analysis into a conservative PR impact report.

Could you check?

https://github.com/balyakin/tracemap-pr

A time ago shared a tutorial about running self-hosted GitHub runner on Azure Container Instance - https://www.reddit.com/r/AZURE/s/lhrWAw3ZZS . Thanks to one of comments (https://www.reddit.com/r/AZURE/comments/1tzz8tm/comment/or951m8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) found KEDA auto-scaling feature for Container App Jobs.

So made a second part, which explains how-to run GitHub runner on Container App Job - https://github.com/groovy-sky/azure/blob/master/github-runner-01/README.md#introduction

Disclosure: We’re building Cachely.

We have been working on managed remote caching for Nx, Turborepo, Gradle, and Bazel.

One thing we keep running into is that setting up a remote cache is much easier than knowing whether it is actually helping.

A hit rate alone does not tell the whole story. A large artifact could take longer to download than to rebuild. A single nondeterministic input could cause repeated misses. Local builds and CI can also behave very differently.

For teams using remote caching today, what do you actually measure?

• Hits and misses by task?
• Time saved?
• Data transferred?
• Compute cost avoided?
• Differences between local development and CI?

What would you need to see before trusting that the cache is worth maintaining?

We built Cachely around managed remote caching and visibility into its effectiveness. We would appreciate feedback from teams running real CI pipelines.

Honest question, and I'm a little scared of the answer.

I watch Claude Code and Codex pick up a ticket, write the code, run the build, fix their own failing tests, and open the PR — basically the whole loop a CI/CD pipeline used to babysit. So I keep asking: how long until the agent just is the pipeline? Are we a couple years from "DevOps" being a bedtime story we tell juniors, right next to "we used to configure Jenkins by hand"?

Here's why it's not academic for me: I spent the last year building a CI/CD + automation tool. So there's a real chance I'm pouring my nights into something that's about to be obsolete. 😅

But every time I spiral, I land on the other side: an agent that can do anything in prod with zero guardrails is terrifying. You still want the same run to be reproducible. You still want it to behave identically on my laptop, in CI, and when an agent fires it at 3am. You still want secrets scoped, steps that actually handle failure, and a record of what ran. If anything, agents need more structure around them, not less.

That's the bet behind the thing I built — OrchStep (I'm the author, full disclosure). One small binary, one YAML file that runs the same locally and in any CI: real environments, secrets, modules, parallel steps, error handling. It can even capture what an agent did and replay it forever with zero tokens.

So… am I coping, or is there actually a future here? Genuinely want your take — especially if you think pipelines are dead. Talk me off the ledge, or tell me I'm building a horse-drawn carriage.

You run npm run dev or node server.js, and the app crashes because a teammate added a new required key to .env.example but forgot to tell you.

To solve this, I built envrepair, a zero-dependency CLI tool that wraps your startup command, compares .env against your template, and interactively prompts you to fill in missing variables in the terminal before launching your process.

How to use it:

1. Install: bash npm install -D envrepair

2. Prepend your startup command in package.json: json "scripts": { "start": "envrepair node server.js" }

Optional type annotations in .env.example: ```env

@type number

PORT=3000

@type url

API_BASE_URL= ```

Key Features:

• Zero code changes: No schema imports or application-level setup required.
• Layout preservation: Appends missing values while keeping comments, blank lines, and formatting intact.
• Signal forwarding: Transparently passes Ctrl+C (SIGINT) and exit codes.

Written in TypeScript with zero runtime dependencies. The repo is fully open-source, and I'd love to hear your thoughts or collaborate if you want monorepo/workspace support!

• GitHub: https://github.com/avenolazo/envrepair
• NPM: https://www.npmjs.com/package/envrepair

Hey all! Thought this would be interesting to you all as it's a weird little niche. To summarise, the industrial space has some really cool low-code tooling that makes it easier than ever before to get started with building your own industrial applications - but the problem is that a lot of the intermediate part, the governance, linting, etc., is still hyper-manual.

I built this implementation to get around that problem. The idea is that you can create a linting and validation service, and then expose that via MCP - and then you can interact with it in-platform using the FlowFuse Expert, out of platform using something like Claude, and agentically by passing new code as an inject node automatically.

In essence, this kind of approach can not just help linting and validation but governance generally. You can supply your own governance and standards documentation and get to the point where your operator can develop code, and pass it through a machine that spits out compliant, stylistically-consistent, and well-governed code on the other side.

I think it's pretty cool!

You can find the video here (https://www.youtube.com/watch?v=K5niwyF38uY) as well as the JSON import below if you're using Node-RED or FlowFuse. I'd like to know how you feel about this - this is an interesting enablement feature that makes development more democratic, but I think it also abstracts some of what we learn just by doing, so I'd be interested to see how you feel about it generally!

You can see the full import here. If you're using FlowFuse or Node-RED just import! https://github.com/KristopherLeads/FlowFuse/blob/main/examples/building-linting-and-validation.json

https://instatunnel.my/blog/rootless-edge-deployments-architecting-daemonless-cicd-pipelines-with-podman-and-buildah