DevantlerTech GitHub Actions & Reusable Workflows 🚀

The shared CI/CD building blocks used across all DevantlerTech projects — both composite actions and reusable workflow_call workflows — in one repository. (The reusable workflows were merged in from devantler-tech/reusable-workflows; that repo is being retired and will be archived once all consumers migrate their uses: pins here.)

Using them

An action is a step inside one of your jobs. A reusable workflow replaces a whole job. Both are called by path from this repository, pinned to a ref:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # an action — a step in your own job
      - uses: devantler-tech/actions/setup-go-toolchain@<ref>

  release:
    # a reusable workflow — the whole job comes from here
    uses: devantler-tech/actions/.github/workflows/create-release.yaml@<ref>
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

Pin <ref> to a commit SHA. Each entry in the tables below links to its own inputs and outputs.

The diagram below shows how GitHub Workflows, Jobs, Steps, Reusable Workflows, and Actions relate.

---
title: GitHub Actions Relationship Diagram
---
flowchart TD
  A[Workflows] --> B[Jobs]
  B --> C([Reusable Workflows])
  B --> D[Steps]
  C --> D
  C --> B
  D --> E[Actions]
  E -.- F([Composite Actions])
  F --> D
  E -.- G([JavaScript Actions])
  E -.- H([Docker Container Actions])

Loading

Actions

Action	Description
aggregate-job-checks	Aggregate multiple job results into a single required check
approve-pr	Approve a PR using a GitHub App identity
cleanup-ghcr-packages	Clean up old GHCR packages
create-issues-from-todos	Create GitHub issues from TODO comments
dependency-review	Scan a PR's dependency changes for vulnerabilities and disallowed licenses
diagnose-flux	Dump Flux reconcile state, controller logs, and failing pod logs on a stuck deploy
enable-auto-merge-on-pr	Enable auto-merge on a pull request
free-disk-space	Reclaim runner disk by removing large preinstalled toolchains
login-to-ghcr	Login to GitHub Container Registry
run-dotnet-tests	Test .NET solution or project with coverage
setup-agent-skills	Install agent skills via gh skill from a newline list of <owner/repo> <skill>[@pin] entries, for one or more agents (e.g. Copilot, Claude Code)
setup-go-toolchain	Setup Go with optional private module support
setup-ksail-cli	Install KSail CLI via Homebrew
update-agent-skills	Run gh skill update --all against installed skills and report changes
upload-coverage	Upload a Cobertura coverage report to GitHub Code Quality
upsert-issue	Create, update, reopen, or close a GitHub issue by title

Distribution

These are not on the GitHub Marketplace, and that is deliberate: Marketplace does not list actions that live in subdirectories, and everything here shares one repository and one release stream. Call them by path as shown above. The reasoning, and when it would be worth revisiting, is in AGENTS.md.

Reusable Workflows

Reusable workflows are designed to encapsulate common CI/CD patterns that can be shared across multiple repositories. They allow you to define a workflow once and reuse it in the job-scope of other workflows. This reduces duplication and enables building generic workflows for common tasks.

🎉 Create Release

Click to expand

.github/workflows/create-release.yaml is a workflow used to create releases using semantic-release.

The release is published with a GitHub App token, so the caller must set the APP_CLIENT_ID repository/organization variable alongside the APP_PRIVATE_KEY secret. The App always needs contents: write (tags/releases). By default it also needs issues: write + pull-requests: write for semantic-release success/fail hooks. Set disable-issue-side-effects: true to suppress those hooks and mint the token with contents: write only.

Usage

jobs:
  release:
    uses: devantler-tech/actions/.github/workflows/create-release.yaml@{ref} # ref
    with:
      disable-issue-side-effects: true
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

Secrets and Inputs

Key	Type	Default	Required	Description
APP_CLIENT_ID	Variable	-	Yes	GitHub App client ID used to mint the release token
APP_PRIVATE_KEY	Secret	-	Yes	GitHub App private key (paired with the APP_CLIENT_ID variable)
disable-issue-side-effects	Input (boolean)	false	No	Disable success/fail hooks and omit issue/pull-request token permissions
dry-run	Input (boolean)	false	No	Run semantic-release in dry-run mode (no tags or publishes)

🗑️ Delete Workflow Runs

Click to expand

.github/workflows/delete-workflow-runs.yaml is a workflow used to clean up old workflow runs from a repository.

