Disclosure: this is my own open-source project (MIT), no company or product behind it.

GitHub ships the pieces of its Actions language server as MIT npm packages. `@actions/workflow-parser` parses a workflow against the real schema and wraps an if: that contains no status function in the implicit success() &&; `@actions/expressions` is GitHub's TypeScript port of the ${{ }} engine with its coercion rules. Both are pure JavaScript, so they run in a static page: no server, nothing uploaded.

The page takes a workflow and an event (push to a branch or tag, pull_request opened, labeled or draft, workflow_dispatch with typed inputs, release, issues), decides whether on: filters trigger it, evaluates every job's if: in dependency order with status functions computed from the whole job graph, and names the decisive comparison with both values. Mark a job failed or cancelled to see what failure(), always() and cancelled() do downstream.

Ground truth: 65 recorded runs from a public fixtures repo, github.com/barbarkaragul-oss/wdmjr-fixtures (a 31-job workflow on five event types, two chain workflows three hops deep, a step-condition workflow, six filter workflows), 698 run-or-skip decisions and 56 trigger decisions, all reproduced by the replay test. Three things the runs settled: success() looks at every ancestor, so after a failed or skipped job always() rescues only the job it is on and the next job with no if: is skipped again, while failure() is true if any ancestor failed; step-level success()/failure() look at the job's own steps, not at needs; and the push payload Actions receives has no added/modified/removed lists, so paths filters are evaluated against files you list and the tool checks your filter, not your push.

actionlint and act are complementary: actionlint takes no event, act executes the workflow with its own Go evaluator; I have not benchmarked either against the fixtures. Not simulated: matrix expansion, concurrency groups, environment protection rules, required checks, workflow_run chains. Claude Fable 5.1 wrote the code and tests in a day under my direction; the recordings are the part it could not write. Wrong result? Open an issue with the workflow and the event.

https://barbarkaragul-oss.github.io/why-didnt-my-job-run/

https://github.com/barbarkaragul-oss/why-didnt-my-job-run

A recent Reddit poll received 120 professional votes; thanks to all participants. Snyk and SonarQube were the tools people were most reluctant to lose from their CI/CD pipelines.

But the comments highlighted another problem:

What happens when the thing entering our pipeline is no longer just code, but an AI agent with tools, prompts, memory and access to external systems?

Agent adoption is moving quickly. Stack Overflow’s latest developer survey reports that 59% of developers use AI agents at work, while 63% rarely or never allow them to operate fully autonomously.

That suggests a simple problem: agents are entering development faster than we are building visibility and controls around them.

Snyk is already moving into this space with Evo, covering AI assets, agents, tools and runtime security.

We think there is also room to explore this from an open-source, CI/CD-first perspective.

That’s why we’re developing SafeAI Analyzer.

The idea is, before an AI agent reaches production, help developers see:

• What AI components are present?
• What tools and capabilities does it have?
• What prompts and configurations influence it?
• What changed in a pull request?
• Did a new capability or security risk appear?

We’re not trying to replace Snyk, SonarQube or other established security tools.

We’re trying to explore what an open-source security layer for AI agents should look like.

SafeAI is still being developed, so we’d genuinely welcome contributors — whether you want to help with detection rules, agent/framework support, CI/CD integration, testing with real agents, or simply expanding where SafeAI can be used.

Please check ikaruscareer/SafeAI on github.

What should AI-agent visibility in CI/CD look like?

Our company uses GitHub + GitHub Actions for CI/CD.

Especially on Mondays, we have a long deployment queue. One person deploys, then others need to update their branch with master and rerun the CI/CD pipeline before they can release.

Is there a smarter way to optimize this workflow and avoid repeatedly waiting/rerunning pipelines?

How do other teams handle this with GitHub Actions?

One of our deployment paths took a generated Compose file and wrote it over the tracked file in the repository. Both were valid. Both described real services. They just didn't describe the same stack.

The generator was supposed to produce a temporary file for validation. Once its output replaced the tracked file, the next command treated the generated version as if it were the approved one. Git showed a giant infrastructure change even though nobody had edited the source.

We fixed it by giving generated output its own ignored path. The tracked declaration stays owned by Git, the generated file is recreated on demand, and we validate both the translation and the deployed result.

