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 private module discovery
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 actor-trust enforcement turned on — the enforce-actor-trust input, or the ENFORCE_ACTOR_TRUST repository/organization variable — every privileged pull-request, review, or comment trigger on an allowlisted bot-authored PR must come from an allowlisted bot or the explicit devantler maintainer actor. Workflow reruns also require the initiating github.triggering_actor to be allowlisted; a trusted original event cannot be replayed by an untrusted collaborator. A rejected pull-request lifecycle trigger—or, when review gates are also enforced, an untrusted dismissal/deletion of trusted review evidence—receives no App token and actively revokes both classic auto-merge and merge-queue state with the caller's GITHUB_TOKEN. These state-removal runs arbitrate within each caller workflow at run creation, so they cancel an older privileged run before its jobs can mutate the PR without cancelling another caller's run. This caller-keyed state lease is acquired only when the reusable auto-merge lane actually executes, so unrelated or conditionally skipped runs of the surrounding caller workflow cannot suppress arming. Same-second lifecycle events share the lease, while unrelated title, label, or assignment edits create no replacement run. Before mutation, a live reopen/ready-for-review/force-push timeline binding rejects later events (including a head that moves away and returns) and treats any equal-time sequence it cannot uniquely identify as superseded. Arming and revocation share one mutation lane; a delayed rejected event preserves only auto-merge state whose authorization time is provably newer than that rejected run attempt. Default-off review/comment no-ops skip the mutation lane entirely, so they cannot replace a queued revocation. Every workflow_call invocation that enables actor trust should provide a globally caller-unique, ref-independent concurrency-key. Existing opted-in callers that omit it retain compatibility in a safe repository-wide actor-trust lane; explicit keys isolate independent callers from one another. The direct and cross-repository required-workflow paths have a built-in stable source identity. Legacy default-off callers retain their existing behavior.

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:
      actions: read
      pull-requests: write
      contents: write
    with:
      enforce-actor-trust: false # default; enable after validating trusted trigger actors
      enforce-review-gates: false # default; flip after the repo's review lanes are validated
    secrets:
      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

Actor-trust note: Callers that enable actor trust must grant actions: read, contents: write, and pull-requests: write as shown above and should pass a stable, globally caller-unique concurrency-key. An omitted key uses a safe repository-wide compatibility lane, which can cancel independent actor-trust call sites for the same PR but cannot let stale authority proceed; explicit keys avoid that availability tradeoff. Workflow-level arbitration orders lifecycle state only for the reusable lane that actually executes; skipped or unrelated caller runs do not reauthorize or supersede it. Both the original and rerun-triggering actors must be trusted for every privileged event. The read scope binds stale-revocation decisions to the rejected run attempt's durable start time; the write scopes revoke classic auto-merge or merge-queue state. Rejected events never receive the App private key. Missing lookup or revoke authority fails the required workflow closed.

Note: The caller grants the documented minimum above with or without enforcement. Actor trust uses its caller Actions: read scope only to bind stale revocation to the rejected run attempt's start time. Review enforcement uses a separate App token and additionally requires the GitHub App installation to grant Actions: read, Checks: read, and Contents: read. If a required scope is missing, the workflow fails closed rather than approving or arming on unproven evidence.

Secrets and Inputs

Key	Type	Default	Required	Description
APP_PRIVATE_KEY	Secret	-	Yes	GitHub App private key
enforce-actor-trust	Input	false	No	Opt-in trusted-trigger enforcement with fail-closed revocation
enforce-review-gates	Input	false	No	Opt-in fail-closed gate before approval; agent arms after live pentad
concurrency-key	Input	""	No	Recommended with actor trust; omitted calls share a safe fallback lane

🧹 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.

MegaLinter always runs read-only, without a GitHub token or persisted checkout credentials. When auto-fixing is enabled, the lint job exports a patch and a separate job on a fresh runner mints the write-scoped App token, applies that patch, and commits it. This isolation prevents pull-request-controlled MegaLinter configuration from accessing repository write credentials.

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: read
    with:
      apply-fixes: false

To enable pull-request auto-fixes, set apply-fixes: true and pass APP_PRIVATE_KEY. MegaLinter still runs without that secret; only the separate patch-application job can access it.

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
enable-caller-pin	Input (boolean)	false	No	Refuse to publish unless the caller pinned this workflow to a 40-character commit SHA. The signing certificate records the calling ref, and the cluster's trust rules verify it, so an unpinned caller lets a superseded revision mint a trusted signature. Opt-in during rollout (#864); every current caller already qualifies

📦 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
enable-caller-pin	Input (boolean)	false	No	Refuse to publish unless the caller pinned this workflow to a 40-character commit SHA. The signing certificate records the calling ref, and the cluster's trust rules verify it, so an unpinned caller lets a superseded revision mint a trusted signature. Opt-in during rollout (#864); every current caller already qualifies

📦 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. On authenticated runs, 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) and is skipped on credential-free pull-request runs.

Secrets and Inputs

Key	Type	Default	Required	Description
enable-github-packages	Input (boolean)	false	No	Use GITHUB_TOKEN for private packages and Code Quality on trusted same-repository non-bot pull-request code
working-directory	Input (string)	""	No	Directory containing the .NET solution or project

Pull-request runs are credential-free by default. A trusted same-repository human-authored pull request that needs private GitHub Packages can set enable-github-packages: true. The workflow ignores that input for fork and bot pull requests, so their code cannot opt itself back into the token-bearing path. Merge-group and direct non-pull-request runs authenticate with the automatic GITHUB_TOKEN when the calling job grants packages: read. The same explicit token boundary keeps the Code Quality uploader out of credential-free runs.

📝 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/platform-tenant-template

By default the sync PR is opened with GITHUB_TOKEN, so GitHub does not trigger on: pull_request or on: push workflows for the resulting branch or PR. This prevents content copied from a compromised or malicious template from reaching a caller's CI trust boundary before review.

Set use-app-token: true and pass APP_PRIVATE_KEY only when CI must run before the sync PR is reviewed. This opt-in mints a write-scoped App token and permits workflow-file updates, but it also causes the template-controlled PR content to trigger caller CI. Callers that opt in must treat the PR as untrusted: do not expose secrets or write-scoped tokens to jobs that check out or execute its content, including local actions and scripts.

An opt-in caller must wire both the input and the corresponding secret:

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

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)	false	No	Opt in to an App-authored sync PR that 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)
working-directory	Input (string)	""	No	Go module directory to validate. Empty means the repository root
scan-default-branch	Input (boolean)	false	No	Also run the vulnerability scan on every default-branch run, not just on pull requests. Off by default: a default branch that was green can legitimately go red once an advisory is published against code that already merged
test-default-branch	Input (boolean)	false	No	Also run the Go test suite on every default-branch run, not just when the diff touched a Go file. Off by default: a test can take a non-Go file as its subject, so a default branch that was green can legitimately go red once the suite stops being skipped

Contributing

See CONTRIBUTING.md for conventions and guidelines.