Pins in actions-lock.json can drift out of sync with workflow

[dsyme]

If I have two workflows

.github/workflows/a.md
.github/workflows/b.md

and run

gh aw compile .github/workflows/a.md

then the action pins for "b.md" can currently go out of sync.

Suggestion is to either

1. key the pins in actions-lock.json by workflow or
2. store the pins in the .lock.yml

One idea is the actions-lock.json can be leveraged by dependabot down the road. But to do that the information must be reliable and kept in sync.

There's a slight difference of POV on this file, because are individual workflows "isolated" from each other or part of an "overall project", e.g. cooperating with each other.

• If workflows are isolated from each pther that would imply putting the pins in the .lock.yml, or at least keying the pins
• If workflows form a unfiied project then that would imply putting them in actions-lock.json and not allowing selective recompilation

My vote is that automations are isolated from each other (and so may be compiled with different versions of gh-aw).

[pelikhan]

It's not possible to maintain a coherent set of shared agentic workflows and support multiple versions of the compiler. It's going to be nightmarish where complex graph of AWs will each potentially have different versions and quirk.

This is not how most PL systems work. You may have multiple Python script , but they all share the same runtime / pip version. You may have multiple Python script.net console apps, they all share the same C# compiler.

This is a NO on trying to service a different compiler/runtime version per agent workflow.

[dsyme]

It's not possible to maintain a coherent set of shared agentic workflows and support multiple versions of the compiler.

It's an OK position, but has consequences. It means we should

1. remove independent compilation of workflows (all must be recompiled, gh aw compile can't take an argument)
2. recompile all workflows when one is added

But I think users will find it strange that adding a workflow means updating other workflows. I don't know how I'd explain that to users.

This is not how most PL systems work. You may have multiple Python script , but they all share the same runtime / pip version. You may have multiple Python script.net console apps, they all share the same C# compiler.

This isn't strictly true - there are plenty of SxS convert-and-install systems. Each executable generated by Go is SxS (and internalizes its runtime). Each .NET tool is SxS - and there are options to internalize the runtime into the app. Different .NET projects can use different versions of the C# language through options.

In our situation, SxS feels pretty natural

• users expect add/remove of workflows to be isolated from each other
• interop between workflows uses standard compilation-neutral mechanisms like workflow_call and workflow_dispatch
• no runtime is installed - the runtime scripts are referenced by SHA (effectively internalized as a remote ref).
• features like "gh aw logs" have to work with outputs from multiple compiler versions

I don't really mind, I just want a coherent position and want actions-lock.json to either be reliable, or removed. No point having a sometimes-inaccurate lock file around.

[pelikhan]

Agreed: we recompile all every time. This is an opinionated system .

Supporting every version that ever existed greatly expands the servicing burden at every level.

• shared agentic workflows need to be backward compatible
• need to download as many versions of the extensions as needed
• there is one 1 extension version per machine so we need to rearchitect the cli to be shim that delegates to multiple versions

I really don't why we would go down this road and make it ourselves into a servicing nightmare. Nobody asked for this.

[dsyme]

Nobody asked for this.

I mean, I'm asking for it, in the sense that I don't want an add of one workflow to recompile and change other workflows. I just don't think that's a good user experience, and I do think users will expect SxS isolation.

There's no servicing nightmare here AFAICS. There's no installed runtime, there's no interaction between workflows, there's not even any pinning of compiler versions used for each workflow.

I think you're talking about a different feature, which is compiler version pinning. Which I agree should be consistent across all workflows if present at all - I agree we wouldn't want a different pinned compiler version for each workflow. And if pinned compiler versions are present and active in a repository then yes, I would expect adding a workflow using a new toolchain to update that pinned compiler version and adjust all workflows.

But right now we have no compiler version pinning.