build-in-devcontainer: not cancellable in the GitHub UI?

[jameslamb]

Description

Today, I observed something like this on a cudf PR:

1. apply a suggestion from the GitHub UI (that creates a new commit)
2. immediately after, click "update branch" in the GitHub UI (created a new merge commit pulling in latest main)
3. observe all jobs on the CI run from the first commit auto-cancelled except devcontainer jobs
4. try to manually cancel the old workflow run by clicking "Cancel Workflow"
5. GitHub UI says "You have successfully requested the workflow to be cancelled"
6. devcontainer jobs not cancelled (even after 10 minutes), next CI run stuck in Pending until they finished

I don't know if this was GitHub issue (temporary or permanent), specific to the build-in-devcontainer workflow (maybe it doesn't respect OS signals?) or something else... just opening to track.

Notes

Details:

• original observation: check-nightly-ci: update to new version NVIDIA/cudf#21464 (comment)
• runs: https://github.com/rapidsai/cudf/actions/workflows/pr.yaml?query=branch%3Apull-request%2F21464

[mroeschke]

This note in the Github Actions documentation about cancellation may be relevant https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-cancellation

To cancel the workflow run, the server re-evaluates if conditions for all currently running jobs. If the condition evaluates to true, the job will not get canceled.

And there may be a likelihood that this last step might always evaluate to true

shared-workflows/.github/workflows/build-in-devcontainer.yaml

Line 220 in 52b4372

- if: ${{ always() && vars.TELEMETRY_ENABLED == 'true' }}

[jameslamb]

Hadn't seen those docs before, great post @mroeschke . I think you're right, that looks really relevant!

Not sure about that step though, even if it wasn't cancellable it is lightweight and only takes a few seconds. If I recall correctly, when I saw this the job was in this step:

shared-workflows/.github/workflows/build-in-devcontainer.yaml

Lines 159 to 160 in 4ede1f4

	- name: Run build in devcontainer
	uses: devcontainers/ci@8bf61b26e9c3a98f69cb6ce2f88d24ff59b785c6 # v0.3.1900000417

But I think it must be something like the quote you shared, because later on that doc says if it gets past the if: checks, then it'll kill jobs after 2500 milliseconds if they don't respond to SIGINT / SIGTERM.