Investigation: Cancelled workflow status issue cannot be fixed at workflow level

[Copilot]

What do these changes do

This PR investigated approaches to prevent cancelled GitHub Actions jobs from appearing as "failed" with red X icons in branch protection and status checks.

What was wrong

PR #1250 added cancel-in-progress: true to deduplicate concurrent workflow runs. When jobs are cancelled, they appear as "failed" with red X icons in some contexts (branch protection, status checks), misleading users about actual failures.

How this fixes it

Investigation Result: After implementation and code review, it was determined that this issue cannot be solved at the workflow level.

The attempted solution was to add a final step to each workflow job:

- name: Ensure success on cancellation
  if: always() && cancelled()
  run: |
    echo "Job was cancelled - marking as success to avoid misleading red X"
    exit 0

However, this approach does not work because when a job is cancelled by GitHub Actions:

1. GitHub sends SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always() && cancelled()

All changes have been reverted. The issue requires one of these alternative approaches:

1. Accept cancelled jobs as a legitimate status in branch protection
2. Remove cancel-in-progress: true from concurrency groups (restoring duplicate runs)
3. Configure branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

Your checklist for this pull request

• Passed code styles and structures
• Passed code linting checks and unit test

Original prompt

Same group conditions and job cancellation added by #1250 help reduce the unnecessary runs (double run).

But the side effect is, once job got cancelled, the check status will be considered "failed" with red 'x' icon - instead of green check icon. This can be misleading.

