Vault Cortex utilizes a multi-layered GitHub Actions infrastructure to automate code quality checks, security auditing, and the distribution of three distinct artifacts: the vault-cortex Docker image (with :latest and :remote targets), the vault-cortex npm CLI package, and the official MCP Registry entry.
The ci.yml workflow serves as the primary quality gate for all code changes. It runs on every pull request and push to the main branch .github/workflows/ci.yml3-6
The checks job validates the core codebase using the following pipeline:
description in server.json is $\le$ 100 characters to prevent 422 errors during MCP Registry publication .github/workflows/ci.yml24-30short-description in dockerhub-description.yml to ensure it is $\le$ 100 UTF-8 bytes (as opposed to characters), as Docker Hub silently truncates overflows .github/workflows/ci.yml32-43prettier:check and eslint via npm run lint .github/workflows/ci.yml52-54Because the CLI package (under cli/) targets a wider range of Node.js versions than the server (engines $\ge$ 20.12), the cli-smoke job executes a matrix test across Node 20, 22, and 24 .github/workflows/ci.yml63-67 It builds the CLI using cli/tsconfig.json and executes a non-interactive init flow to ensure no "too-new" APIs were accidentally introduced .github/workflows/ci.yml80-92
Sources: .github/workflows/ci.yml1-92
Vault Cortex maintains a "Defense in Depth" security posture through specialized scanning workflows that report findings to the GitHub Security tab.
| Workflow | Tool | Purpose | Frequency |
|---|---|---|---|
gitleaks.yml | Gitleaks | Scans full git history for secrets/credentials using gitleaks detect .github/workflows/gitleaks.yml39-40 | Every PR/Push |
trivy.yml | Trivy | Scans Docker images for OS-layer CVEs in the Debian base .github/workflows/trivy.yml3-5 | PRs & Weekly |
scorecard.yml | OpenSSF Scorecard | Grades repo security (branch protection, SAST, token permissions) .github/workflows/scorecard.yml3-5 | Weekly |
Gitleaks is configured to scan the entire history with --log-opts="--all" .github/workflows/gitleaks.yml40 It installs a specific version (8.21.2) and verifies the checksum before execution .github/workflows/gitleaks.yml21-37
The trivy.yml workflow manages two scanning targets to cover both the standard and remote images:
trivy-pr: Builds fresh images from the branch (local and remote targets) and fails the PR (exit-code 1) if CRITICAL or HIGH vulnerabilities are found .github/workflows/trivy.yml113-171 It uses a daily cache-busting date for apt-get upgrade to ensure current Debian patches are scanned .github/workflows/trivy.yml131-133trivy-published: Scans the latest and remote images on GHCR weekly to detect post-release CVE drift .github/workflows/trivy.yml37-111 It uses docker manifest inspect to check if images exist before scanning to avoid workflow failures in fresh forks .github/workflows/trivy.yml52-66Dependabot is configured to provide weekly updates for npm, github-actions, and docker ecosystems. It specifically monitors the obsidian-headless dependency and its own lockfile.
Sources: .github/workflows/gitleaks.yml1-41 .github/workflows/trivy.yml1-171 .github/workflows/scorecard.yml1-53
Vault Cortex follows Conventional Commits. This convention is used by automation scripts to generate the CHANGELOG.md and GitHub release notes.
Server releases are triggered via manual_release.yml (workflow dispatch) or auto_release.yml (pushing a v* tag).
In a manual release, the operator selects a patch, minor, or major bump .github/workflows/manual_release.yml5-14 The bump-and-tag job:
jq on package.json .github/workflows/manual_release.yml64-76version in package.json and package-lock.json .github/workflows/manual_release.yml83identifier in server.json to point to the new GHCR image tag .github/workflows/manual_release.yml84The generate-notes.sh script extracts changes between the new tag and the previous one .github/scripts/generate-notes.sh17-26
Release Notes Data Flow
Sources: .github/scripts/generate-notes.sh1-168
The script prioritizes "Breaking Changes" detected via the ! type marker, BREAKING CHANGE: footers in commits/PRs, or the breaking-change PR label .github/scripts/generate-notes.sh131-143
The update-changelog.sh script prepends the generated notes to CHANGELOG.md .github/workflows/manual_release.yml162 The automation then commits this update back to the main branch to keep documentation in sync with the release .github/workflows/manual_release.yml164-181
deploy.yml workflow (called by manual_release.yml and auto_release.yml) builds and pushes both :latest (local) and :remote targets to GHCR and Docker Hub .github/workflows/manual_release.yml105publish-registry.yml workflow uses mcp-publisher (pinned to version 1.7.9) to update the official registry via GitHub OIDC .github/workflows/publish-registry.yml23-57 It verifies that the server.json version matches the release tag before publishing .github/workflows/publish-registry.yml38-44dockerhub-description.yml workflow syncs DOCKERHUB.md to the Docker Hub repository description .github/workflows/dockerhub-description.yml21-31Sources: .github/workflows/manual_release.yml1-200 .github/workflows/auto_release.yml1-136 .github/workflows/publish-registry.yml1-58 .github/workflows/dockerhub-description.yml1-31 CHANGELOG.md64-90
The vault-cortex CLI is released independently of the server via cli_release.yml.
The CLI uses NPM Trusted Publishing (OIDC), eliminating the need for long-lived secrets .github/workflows/cli_release.yml61-63
CLI Release Validation
Sources: .github/workflows/cli_release.yml69-111
bump: none to resume or abandon the version .github/workflows/cli_release.yml88-91beta publishes a prerelease under the beta dist-tag (e.g., v0.29.3-beta.330) without creating a git tag or GitHub release .github/workflows/cli_release.yml79-162--provenance to attest to the build's origin .github/workflows/cli_release.yml147The ghcr-cleanup.yml workflow runs weekly to prune untagged/orphaned images from the GitHub Container Registry, maintaining storage efficiency. The force_deploy.yml workflow allows for redeploying current releases with fresh configuration (e.g. secret rotation) without rebuilding the image .github/workflows/force_deploy.yml3-8
Sources: .github/workflows/cli_release.yml1-175 .github/workflows/ghcr-cleanup.yml1-40 .github/workflows/force_deploy.yml1-57
Refresh this wiki
This wiki was recently refreshed. Please wait 7 days to refresh again.