This is the project owner's checklist for the external, one-time setup that the
.gitlab-ci.yml pipeline assumes. The pipeline file itself is committed and
correct; the steps below wire up the GitLab project, secrets, security
features, npm Trusted Publishing, and Pages so those jobs actually do something.
The pipeline degrades gracefully: before any of this is done, pushes still run
the test stage, the dogfood jobs are skipped (no SLACK_TOKEN), the release job
only runs on tags, and the managed security jobs are inert until the matching
GitLab features are enabled.
- Create a new project on GitLab (gitlab.com or self-managed) named
slackwire. - If you want npm provenance (recommended), make the project public. Provenance attestations are only accepted by npm for public repositories.
- Push the existing history to GitLab as the canonical remote.
The intended topology is: GitLab is canonical, GitHub is a read-only mirror.
- Create an empty GitHub repository (for example
your-org/slackwire). - Generate a GitHub Personal Access Token (PAT) with
reposcope on GitHub. - In GitLab: Settings -> Repository -> Mirroring repositories.
- Add a mirror:
- Git repository URL:
https://github.com/your-org/slackwire.git - Mirror direction: Push
- Authentication method: Password
- Username: your GitHub username
- Password: the GitHub PAT
- Git repository URL:
- Save. GitLab now pushes branches and tags to GitHub automatically, keeping GitHub a read-only mirror of GitLab.
Set these in Settings -> CI/CD -> Variables:
| Variable | Value | Flags | Used by |
|---|---|---|---|
SLACK_TOKEN |
Slack bot (xoxb-) or user (xoxp-) token |
Masked, Protected | dogfood stage |
SLACK_CHANNEL |
Target channel ID (e.g. C0EXAMPLE123) or name |
(plain) | dogfood stage |
Notes:
- The Container Registry and GitLab Pages are built-in. You do not set
any variables for them. The registry credentials (
$CI_REGISTRY,$CI_REGISTRY_IMAGE,$CI_REGISTRY_USER,$CI_REGISTRY_PASSWORD) are injected automatically by GitLab for the project's own registry. - npm publishing uses OIDC, so there is no
NPM_TOKENto set here. See section 4. - Mark
SLACK_TOKENas Masked (so it never prints in logs) and Protected (so it is only exposed to protected branches and tags). - The dogfood jobs are gated on
rules: - if: '$SLACK_TOKEN'. Until this variable exists, those jobs are simply not created and the pipeline runs cleanly without them.
The pipeline includes GitLab's managed security templates (SAST/Semgrep, Secret Detection, Dependency Scanning, Container Scanning). They are inert until the corresponding features are enabled and (for some) licensed on the project.
- Go to Settings -> Security & Compliance (and Security configuration).
- Enable:
- SAST (Semgrep-based static analysis)
- Secret Detection (leaked credential scanning)
- Dependency Scanning (vulnerable dependency detection)
- Container Scanning (scans the image built in the
buildstage)
- Some scanners require a GitLab Ultimate tier for full reporting. The jobs run regardless; the merge-request security widgets and vulnerability dashboard are the tier-gated parts.
Container scanning is pointed at the per-commit image
$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA produced by the build:image job, so
it scans exactly what was built in this pipeline.
The release job publishes with Trusted Publishing: short-lived OIDC tokens instead of a stored npm token, with provenance attestations emitted automatically. This must be configured once per package on npmjs.com before the first tag.
Reference: https://docs.npmjs.com/trusted-publishers/
For each of the three published packages:
slackwire@slackwire/core@slackwire/mcp
do the following on npmjs.com:
- Open the package settings (or create the package placeholder if it does not exist yet, then configure publishing access).
- Add a Trusted Publisher with provider GitLab.
- Point it at:
- The GitLab namespace/project for
slackwire(the canonical GitLab repo). - The CI/CD job that publishes:
release:npm. - The top-level pipeline / default ref as required by the npm form.
- The GitLab namespace/project for
- Save.
Requirements that the pipeline already satisfies, but that you must keep true:
- npm CLI >= 11.5.1 and Node >= 22.14. The release job starts from
node:22and runsnpm install -g npm@latestto guarantee a recent enough npm. It also printsnode --versionandnpm --versionso you can verify in the job log. - The GitLab repo must be public for provenance to be accepted (see section 1).
- The job mints the OIDC token via the
id_tokens:block with audiencenpm:registry.npmjs.org. npm reads$NPM_ID_TOKENautomatically duringpublish; you do not pass any provenance flag by hand.
If a trusted publisher is not configured for a package, pnpm -r publish will
fail authentication for that package. Configure all three before tagging.
A release is driven entirely by pushing a version tag.
-
Bump versions in the package manifests (
packages/cli/package.json,packages/core/package.json,packages/mcp/package.json) to the newX.Y.Z. -
Update
CHANGELOG.mdwith the release notes. -
Commit, then tag with a
v-prefixed semver tag and push the tag:git tag vX.Y.Z git push origin vX.Y.Z
-
The tag pipeline:
- Runs the
teststage (lint, build, test across the workspace). - Builds and pushes the Docker image tagged with the commit SHA, the tag
name (
vX.Y.Z), andlatestto the GitLab Container Registry. - Runs the
release:npmjob, which publishes@slackwire/core,@slackwire/mcp, andslackwireto npm with provenance via OIDC. - If
SLACK_TOKENis set, posts and morphs a Slack status card for the run.
- Runs the
-
Docs deploy separately: GitLab Pages publishes
docs/site/on every push to the default branch (not on tags). Merge your docs changes to the default branch to update the published site.
The push mirror (section 1) then mirrors the tag and commit to GitHub automatically.
The package manifests use the GitLab project URL:
https://gitlab.com/slackwire/slackwire
This namespace/project path (slackwire/slackwire) is set in
packages/cli/package.json, packages/core/package.json, and
packages/mcp/package.json. These
URLs feed the npm package repository, homepage, and bugs fields, and
provenance ties attestations to the source repo, so they must be accurate
before the first publish.