How to deal with this?

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR attempts to address the issue where cancelled workflow jobs (from PR #1250's concurrency groups) appear as "failed" with red X icons in branch protection and status checks. The proposed solution adds a final step to each workflow job that runs on cancellation and exits successfully.

Changes:

• Added cancellation handler steps to 4 workflow files (unittest.yml, lint.yml, codeql-analysis.yml, pypi-publish.yml)
• Each handler uses if: always() && cancelled() condition with exit 0 to mark as success
• Total of 7 jobs modified across the workflows

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.

File	Description
.github/workflows/unittest.yml	Added cancellation handler to unittest job
.github/workflows/lint.yml	Added cancellation handler to ruff job
.github/workflows/codeql-analysis.yml	Added cancellation handler to analyze job
.github/workflows/pypi-publish.yml	Added cancellation handlers to echo_github_env, check_build_trigger, build, and publish_pypi jobs

[Copilot]

This approach does not achieve the intended goal. When a workflow job is cancelled by GitHub Actions (via concurrency groups), the entire job is cancelled immediately and no subsequent steps run - including steps with if: always() && cancelled(). The job conclusion remains "cancelled" regardless of this step.

According to GitHub Actions documentation, when a job is cancelled:

1. GitHub sends a SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always()

The fundamental issue is that branch protection rules and status checks treat "cancelled" jobs as failed (red X). However, this cannot be worked around at the workflow level - it requires either:

1. Accepting cancelled jobs as a legitimate status
2. Removing cancel-in-progress: true from concurrency groups
3. Configuring branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

This step will never execute when the job is actually cancelled, making it ineffective.

[Copilot]

This approach does not achieve the intended goal. When a workflow job is cancelled by GitHub Actions (via concurrency groups), the entire job is cancelled immediately and no subsequent steps run - including steps with if: always() && cancelled(). The job conclusion remains "cancelled" regardless of this step.

According to GitHub Actions documentation, when a job is cancelled:

1. GitHub sends a SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always()

The fundamental issue is that branch protection rules and status checks treat "cancelled" jobs as failed (red X). However, this cannot be worked around at the workflow level - it requires either:

1. Accepting cancelled jobs as a legitimate status
2. Removing cancel-in-progress: true from concurrency groups
3. Configuring branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

This step will never execute when the job is actually cancelled, making it ineffective.

[Copilot]

This approach does not achieve the intended goal. When a workflow job is cancelled by GitHub Actions (via concurrency groups), the entire job is cancelled immediately and no subsequent steps run - including steps with if: always() && cancelled(). The job conclusion remains "cancelled" regardless of this step.

According to GitHub Actions documentation, when a job is cancelled:

1. GitHub sends a SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always()

The fundamental issue is that branch protection rules and status checks treat "cancelled" jobs as failed (red X). However, this cannot be worked around at the workflow level - it requires either:

1. Accepting cancelled jobs as a legitimate status
2. Removing cancel-in-progress: true from concurrency groups
3. Configuring branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

This step will never execute when the job is actually cancelled, making it ineffective.

Suggested change

	# Ensure cancelled jobs don't show as failed (red X) in PR checks
	# When job is cancelled by concurrency, this step ensures success status
	- name: Ensure success on cancellation
	if: always() && cancelled()
	run: |
	echo "Job was cancelled - marking as success to avoid misleading red X"
	exit 0

[Copilot]

You're correct - the approach is ineffective. Reverted in 857e1f2.

[Copilot]

This approach does not achieve the intended goal. When a workflow job is cancelled by GitHub Actions (via concurrency groups), the entire job is cancelled immediately and no subsequent steps run - including steps with if: always() && cancelled(). The job conclusion remains "cancelled" regardless of this step.

According to GitHub Actions documentation, when a job is cancelled:

1. GitHub sends a SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always()

The fundamental issue is that branch protection rules and status checks treat "cancelled" jobs as failed (red X). However, this cannot be worked around at the workflow level - it requires either:

1. Accepting cancelled jobs as a legitimate status
2. Removing cancel-in-progress: true from concurrency groups
3. Configuring branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

This step will never execute when the job is actually cancelled, making it ineffective.

Suggested change

	# Ensure cancelled jobs don't show as failed (red X) in PR checks
	# When job is cancelled by concurrency, this step ensures success status
	- name: Ensure success on cancellation
	if: always() && cancelled()
	run: |
	echo "Job was cancelled - marking as success to avoid misleading red X"
	exit 0

[Copilot]

This approach does not achieve the intended goal. When a workflow job is cancelled by GitHub Actions (via concurrency groups), the entire job is cancelled immediately and no subsequent steps run - including steps with if: always() && cancelled(). The job conclusion remains "cancelled" regardless of this step.

According to GitHub Actions documentation, when a job is cancelled:

1. GitHub sends a SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always()

The fundamental issue is that branch protection rules and status checks treat "cancelled" jobs as failed (red X). However, this cannot be worked around at the workflow level - it requires either:

1. Accepting cancelled jobs as a legitimate status
2. Removing cancel-in-progress: true from concurrency groups
3. Configuring branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

This step will never execute when the job is actually cancelled, making it ineffective.

Suggested change

	# Ensure cancelled jobs don't show as failed (red X) in PR checks
	# When job is cancelled by concurrency, this step ensures success status
	- name: Ensure success on cancellation
	if: always() && cancelled()
	run: |
	echo "Job was cancelled - marking as success to avoid misleading red X"
	exit 0

[Copilot]

This approach does not achieve the intended goal. When a workflow job is cancelled by GitHub Actions (via concurrency groups), the entire job is cancelled immediately and no subsequent steps run - including steps with if: always() && cancelled(). The job conclusion remains "cancelled" regardless of this step.

According to GitHub Actions documentation, when a job is cancelled:

1. GitHub sends a SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always()

The fundamental issue is that branch protection rules and status checks treat "cancelled" jobs as failed (red X). However, this cannot be worked around at the workflow level - it requires either:

1. Accepting cancelled jobs as a legitimate status
2. Removing cancel-in-progress: true from concurrency groups
3. Configuring branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

This step will never execute when the job is actually cancelled, making it ineffective.

[Copilot]

This approach does not achieve the intended goal. When a workflow job is cancelled by GitHub Actions (via concurrency groups), the entire job is cancelled immediately and no subsequent steps run - including steps with if: always() && cancelled(). The job conclusion remains "cancelled" regardless of this step.

According to GitHub Actions documentation, when a job is cancelled:

1. GitHub sends a SIGINT/SIGTERM to the runner
2. After a grace period, the runner forcibly terminates all processes
3. No further steps execute, even with if: always()

The fundamental issue is that branch protection rules and status checks treat "cancelled" jobs as failed (red X). However, this cannot be worked around at the workflow level - it requires either:

1. Accepting cancelled jobs as a legitimate status
2. Removing cancel-in-progress: true from concurrency groups
3. Configuring branch protection to not require these checks for cancelled runs (not currently supported by GitHub)

This step will never execute when the job is actually cancelled, making it ineffective.

[coveralls]

coverage: 64.647%. remained the same
when pulling 1c9138d on copilot/fix-job-cancellation-status
into 78d3ee4 on dev.

[bact]

@copilot apply changes based on the comments in this thread

[Copilot]

@copilot apply changes based on the comments in this thread

Reverted all cancellation handling changes in commit 857e1f2. The approach doesn't work because cancelled jobs terminate immediately without executing subsequent steps, even with if: always() && cancelled(). The issue cannot be solved at the workflow level and requires accepting cancelled status or removing cancel-in-progress: true.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud