Project tokens

Keep the checkout clean

Publish requires a clean checkout before export and again before upload. Git-ignored files, this run’s output directory, and Mokly’s own caches and temporary files never count. Committed generated files count and must match the build. Derived generated output must be ignored by Git.

A build step that changes tracked files or leaves files that Git does not ignore stops the publish. Commit generated changes before the job runs. Add build products to .gitignore. Use npm ci to install from the committed lockfile without changing it.

One token per publishing job

Publishing presents a bearer token to the endpoint you name. The token is read from MOKLY_TOKEN or from --token, and it is sent in the Authorization header of every upload request, only to the endpoint’s own origin, and nowhere else.

Where to keep it

Keep the token in your CI system’s secret storage and expose it to the job as an environment variable. Prefer the environment variable to the option: a command line ends up in shell history and in job logs, and an environment variable does not.

A token that begins with - needs the assigned form so it is not read as an option:

npx mokly publish --token=-TOKEN

What the token controls

The service that receives the upload decides what a token may do. The upload names the repository, the branch and the revision it came from, and it is the receiver that checks whether that token is allowed to publish for that repository before it exposes anything.

Mokly never prints the token, including in error messages and diagnostics, and it never writes it into the export.

Rotating

Because the token lives only in your CI secrets, rotating it is a change in one place. A rejected token fails the job with the upload-unauthorized category rather than a partial publication.