Usage

jobs:
  delete-runs:
    uses: devantler-tech/actions/.github/workflows/delete-workflow-runs.yaml@{ref} # ref
    permissions:
      actions: write
      contents: read
    with:
      days: 30 # optional
      minimum-runs: 6 # optional
      dry-run: false # required to perform actual deletions (defaults to true)

Secrets and Inputs

Key	Type	Default	Required	Description
repository	Input (string)	Calling repo	No	Repository to target for workflow run deletion
days	Input (number)	30	No	Days-worth of runs to keep for each workflow
minimum-runs	Input (number)	6	No	Minimum runs to keep for each workflow
delete-workflow-pattern	Input (string)	-	No	Name or filename of the workflow to target
delete-workflow-by-state-pattern	Input (string)	ALL	No	Filter workflows by state (comma-separated)
delete-run-by-conclusion-pattern	Input (string)	ALL	No	Remove runs based on conclusion (comma-separated)
dry-run	Input (boolean)	true	No	Logs simulated changes, no deletions are performed

Note: The calling workflow must grant actions: write and contents: read permissions.

🛡️ Dependency Review

Click to expand

.github/workflows/dependency-review.yaml scans a pull request's dependency changes for known-vulnerable packages and disallowed licenses using GitHub Dependency Review. It is designed to run as an organization Required Workflow as well as via workflow_call.

It is non-blocking by default (warn-only: true, fail-on-severity: critical) so it can be required org-wide without blocking existing PRs; set warn-only: false to enforce. With comment-summary-in-pr: never (the default) the job needs only contents: read.

Usage

jobs:
  dependency-review:
    uses: devantler-tech/actions/.github/workflows/dependency-review.yaml@{ref} # ref

Inputs

Name	Description	Default
fail-on-severity	Block on vulnerabilities of this severity or higher (low, moderate, high, critical); only when warn-only is false.	critical
fail-on-scopes	Comma-separated scopes to block on (runtime, development, unknown).	runtime
allow-licenses	Comma-separated SPDX allow-list (empty = not enforced). Mutually exclusive with deny-licenses.	""
deny-licenses	Comma-separated SPDX deny-list (empty = not enforced). Mutually exclusive with allow-licenses.	""
comment-summary-in-pr	Post the summary as a PR comment (always, on-failure, never); anything but never needs pull-requests: write.	never
warn-only	Report findings as warnings and always succeed (non-blocking); set false to enforce.	true

🚀 Deploy GitHub Pages

Click to expand

.github/workflows/deploy-github-pages.yaml is a workflow used to build and deploy a Jekyll site to GitHub Pages.

Usage

jobs:
  pages:
    uses: devantler-tech/actions/.github/workflows/deploy-github-pages.yaml@{ref} # ref
    with:
      ruby-version: "3.3" # optional
      jekyll-env: production # optional
      extra-build-args: "" # optional, e.g. '--future'
      working-directory: "." # optional, e.g. 'docs' if Jekyll site is in a subdirectory

Secrets and Inputs

Key	Type	Default	Required	Description
dry-run	Input (boolean)	false	No	Skip build and deploy (validate workflow interface only)
ruby-version	Input (string)	3.3	No	Ruby version to install
jekyll-env	Input (string)	production	No	Jekyll environment
extra-build-args	Input (string)	""	No	Extra args appended before the automatically supplied --baseurl
working-directory	Input (string)	"."	No	Working directory for the Jekyll site (e.g., 'docs')

Outputs

Key	Description
page-url	Deployed Pages site URL

🔀 Enable Auto-Merge

Click to expand

.github/workflows/enable-auto-merge.yaml approves pull requests opened by an allowlist of trusted single-author bots, so routine bot PRs do not need a human click.

By default it behaves as it always has: it approves the PR and arms auto-merge, bound to the commit it checked.

With review enforcement turned on — the enforce-review-gates input, or the ENFORCE_MERGE_GATES repository/organization variable — it additionally requires, on the PR's current commit, both a passing review (CodeRabbit approved, or a clean Codex pass when CodeRabbit has no blocking result) and a fresh CodeRabbit pre-merge result. This gate fails closed: evidence that is missing, stale, edited, mixed, or unreadable counts as a failure, and the workflow then actively withdraws any auto-merge or merge-queue state the PR had.

Enforced runs approve but deliberately never arm the merge themselves. GitHub offers no way to tie mutable review evidence to the merge call atomically, so arming is left to whatever drives the merge afterwards.

[!IMPORTANT] If you enable enforcement via workflow_call, add pull_request_review and issue_comment triggers to your own caller workflow. Review results arrive after the pull_request event, and a reusable workflow cannot add triggers to the workflow calling it — so without these the gate never re-evaluates once a review lands.

Usage

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
  # Required when enforce-review-gates is true: review results land after
  # the pull_request events, so the caller must re-invoke the gate on them
  # — including edits and dismissals, which can turn green evidence red and
  # must be able to DISARM, and deleted comments, since removing a pre-merge
  # summary or Codex clean pass is evidence deletion the gate must re-evaluate.
  pull_request_review:
    types: [submitted, edited, dismissed]
  issue_comment:
    types: [created, edited, deleted]

jobs:
  auto-merge:
    uses: devantler-tech/actions/.github/workflows/enable-auto-merge.yaml@{ref} # ref
    permissions:
      pull-requests: write
      contents: write
    with:
      enforce-review-gates: false # default; flip after the repo's review lanes are validated
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

Note: The caller grants only the legacy minimum above, with or without enforcement — the enforced gate's read-only lookups run on a separate App token minted only on enforced runs, so opting in requires the GitHub App installation (not the caller's GITHUB_TOKEN) to include Checks: read, Actions: read, and Contents: read. If the installation lacks them, the gate fails closed (approval is withheld and stale arming is revoked) rather than open.

Secrets and Inputs

Key	Type	Default	Required	Description
APP_PRIVATE_KEY	Secret	-	Yes	GitHub App private key
enforce-review-gates	Input	false	No	Opt-in fail-closed gate before approval; agent arms after live pentad

🧹 Lint

Click to expand

.github/workflows/lint.yaml lints a whole repository with MegaLinter (Go flavor), auto-fixing what it can and committing the result back to the pull request.

Which one do I want? If your repository is a Go module, use ✅ Validate Go Project — it already runs MegaLinter as one stage of a full Go pipeline. Reach for this workflow when Go is only part of a larger tree (a game client plus a Go server, for example): it lints everything and leaves the Go build and tests to your own job.

The Go flavor covers Go, JSON, Markdown, YAML, shell, GitHub Actions, Dockerfile, Kubernetes, spelling, secrets and copy-paste. It has no GDScript, Python or Terraform linters — see MegaLinter's flavor list if you need those.

Configure the linters themselves in a .mega-linter.yml at your repository root, as usual.

Grant contents: write, even if you set apply-fixes: false. A caller must grant at least what the called workflow's jobs declare. Granting less is not a narrower permission — GitHub rejects the call when it loads the file, and the entire calling workflow returns startup_failure with no jobs at all, which looks exactly like the workflow never triggering. actionlint does not catch it.

Fork pull requests lint read-only, automatically. GitHub withholds secrets from forks, so fixes could never be committed back; auto-fixing there would only produce a failure an outside contributor cannot resolve. Real lint errors still fail on forks — only the auto-fix half is skipped.

Usage

jobs:
  lint:
    uses: devantler-tech/actions/.github/workflows/lint.yaml@{ref} # ref
    permissions:
      contents: write
      issues: write
      pull-requests: write
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

Secrets and Inputs

Key	Type	Default	Required	Description
APP_PRIVATE_KEY	Secret	-	No	GitHub App private key. Needed only to commit auto-fixes; without it a fixable finding fails the build instead
working-directory	Input	""	No	Directory to lint. Empty lints the whole repository
go-version-file	Input	""	No	Path to a go.mod. When set, Go is installed first so the Go linters use the module's toolchain, not the container's
apply-fixes	Input (boolean)	true	No	Auto-fix and commit back to the pull request. Set false for a read-only gate
pr-owner	Input	""	No	Pull request author login. Auto-fix commits are suppressed for dependency-bot pull requests

📦 Publish App

Click to expand

.github/workflows/publish-app.yaml is a workflow used to build and publish a containerized app and its Kubernetes manifests to GHCR as cosign-signed OCI artifacts. It builds and pushes the container image (tagged with the semantic version derived from the git tag — e.g. 1.2.3 from a v1.2.3 tag — plus sha-<sha> and latest), pins the built image digest into the deployment manifest's app-name container, pushes the manifests directory as a Flux-compatible OCI artifact (ghcr.io/<owner>/<repo>/manifests), and signs both the image and the manifests artifact with keyless cosign (Fulcio/Rekor via GitHub OIDC).

Usage

on:
  push:
    tags:
      - "v*"

jobs:
  publish-app:
    uses: devantler-tech/actions/.github/workflows/publish-app.yaml@{ref} # ref
    permissions:
      contents: read # checkout
      packages: write # push image + manifests OCI artifact
      id-token: write # keyless cosign signing
    with:
      app-name: my-app # container name in deploy/deployment.yaml
      deploy-path: ./deploy # optional

Note: Must be invoked from a semver tag (vX.Y.Z) — Docker semver tagging and Flux OCIRepository semver selection depend on it. The calling job must grant packages: write and id-token: write (and contents: read for checkout); no secrets are required (auth uses the GHCR-scoped GITHUB_TOKEN).

Secrets and Inputs

Key	Type	Default	Required	Description
app-name	Input (string)	-	Yes	Container name in the deployment manifest to pin to the built image digest
deploy-path	Input (string)	./deploy	No	Path to the Kubernetes manifests directory packaged as the OCI artifact

📦 Publish Manifests

Click to expand

.github/workflows/publish-manifests.yaml is a workflow used to publish a Kubernetes manifests directory to GHCR as a cosign-signed OCI artifact — with no container image build. Use it for repos that ship only manifests (e.g. GitOps/Crossplane desired-state) rather than an application: it pushes the manifests directory as a Flux-compatible OCI artifact (ghcr.io/<owner>/<repo>/manifests, tagged with the semantic version derived from the git tag — e.g. 1.2.3 from a v1.2.3 tag — plus latest), then signs the artifact by digest with keyless cosign (Fulcio/Rekor via GitHub OIDC). It is the manifests-only sibling of publish-app.yaml (which additionally builds and signs a container image).

Because the signing happens inside this reusable workflow, the cosign certificate identity (OIDC subject) is this workflow's path — https://github.com/devantler-tech/actions/.github/workflows/publish-manifests.yaml@<ref> — not the caller's. Verifiers (e.g. a Flux OCIRepository verify.matchOIDCIdentity) must match that.

Usage

on:
  push:
    tags:
      - "v*"

jobs:
  publish-manifests:
    uses: devantler-tech/actions/.github/workflows/publish-manifests.yaml@{ref} # ref
    permissions:
      contents: read # checkout
      packages: write # push manifests OCI artifact
      id-token: write # keyless cosign signing
    with:
      oci-name: devantler-tech/github-config # optional override; defaults to github.repository
      deploy-path: ./deploy # optional

Note: Must be invoked from a semver tag (vX.Y.Z) — Flux OCIRepository semver selection depends on it. The calling job must grant packages: write and id-token: write (and contents: read for checkout); no secrets are required (auth uses the GHCR-scoped GITHUB_TOKEN). Override oci-name when the repo name is an invalid OCI path component (e.g. .github → devantler-tech/github-config).

Secrets and Inputs

Key	Type	Default	Required	Description
oci-name	Input (string)	${{ github.repository }}	No	OCI repository name (<owner>/<name>) the artifact is published under, without the registry prefix or trailing /manifests. Override for invalid OCI path components
deploy-path	Input (string)	./deploy	No	Path to the Kubernetes manifests directory packaged as the OCI artifact

📦 Publish .NET Library

Click to expand

.github/workflows/publish-dotnet-library.yaml is a workflow used to publish .NET libraries to NuGet and GHCR.

Usage

jobs:
  publish-library:
    uses: devantler-tech/actions/.github/workflows/publish-dotnet-library.yaml@{ref} # ref
    secrets:
      NUGET_API_KEY: ${{ secrets.NUGET_API_KEY }}

Secrets and Inputs

Key	Type	Default	Required	Description
NUGET_API_KEY	Secret	-	No	NuGet API key (required when dry-run is false)
dry-run	Input (boolean)	false	No	Skip publish (validate workflow interface only)

🧪 Run .NET Tests

Click to expand

.github/workflows/run-dotnet-tests.yaml is a workflow used to test .NET solutions or projects across multiple operating systems. Coverage is merged into a single Cobertura report and uploaded to GitHub Code Quality (native PR coverage).

Usage

