Skip to content

ci(cann): drop auto-triggers (workflow has zero jobs upstream)#80

Open
marksverdhei wants to merge 1 commit into
htfrom
fix/disable-cann-ci-trigger
Open

ci(cann): drop auto-triggers (workflow has zero jobs upstream)#80
marksverdhei wants to merge 1 commit into
htfrom
fix/disable-cann-ci-trigger

Conversation

@marksverdhei
Copy link
Copy Markdown

Summary

Same pattern as PR #74build-cann.yml has had every job commented out since upstream PR ggml-org#23705, but kept its push:master + pull_request auto-triggers. Any PR touching ggml/src/ggml-cann/** would produce a zero-job "failure" run on this workflow.

This PR strips those auto-triggers and keeps only workflow_dispatch, so the workflow can still be invoked manually if/when jobs are re-enabled.

Why this hasn't fired yet on ht

Unlike build-sycl.yml (which has a path filter that matches almost any C/C++ change), the CANN pull_request path filter is narrow: ggml/src/ggml-cann/**. No recent PR has touched those files, so the zero-job failure runs haven't materialized. They will the next time a contributor touches CANN code.

Test plan

  • yaml validates
  • (post-merge) confirm no new build-cann runs fire on regular PRs

Related

🤖 Generated with Claude Code

Same pattern as PR #74 (build-sycl.yml): upstream PR ggml-org#23705 commented
out every job in this workflow, but the push:master + pull_request
auto-triggers stayed live. Any PR touching ggml/src/ggml-cann/** would
create a zero-job "failure" run.

Keep workflow_dispatch so the workflow stays available for manual
runs once jobs are re-enabled (which requires provisioning dedicated
runners per the upstream TODO).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant