implement manual approval for Docker CE release workflow

[ilopezluna]

Problem

The release workflow was blocking while waiting for the docker/release-repo workflow to complete. The external workflow requires manual approval at the deploy-to-live gate, which could take hours to be approved. During this wait time, the entire release-cli-docker-ce job would be stuck, consuming GitHub Actions minutes and blocking other dependent jobs.

Solution

Split the release-cli-docker-ce job into two separate jobs with a manual approval gate:

1. release-cli-docker-ce-trigger - Triggers the packaging and release-repo workflows, then completes immediately
2. release-cli-docker-ce-wait - Requires manual approval via GitHub environment protection before waiting for the release-repo workflow to complete

I also removed the timeouts, I think they are unnecessary, I will get back any of them if turns out they are needed

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[sourcery-ai]

Hey - I've left some high level feedback:

• The new release-cli-docker-ce-wait job no longer has the 360-minute timeout that existed on the original release-cli-docker-ce job; consider adding an explicit timeout to the wait job so that it can’t block indefinitely if the release-repo workflow stalls.
• You removed timeout-minutes from release-cli-desktop, bump-pinata, and verify-docker-ce; if that wasn’t intentional, it may be worth restoring timeouts to avoid long-running or stuck jobs in these parts of the workflow.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new `release-cli-docker-ce-wait` job no longer has the 360-minute timeout that existed on the original `release-cli-docker-ce` job; consider adding an explicit timeout to the wait job so that it can’t block indefinitely if the release-repo workflow stalls.
- You removed `timeout-minutes` from `release-cli-desktop`, `bump-pinata`, and `verify-docker-ce`; if that wasn’t intentional, it may be worth restoring timeouts to avoid long-running or stuck jobs in these parts of the workflow.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[doringeman]

gh workflow run has just been updated to return the workflow ID!

cli/cli#4001 (comment)
❤️ https://github.blog/changelog/2026-02-19-workflow-dispatch-api-now-returns-run-ids/

[babakks]

Hi from gh! 👋 Sorry to interrupt. I just noticed this PR via links and thought sharing these:

• When run gh workflow run non-interactively (as in here, in Actions), the dispatched run URL is the only thing that is printed on stdout. So you can safely drop stderr redirection (2>&1) to avoid any accidental matches against error messages if they happen to include URLs of the same pattern.

• Usually it takes a few weeks for new gh versions to be fully propagated across Actions runner images. For example, you can watch for changes on ubuntu-latest image here.

Cheers