jobs:
  dotnet-test:
    uses: devantler-tech/actions/.github/workflows/run-dotnet-tests.yaml@{ref} # ref
    permissions:
      contents: read
      packages: read
      code-quality: write # required for GitHub Code Quality coverage upload

Note: The calling workflow must grant code-quality: write (otherwise the run fails at startup). Coverage requires the repo's Code Quality to be enabled (Settings → Code quality).

Secrets and Inputs

This workflow needs no caller-provided secrets or inputs — it authenticates to the GHCR NuGet feed with the automatic GITHUB_TOKEN (requires the packages: read permission shown above).

📝 Scan for TODO Comments

Click to expand

.github/workflows/scan-for-todo-comments.yaml is a workflow used to scan for TODOs in code and create GitHub issues.

Usage

jobs:
  todos:
    uses: devantler-tech/actions/.github/workflows/scan-for-todo-comments.yaml@{ref} # ref
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

Secrets and Inputs

Key	Type	Default	Required	Description
APP_CLIENT_ID	Variable	-	Yes	GitHub App client ID used to mint the issue-creation token
APP_PRIVATE_KEY	Secret	-	Yes	GitHub App private key (paired with the APP_CLIENT_ID variable)
dry-run	Input (boolean)	false	No	Skip issue creation (validate workflow interface only)

🔍 Scan for Workflow Vulnerabilities

Click to expand

.github/workflows/scan-for-workflow-vulnerabilities.yaml is a workflow used to perform static analysis on GitHub Actions workflows using Zizmor.

Usage

jobs:
  zizmor:
    uses: devantler-tech/actions/.github/workflows/scan-for-workflow-vulnerabilities.yaml@{ref} # ref

🔄 Sync Cluster Policies

Click to expand

.github/workflows/sync-cluster-policies.yaml is a workflow used to sync upstream Kyverno policies to a target directory.

Which policies are synced is controlled by a .policyignore file at the repo root. It uses gitignore-style syntax — ordered glob patterns, one per line, where a leading ! re-includes a previously excluded path — so you can exclude everything by default and whitelist just the policies you want:

# Ignore every category…
other*
# …except these two policies.
!other/create-pod-antiaffinity/create-pod-antiaffinity.yaml
!other/spread-pods-across-topology/spread-pods-across-topology.yaml

Patterns are evaluated per file with last-match-wins, so a ! re-include still applies even when a broad earlier pattern matched its parent directory.

Usage

jobs:
  sync-cluster-policies:
    uses: devantler-tech/actions/.github/workflows/sync-cluster-policies.yaml@{ref} # ref
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}
    with:
      kyverno-policies-dir: policies/kyverno

Secrets and Inputs

Key	Type	Default	Required	Description
APP_PRIVATE_KEY	Secret	-	Yes	GitHub App private key
kyverno-policies-dir	Input (string)	-	Yes	Directory to sync Kyverno policies to
dry-run	Input (boolean)	false	No	Skip sync and PR creation (validate workflow interface only)

🔄 Template Sync

Click to expand

.github/workflows/template-sync.yaml keeps a repository in sync with an upstream template repository via AndreasAugustin/actions-template-sync, opening a PR with any incoming template changes. List the files this repository owns (and that must never be overwritten by the template) in a .templatesyncignore file at the repo root — everything else the template ships is kept in sync.

Usage

on:
  schedule:
    - cron: "0 6 * * 1"
  workflow_dispatch:

jobs:
  template-sync:
    uses: devantler-tech/actions/.github/workflows/template-sync.yaml@{ref} # ref
    with:
      source-repo-path: devantler-tech/gitops-tenant-template
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

By default the sync PR is opened with a GitHub App token (use-app-token: true) so it triggers the caller's CI; this needs the APP_CLIENT_ID variable and the APP_PRIVATE_KEY secret. Set use-app-token: false to fall back to GITHUB_TOKEN (the PR then will not trigger on: pull_request checks).

Secrets and Inputs