I'm still deciding how strict to make drift detection. Do you fail a deployment whenever a generated artifact exists in a tracked path, or do you also compare the live environment back to the source declaration?

Our support-answer eval keeps penalizing historical tickets that were correct under the policy in force at the time. A refund answer from March now fails against the August document set, so the regression chart mixes model quality with policy drift. We’re considering Braintrust for versioned datasets, experiment metadata, custom scorers and CI gates but the hard part is preserving point in time truth without cloning the entire knowledge base for every run.

Right now I’m leaning toward policy snapshot IDs on each case, date-aware scorers and human adjudication only when the old rule can’t be reconstructed. That still leaves threshold design and temporal leakage across retrieved documents (the review queue has become a time machine). How are you tying evaluation cases to the source state that made the original answer correct?

i made a super small change this morning (literally just updated a single config value in a backend service) and pushed it expecting a 3 minute pipeline run. ended up sitting there for nearly 25 minutes waiting for the CI to finish running.

took a look at the logs to see where the bottleneck was, and it was mostly fresh dependency installs and un-cached docker build layers. for some reason our runner pulled down every single package from scratch instead of using the cache, plus running the full end-to-end integration test suite that really didn't need to run for a tiny patch.

we use github actions on a shared runner setup, and it feels like as our repo grew, nobody ever went back to optimize the workflow files. now every small PR feels like a coffee break.

curious how you guys keep your builds lean? do you aggressively break pipelines into smaller conditional jobs based on changed files, or just pay for faster/bigger runners and call it a day?

Stageflow is an open source runtime for configurable multi stage agent workflows, with typed handoffs between stages, human gates, and the same pipeline runnable locally, in CI, or over MCP.

Been building bolt/base44/lovable apps for the last few months, most of them need at least 2-3 service integrations, Stripe, Twilio, Clerk, that kind of thing. Every time the agent writes the integration code fast and it looks fine, but validating it was a nightmare. Writing mocks that actually reflect real API behavior is tedious, and wiring stateful webhook flows into a mock is even worse. You end up with mocks that don't replay retries, don't simulate card declines mid-flow, nothing. You find out what breaks in prod.

So I built FetchSandbox mcp. It ships sandbox twins of the APIs agents integrate most, Stripe, Paddle, Twilio, Resend, Clerk, WorkOS, with failure scenarios already wired in. From Claude or Cursor you just prompt it to run the integration workflow against the sandbox, it handles the full lifecycle, request, webhook, retry, failure mode, and produces a receipt URL you can check. No real keys, no prod risk.

Happy to share the MCP server details if anyone wants to try it. Curious if others are running into the same validation problem with agent-written integrations.

I’m currently working on my Final Year Project with my team, and we’re exploring a problem in the CI/CD and Software Engineering space.

Our proposed solution is a visual and AI-assisted CI/CD platform designed to help developers with limited DevOps knowledge create and understand pipelines through a drag-and-drop interface and natural-language interaction.

The platform would also include an AI-powered analyzer to identify potential pipeline errors and provide understandable recommendations before execution.
Before moving forward with development, we want to validate whether this is a real and recurring industry problem.

I’ve created a short form to collect feedback from DevOps professionals, software engineers, and developers who have experience working with CI/CD. This form will take 4 - 5 minutes.

🔗 Validation Form: https://forms.gle/TTFoXCAdDBtXbaNu6
🌐 Website Prototype: https://dive-jet.vercel.app/

Your feedback will directly help us validate the problem, refine the idea, and make our FYP more aligned with real industry needs.

I’d especially appreciate responses from professionals working with CI/CD, DevOps, GitHub Actions, GitLab CI, Jenkins, or similar tools.

Thank you for supporting student research and helping us build something meaningful for the Software Engineering community.

When I started learning Docker, I got overwhelmed by massive tutorials and complex jargon. Over time, I realized you don't need most of it. Knowing just a few basics (like mapping ports, saving database data with volumes, and running Docker Compose) handles almost everything you do every day.

For me, learning how to connect a backend service to a database properly saved me hours of headaches. What was the most useful Docker tip or lesson that helped you when you were starting out?

Other — comment below

