[Idea] Add workflow_call to more workflows

[Johannes Wikman (jwikman)]

Idea Description

I'd like to create an orchestrator workflow for our releases.
Draft thinking:

1. Identify which build to release
2. Construct input parameters for the other workflows that will be invoked
3. Invoke CreateRelease.yaml (creates pre-release)
4. Invoke a workflow that updates our Docs repo, in a work branch, creates a PR
5. Invoke PublishToAppSource.yaml (GoLive: false)
6. Manual gate approval - "Live on AppSource"
7. Update the pre-release created above and remove the "pre-release" flag
8. Run IncrementVersionNumber.yaml to increase minor version
9. Merge the Docs PR

But to be able to invoke other AL-Go workflows, they would need to have workflow_call added.

My other options:

1. Clone parts of above workflows (reusing actions), but that comes with quite a lot of maintenance debt.
2. use gh workflow run and poll for results
3. Hybrid of above

What's the downsides of adding workflow_call to the workflows?
One I can think about is when we need to add new required parameters, that could break callers. But that would break all my other options as well...

workflow_call got added to UpdateGitHubGoSystemFiles in #2031 (with an additional fix in #2154), but I would like to add this to more workflows.

I'm open to do the work myself, and in that case, I'd focus the three ones above.

Contribution (Optional)

• I would be open to contributing to this idea (implementation, documentation, testing, etc.)

[Daniele Lixi (y0m0)]

I also tried to achieve something similar and came to the same conclusion, we should have workflow_call on most of the workflows.

[Daniele Lixi (y0m0)]

I am of a mind to start working on this. But before it, Maria Zhelezova (@mazhelez) do you have any input or comment on this?

[Maria Zhelezova (mazhelez)]

Hey Johannes Wikman (@jwikman) and Daniele Lixi (@y0m0)
Are you willing to work together on the suggested idea?

What worries me a bit is the customization part. How do you plan to cover different release processes? What if someone doesn't want a docs update?

[Johannes Wikman (jwikman)]

Hey Maria Zhelezova (@mazhelez) 👋

Good question — and it's actually one I already had to answer, since I ended up building this exact orchestrator (as described in my original post) for our own AppSource release pipeline. So this isn't hypothetical for me, here's how it plays out in practice.

I didn't try to make the called workflows aware of being optional — that would mean touching workflow_call contracts every time someone wants a different flavor of release process. Instead, all the customization lives in the orchestrator itself:

1. Every optional step is a workflow_dispatch boolean input on the orchestrator (e.g. skip docs update, skip AppSource publishing, skip version increment), defaulting to "run it" so opting out is explicit rather than opting in.
2. A single "compute flags" step early in the run turns those raw inputs (plus a bit of repo-level config, e.g. "is a docs step even configured for this repo?") into a small set of clean booleans. Every downstream job's if: only ever looks at those computed flags — never at the raw inputs directly. Keeps the branching logic in one place instead of duplicated across jobs.
3. Downstream jobs use if: always() && needs.X.result == 'success' && needs.Flags.outputs.runY == 'true', so a skipped optional job doesn't block whatever depends on it — "skipped" isn't "failed" for the purposes of the jobs further down the chain.
4. A manual approval gate (environment: protection rule) sits between "publish to AppSource" and "make it live", regardless of which optional steps ran before it.
5. workflowDefaultInputs lets each project set its own defaults for those same inputs, so per-project process differences don't even need a manual choice at dispatch time — the org-wide orchestrator stays generic, and each project's settings file decides what "default" means for it.

This is literally the run graph GitHub shows for it today:

flowchart LR
    Init["Init"]
    CreateRelease["CreateRelease"]
    UpdateDocs["UpdateDocs\n(optional)"]
    PublishToAppSource["PublishToAppSource\n(optional)"]
    ApprovalGate{{"ApprovalGate"}}
    PromoteRelease["PromoteRelease"]
    IncrementVersion["IncrementVersion\n(optional)"]
    MergeDocs["MergeDocs\n(optional)"]

    Init --> CreateRelease
    Init --> UpdateDocs
    CreateRelease --> PublishToAppSource
    UpdateDocs --> PublishToAppSource
    PublishToAppSource --> ApprovalGate
    ApprovalGate --> PromoteRelease
    ApprovalGate --> IncrementVersion
    PromoteRelease --> MergeDocs
    IncrementVersion --> MergeDocs

Loading

So my take on your worry: the individual AL-Go workflows (CreateRelease, PublishToAppSource, etc.) don't need to know or care whether they're "optional" for a given org. That decision lives entirely in the orchestrator, driven by its own inputs + one flags step (and workflowDefaultInputs for per-project defaults). Adding workflow_call to those workflows wouldn't force any particular release process on anyone — it would just let orchestrators like mine invoke them directly (with proper run tracking/outputs) instead of going through gh workflow run + polling for status, which is what I'm stuck doing today.

Happy to go deeper on any part of this — genuinely think it validates that workflow_call support wouldn't need to solve the "different release processes" problem itself, since that's naturally the orchestrator's job, not the called workflow's.

Daniele Lixi (@y0m0) since you're up for starting on this — happy to team up. I'm a bit busy to drive implementation myself right now, but I'm glad to discuss the design, review PRs, and help test.

[Johannes Wikman (jwikman)]

And our workflow inputs:

[Daniele Lixi (y0m0)]

Maria Zhelezova (@mazhelez) as far as I am concerned, and also understood from Johannes Wikman (@jwikman), we are not trying to add a reusable and customizable orchestrator directly into AL-Go.
By adding the workflow_call to the different existing workflows we are simply enabling everyone to build their own orchestrator as they see fit. Meaning we would be able, and be responsible, for passing in our own parameters and rules based on individual needs.
Like Johannes Wikman (@jwikman), I also endend builind our own orchestrator around this limitation by using the gh rest api to dispatch the workflows, same concept as using gh workflow run, and having to recursively check for completion status by inferring the correct run ID.

Johannes Wikman (@jwikman) sound good to me. I can start on a draft PR since I have some available tokens to burn :)

[Johannes Wikman (jwikman)]

Nice, glad we're aligned, Daniele Lixi (@y0m0) — workflow_call just needs to expose the door, not decide what's behind it.

The "poll + infer the run ID" pain is very familiar. That's exactly what native workflow_call support removes — the caller gets run status/outputs directly, no correlation guesswork.

Go ahead and start the draft PR. Tag me when it's up, I'll review and help test.