Key	Type	Default	Required	Description
APP_PRIVATE_KEY	Secret	-	When use-app-token	GitHub App private key (paired with the APP_CLIENT_ID variable)
source-repo-path	Input (string)	-	Yes	owner/repo of the upstream template to sync from
upstream-branch	Input (string)	main	No	Branch of the template repository to sync from
pr-title	Input (string)	chore: sync changes from the upstream template	No	Title of the sync PR (Conventional-Commit by default)
pr-commit-msg	Input (string)	chore: sync changes from the upstream template	No	Commit message for the sync PR
pr-labels	Input (string)	dependencies,automation	No	Comma-separated labels for the sync PR
pr-branch-name-prefix	Input (string)	chore/template-sync	No	Prefix for the branch the sync PR is opened from
template-sync-ignore-file-path	Input (string)	.templatesyncignore	No	Path to the file listing consumer-owned (non-synced) files
use-app-token	Input (boolean)	true	No	Open the sync PR with a GitHub App token so it triggers the caller's CI
dry-run	Input (boolean)	false	No	Skip the sync and PR creation (validate workflow interface only)

Note: The calling workflow runs the sync job with contents: write and pull-requests: write (declared by the reusable workflow).

🔄 Update Agent Skills

Click to expand

.github/workflows/update-agent-skills.yaml is a workflow used to keep installed agent skills (Copilot, Claude Code, …) up-to-date via gh skill update --all, opening a PR with any changes. Each installed SKILL.md's metadata.github-* frontmatter is the source of truth — no lockfile is required. Works with any mix of gh skill-compatible upstreams.

Usage

on:
  schedule:
    - cron: "0 6 * * *"
  workflow_dispatch:

jobs:
  update-agent-skills:
    uses: devantler-tech/actions/.github/workflows/update-agent-skills.yaml@{ref} # ref
    permissions:
      contents: write
      pull-requests: write
    with:
      dir: .agents/skills

The workflow assumes skills were previously installed with devantler-tech/actions/setup-agent-skills (or gh skill install directly) — the committed SKILL.md files carry the upstream pointers.

Secrets and Inputs

Key	Type	Default	Required	Description
dir	Input (string)	.	No	Directory to scan for installed skills (passed to gh skill update --dir)
unpin	Input (boolean)	false	No	When true, pass --unpin (clear pinned versions)
gh-version	Input (string)	2.90.0	No	Minimum required gh version (must support gh skill)
pr-branch	Input (string)	deps/agent-skills-update	No	Branch the update PR is opened from
pr-title	Input (string)	chore(deps): update agent skills	No	Title of the update PR
pr-labels	Input (string)	dependencies,automation	No	Comma-separated labels for the update PR
commit-message	Input (string)	chore(deps): update agent skills	No	Commit message for the update PR
dry-run	Input (boolean)	false	No	Skip update and PR creation (validate workflow interface only)

Note: The calling workflow must grant contents: write and pull-requests: write permissions.

✅ Validate Go Project

Click to expand

.github/workflows/validate-go-project.yaml is a workflow used to lint and test Go projects across multiple operating systems.

Features

• Automated Linting: Runs golangci-lint and mega-linter to ensure code quality
• Auto-fix: Automatically applies linter fixes and commits them
• Copilot Integration: When linting fails, automatically prompts Copilot on the PR to fix the remaining issues
• Supply-chain Scanning: Runs govulncheck via the official golang/govulncheck-action to fail the PR on known vulnerabilities your code actually calls (call-graph reachability, so imported-but-unreachable advisories don't block). A consumer can risk-accept a reachable advisory that has no upstream fix (Fixed in: N/A) by committing an optional .govulncheck-allow.txt at the repo root (one GO-YYYY-NNNN # justification per line; # comments and blank lines ignored); the gate stays strict for everything else. Repos with no allowlist file keep using the official action unchanged — only opt-in repos take the allowlist-aware path.
• Code Coverage: Generates a Cobertura report and uploads it to GitHub Code Quality (native PR coverage).

Usage

jobs:
  go-test:
    uses: devantler-tech/actions/.github/workflows/validate-go-project.yaml@{ref} # ref
    permissions:
      contents: write
      code-quality: write # required for GitHub Code Quality coverage upload
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}
    with:
      pr-owner: ${{ github.event.pull_request.user.login }} # optional

Note: The calling workflow must grant code-quality: write so coverage can be uploaded to GitHub Code Quality. Coverage requires the repo's Code Quality to be enabled (Settings → Code quality).

Secrets and Inputs

Key	Type	Default	Required	Description
APP_PRIVATE_KEY	Secret	-	No	GitHub App private key for authenticating the workflow
pr-owner	Input (string)	-	No	Pull request author login (used to disable auto-commit for bot PRs)

Contributing

See CONTRIBUTING.md for conventions and guidelines.