GitHub Actions Ubuntu build job is stuck and does not complete

[zorowk]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

GitHub Actions Ubuntu job is canceled after all tests pass

Our GitHub Actions Ubuntu CI job was canceled immediately after the test suite
completed successfully.

Job URL:
https://github.com/linuxdeepin/treeland/actions/runs/32841769589/job/97782647441

The final test output shows that all executed tests passed:

100% tests passed, 0 tests failed out of 48

Label Time Summary:
protocols    =  14.86 sec*proc (32 tests)

Total Test time (real) =  21.73 sec

The following tests did not run:
         19 - test_treeland_foreign_toplevel_manager_v1 (Disabled)

Immediately afterwards, the job ended with:

context canceled
Error: The operation was canceled.

No test failure occurred before the cancellation. The disabled test is expected
and is unrelated to the cancellation.

Could you help determine why the GitHub Actions job was canceled after the
workflow steps had completed successfully? In particular, we would like to know
whether this was caused by GitHub Actions infrastructure, runner termination,
or workflow cancellation behavior.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[tomm1990]

not a mystery “canceled right after green tests” and not ARC. the job ran into the GitHub-hosted ~6h wall, and the interesting part is what happened before that kill.

from the public job log / API:

• job start 11:20:09Z, cancel 17:20:52Z → ~6h00m (hosted hard ceiling)
• cancelled step: Build treeland deb package
• 100% tests passed lands at 11:41:56Z (~22 min in)
• then no more step output until context canceled at 17:20:52Z (~5h39m of silence)

so the tests really did pass. the step just never finished after that - hung / stalled with zero further logs - until the hosted job limit killed the context (context canceled / The operation was canceled.).

your workflow has no timeout-minutes and no concurrency, so this isn’t cancel-in-progress from a newer push.

do this first - fail faster + see where it sticks after ctest:

jobs:
  container:
    runs-on: ubuntu-latest
    timeout-minutes: 90   # or whatever budget you actually want; don’t wait for the silent 6h kill
    container: linuxdeepin/deepin:crimson

and split the long dpkg-buildpackage so packaging isn’t invisible after tests, e.g. DEB_BUILD_OPTIONS=nocheck on a package step, or run tests in their own step with a hard timeout-minutes: so a hang shows up as that step timing out.

if you need the full package build to keep going past 6h on hosted - you can’t on standard ubuntu-latest. prebake deps into the image / cache, or move the heavy job to a self-hosted / larger runner with a higher limit.

so: canceled cos the job hit ~6h while stuck silent after ctest, not cos the tests failed and not cos random infra yanked a healthy short job.