ci: align pre-commit hooks and GitHub templates - #161
Conversation
Adopt the shared pre-commit baseline: two-line SPDX header, conventional commit message validation (commit-msg stage), and the centralized add-license / add-spdx-license hooks from developer_tools v0.2.0. Run pre-commit CI only on files modified by the PR, and roll out the standard issue templates and the simplified single PR template. TRI-1100
Legal's Copyright / License Header Guidance specifies the SPDX form without a comma after the year. TRI-1100
Human-readable type labels with enforced descriptions and colors. TRI-1100
The add-license hook now fails when the LICENSE copyright year is stale. TRI-1100
Workflow files are license-processed again (only templates excluded); refresh the stale copyright year this repo's pre-commit workflow carried. TRI-1100
Grant issues:write to the labeling job (review feedback). TRI-1100
Greptile SummaryThis PR aligns the repository's CI and pre-commit configuration with the org-wide setup in
Confidence Score: 5/5Safe to merge — changes are CI/config only, no production code is touched, and the pull_request_target usage is correctly gated by a mutual-exclusion condition. All three changed files are CI infrastructure and pre-commit configuration. The pull_request_target pattern is intentional, well-documented, and correctly implemented. No application logic is affected. No files require special attention, though pre-commit.yml has minor style nits around the cache action version pin and missing restore-keys. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
PR[Pull Request Event] --> IS_SAME{"Same-repo PR?<br/>head.repo == github.repository"}
IS_SAME -- Yes --> PE[pull_request event triggers]
IS_SAME -- No --> PTE[pull_request_target event triggers]
PE --> SAFE_JOB["conventional-pr job runs<br/>(read-only token, no fork secrets)"]
PTE --> FORK_JOB["conventional-pr job runs<br/>(write token — labels only)"]
SAFE_JOB --> REUSABLE["Calls org reusable workflow<br/>triton-inference-server/.github@v1.4.3"]
FORK_JOB --> REUSABLE
REUSABLE --> TITLE[Validate PR title vs Conventional Commits]
REUSABLE --> LABEL[Derive & apply type label]
REUSABLE --> CHERRY[Detect cherry-picks]
Reviews (2): Last reviewed commit: "ci: harden CI workflows and configs per ..." | Re-trigger Greptile |
| permissions: | ||
| pull-requests: write | ||
| issues: write | ||
| uses: triton-inference-server/.github/.github/workflows/conventional-pr.yml@v1.4.2 |
There was a problem hiding this comment.
Version tag inconsistency with PR description
The PR description consistently references v1.4.1 throughout (in the "What does the PR do?" section, the "Depends on" callout, and the "Pros/Cons" block), but both this workflow and .pre-commit-config.yaml are actually pinned to v1.4.2. The two config files are self-consistent, but the mismatch against the description means anyone cross-referencing the description to validate what is deployed will be misled.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Fixed - documentation drift: the descriptions have been refreshed to the current pinned tag v1.4.3 (they lagged behind the tag revisions; the tag exists and CI is green fleet-wide).
- conventional-pr stub: dual pull_request/pull_request_target triggers so fork PRs from external contributors get labeled too (the reusable workflow never checks out PR code); explicit contents:read; pinned v1.4.3. - pre-commit workflow: robust modified-files runner (null-delimited paths, deletion-only PRs handled, deleted paths filtered, no undocumented -r flag, cache keyed on config hash). - flake8 args quoted correctly (the flow-scalar form split at commas and silently reduced the select list). - hooks pinned to .github v1.4.3. TRI-1100
|
Closing: the team is moving away from centralized org-level configuration in favor of per-repository self-contained setups (see triton-inference-server/server#8897 for the first decentralized implementation). Branch retained for reference. TRI-1100 |
What does the PR do?
Aligns this repository with the org-wide setup consolidated in triton-inference-server/.github:
.pre-commit-config.yaml: shared baseline hooks, conventional-commit message validation (commit-msg stage), and the centralizedadd-licensehook from the org.githubrepository (rev: v1.4.3— excludes.github/templates, never rewrites LICENSE files).conventional-prworkflow (@v1.4.3): validates the PR title against Conventional Commits (hard gate — it becomes the squash-merge commit), derives one human-readable label per distinct type found in the title and all conforming commit subjects (e.g.ci:→CI/CD,feat:→feature,fix:→fix), enforces org-wide label colors/descriptions, detects cherry-picks, and fails if no type is derivable and no type label is assigned.Depends on triton-inference-server/.github#5 (pinned tags current:
v1.4.3— already exist, CI is green).Pros / Cons
Pros
.githubrepo) for hooks, templates, issue routing, and the PR-title workflow — one change propagates everywhere.Cons / risks
.githubrepository (tags are write-once; changes ship as a new tag + rev bump)..githubrepository to remain public.Related Issues / PRs
Related PRs:
Test plan
pre-commit validate-configpasses;pre-commit run --files <PR diff>passes locally with the centralized hooks pinned to the .github branch SHA.v1.4.3exists: the conventional-pr check validates this PR's own title and applies thecilabel.Caveats
Checklist
<commit_type>: <Title>(conventional commit)