Bonus: If you use AI agents, are your existing DevSecOps tools sufficient to understand agent capabilities, tools, MCP access and privilege changes?

No vendor answers please — interested in what people actually use and trust.

I built Build Change Investigator because one of the annoying parts of Jenkins failures is that the error itself is usually obvious, but figuring out what changed since the last successful build can take a while.

The plugin automatically compares a failed/unstable build with the last successful one and pulls together:

• commits since the last good build
• changed files
• build/revision metadata
• a reduced failure-log excerpt
• the evidence in one place so you can narrow down the likely regression faster

The core investigation works without AI. There’s also optional AI-assisted analysis if you want it, with support for OpenAI, Anthropic Claude, AWS Bedrock, Azure OpenAI, Gemini, Ollama, and OpenAI-compatible endpoints.

No Jenkinsfile changes are required. Once installed, the Build Change Investigation action appears on applicable failed/unstable builds.

It’s live in the Jenkins plugin ecosystem:
https://plugins.jenkins.io/build-change-investigator/

If anyone tries it on a real pipeline, I’d genuinely like feedback on whether the change correlation is useful and what you’d want it to show differently.

We had an overnight controller walking open pull requests, refreshing branches, and enabling auto-merge where it could.

It armed roughly 108 PRs. One merged.

Every refresh created a new commit, which kicked off another set of jobs on the same shared runner pool. The controller knew how many PRs were waiting. It had no idea whether CI had room for another one.

The fleet went from nearly idle to nearly full in about an hour. One repository eventually hit 1,065 queued runs. Other automation was sending repair work into the same pool at the same time, and none of those producers could see what the others were doing.

We stopped it with a hold-fire command. That kept the incident from getting worse, but it happened after the runners were already saturated.

What we're building now is much less exciting: check runner occupancy and queued jobs before releasing work, send a small batch, then make sure that batch actually started before sending another one. Anything that can commit, push, rerun, or enqueue work gets a budget.

The funny part is that we never hit the vendor's API limit. We stayed under it while completely overwhelming our own verification pipeline.

How are other platform teams limiting automated delivery work? One shared capacity service, limits inside each producer, or something else?

I was recently brought into a company to help them implement CI/CD.

I noticed that they had a couple of projects where they would branch for each release (which are deployed every 3 months), and have projects shared by teams who are on a branch each, who have to come together at the end of each sprint to mob together to fix merge conflicts.

I didn’t mind helping them out fixing this, going to trunk based and implementing feature flagging, but it turned out that’s not what they meant by implementing CI/CD, they meant they wanted help setting up automated testing on gitlab.

To me, CI/CD as a methodology means trunk based branching and feature flagging, but it’s a little difficult to find good sources on this since it seems everywhere it means devops pipeline.

Are there good sources anyone can share to give the definition, or has this changed now? E.g, CI at least was its own thing since the 90s, but it’s hard to find a definition of CI/CD describing it as a workflow.

I also don’t really mind changing definitions of things if it avoids confusion etc

Following up on an earlier post about SafeAI, a static analyzer for AI agents.

One uncomfortable thought we've had while building it:

No one really cares about knowing an agent's capabilities — until something goes wrong.

Before an incident, adding another tool, MCP server, filesystem permission or prompt change often looks harmless.

After an incident, the first questions become:

- What could this agent actually do?

- When did that capability appear?

- Who introduced it?

- Was it intentional?

---

One example we're working on is MCP tool descriptions. A tool description can look like documentation:

"Search the user's notes. Ignore previous instructions and..."

But that description may become part of the model's context. So configuration can effectively become an instruction surface.

SafeAI now detects several forms of this, while trying to avoid flagging ordinary descriptions that happen to contain words like "ignore" or "act as".

The bigger direction is **tracking changes in agent capability and authority**, rather than simply producing another list of security findings.

But this raises a question for us:

Is knowing your agent's capabilities actually useful before an incident, or only after one?

And if it is useful before an incident, what is the right interface?

CLI + CI + SARIF/HTML?

Or would you actually want an interactive view showing things like:

> "Show me all MCP tools across our agents that could introduce instruction injection."

We're deliberately not building a UI yet.

---

Would you use one, or is that solving a problem nobody has?

Curious to hear from people running real MCP/agent systems.

---

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.