Combining cron-staging.yml and main.yml

[AbdullahKazi500]

Summary

• This PR consolidates the cron-staging.yml and main.yml GitHub Actions workflows into a single unified workflow (ci.yml).

Details

• Merges duplicated logic between cron and main workflows.

• Uses conditional if: checks to distinguish between schedule runs and regular PR/merge queue runs.

• Removes unnecessary push trigger (superseded by merge_group).

• Keeps merge_group as the required status check for branch protection.

Runs:

• Normal py tests on PRs and merge queue.

• qiskit-main tests and docs-qiskit-main build on scheduled cron runs.

• Skips linting on cron runs to avoid redundant checks.

• Unifies documentation build and artifact upload steps.

Motivation

• Simplifies CI by reducing duplication.

• Aligns with new merge queue workflow.

• Removes legacy testing on qiskit-ibmq-provider (now deprecated).

PR checklist (delete when all criteria are met)

• I have referenced any relevant issue addressed by this change.
• I have read the contributing guide CONTRIBUTING.md.
• I have added the tests to cover my changes.
• I have updated the documentation accordingly.
• I have added a release note file using reno if this change needs to be documented in the release notes.
  Fixes Streamline CI workflow #1073

[AbdullahKazi500]

Hi @wshanks this was one of the issue which I was assigned to a few years back and was not able to fix ,I am now open for any feedback on the PR Related to the issue

[wshanks]

Thanks, @AbdullahKazi500! I read through the new workflow and it looks good. I just had a couple small comments.

[wshanks]

There is something strange about the CI here. Maybe it is just unique to this PR. I have to approve the tests to start running but that seems to have started a second run while some first run it stuck waiting approval to run. The second run's jobs get canceled because the first run's jobs have higher priority according to the message in the UI.

[AbdullahKazi500]

There is something strange about the CI here. Maybe it is just unique to this PR. I have to approve the tests to start running but that seems to have started a second run while some first run it stuck waiting approval to run. The second run's jobs get canceled because the first run's jobs have higher priority according to the message in the UI.

Hi Yeah, what you’re seeing is expected GitHub Actions behaviour, but it does look confusing at first glance. I believe that it is happening due to the following reasons

• Concurrency group cancellation

In my workflow if you see I have defined:

concurrency:
  group: ${{ github.repository }}-${{ github.ref }}-${{ github.head_ref }}
  cancel-in-progress: true

This means only one workflow run per branch/PR is allowed at a time.

When you approved the run, GitHub scheduled a new run (because the approval counts as a “re-run”), while the earlier “waiting for approval” run is still holding the concurrency lock.

As a result, the new run gets cancelled in favour of the first one, even though the first run is stuck until you approve it.

Why it looks like a loop

Essentially, GitHub keeps trying to create a new run when you approve, but concurrency gives priority to the oldest pending run.

That leaves you with one “zombie” workflow blocking the new one.

there are some few Options to fix / avoid this:

Approve immediately instead of triggering a new run; the first pending run should proceed.

Cancel the older “waiting for approval” run before approving a new one. That clears the concurrency lock.

Loosen the concurrency group definition if this behaviour becomes a recurring problem. For example, you could remove ${{ github.head_ref }} so that fork PRs don’t get stuck in this loop.

Alternatively, disable cancel-in-progress but that means multiple runs per PR could execute simultaneously, which might not be what you want.

[wshanks]

Okay, I got it straightened out to run this time at least, but it failed because your conditional syntax didn't work on powershell.

By the way, is there any reason not to remove the main.yml and cron-staging.yml files as part of this PR? Removing main.yml now would be nice so that we don't have to run its tests before we can run ci.yml's tests.