Make dependency check always run and add workflow concurrency grouping#345
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the “Dependency Minimum Age Check” GitHub Actions workflow to run on every pull request event, while conditionally running the heavier dependency-check steps only when relevant files change.
Changes:
- Removed
on.pull_request.pathsso the workflow triggers for all PRs. - Added a
dorny/paths-filterstep and gated Rust/tooling steps behindif: steps.filter.outputs.relevant == 'true'. - Updated pinned action SHAs (e.g.,
actions/checkout,cargo-oxidate).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
.github/workflows/DependencyCheck.yaml:24
actions/checkoutruns even when no relevant files changed. Since the workflow is now triggered for all PRs, this will still download the repo on every PR even though all subsequent work is skipped. You can avoid the extra runtime/cost by gating the checkout step with the samepaths-filtercondition.
- name: Checkout repository
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
.github/workflows/DependencyCheck.yaml:26
actions/checkoutruns even when the change set is not relevant, so the workflow still checks out the repo on every PR even though later steps are skipped. Also, the repo’s other workflows consistently useactions/checkout@v4(e.g..github/workflows/Integration.yml:78,FeatureCheck.yml:40), so using a pinned SHA forv7.0.1here is inconsistent and may introduce different behavior than the rest of CI.
- name: Checkout repository
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.
Comments suppressed due to low confidence (1)
.github/workflows/DependencyCheck.yaml:25
- When there are no relevant changes, the workflow correctly skips Rust install and cargo-oxidate, but it still performs a full checkout. Add the same
if:guard to the checkout step to avoid unnecessary work on unrelated PRs.
- name: Checkout repository
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (2)
.github/workflows/DockerChecks.yml:11
concurrency.grouphere is inconsistent with the other workflows updated in this PR (it omitsgithub.event_name). That makes it easier to accidentally introduce cross-event cancellations later (e.g., if another trigger is added), and it diverges from the PR’s stated grouping format.
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
cancel-in-progress: true
.github/workflows/DependencyCheck.yaml:30
- When
steps.filter.outputs.relevantis false, the workflow still checks out the repository even though no subsequent steps will run. Sincedorny/paths-filteruses the GitHub REST API forpull_requestevents, you can skip checkout to make irrelevant runs complete faster.
- name: Checkout repository
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
Problem 1: The dependency check CI blocks PRs when the relevant files are not modified
Instead of skipping dependency check trigger when relevant files are not affected, we always run the workflow, but decide to skip within the workflow logic.
Problem 2: When you push a new commit to a PR, CI runs for previous commits still run, wasting resources
Add concurrency grouping for PR-based workflow runs. For branch pushes, the group ID falls back to
run_idso it doesn't affect branch pushes.