Deploy and release a node package

This guide takes a package of custom Integration Studio nodes from your repository to the palette of the tenants that use it. You deploy the package with the revenexx CLI or from a repository connected in Cockpit, follow its release round through review, and check its state on the way. It is for developers who build nodes with the Integration Node SDK and have a package that builds. You need the CLI, your revenexx identity, a tenant slug, and a machine-to-machine X-Revenexx-Api-Key from Cockpit that covers integrations (a development key with full access * is simplest).

Quick start

npm run build
revenexx deploy integration
revenexx release status

The rest of this guide explains each step and what happens after the upload.

1. Check the package builds

The platform builds the package itself: it installs the dependencies, runs the package's build, and packs the result. The packed package has to contain package.json and the manifest that the SDK's manifest step writes, so the build script must run both steps (see The build):

{
  "scripts": {
    "build": "tsup && rvnxx-nodes manifest"
  }
}

Run npm run build locally before you deploy. A missing manifest is the most common reason a build fails. For a new release, bump version in package.json; Package manifest explains how the package version and each node's version differ.

2. Sign in

Sign in once with your key and tenant. Keep REVENEXX_TENANT exported, or pass --tenant on each command:

export REVENEXX_API_KEY="rvxk_..."
export REVENEXX_TENANT="<TENANT_SLUG>"
revenexx login --token "$REVENEXX_API_KEY" --tenant "$REVENEXX_TENANT"

See Authentication for how the tenant resolves.

3. Deploy

There are two ways to get a package onto the platform. Pick one per package.

From the command line

Run deploy integration from the package directory, or pass the directory as an argument:

revenexx deploy integration

The command uploads the package source, waits for the build, and then reads the release round, the review of this upload, as deploy app does (see Follow the release round). The checks of the review run on the built package, and their results are part of the round.

• --integration-id <id> — deploy to an existing integration instead of finding one by name.
• --from-git — deploy from the integration's connected repository instead of uploading the directory (see below).
• --release-wait <seconds> — how long to wait after the build for the round to be approved or rejected.
• --json — print the result as a JSON document.

Run revenexx deploy integration --help for the full list.

From a connected repository

In Cockpit, open Integration Studio → My Integrations, choose Connect repository, and pick the repository, the production branch and the root directory, the folder inside the repository that holds the package. There is no build command or runtime to configure: the platform detects the node package. Choose Build for the first build. After that, every push to the production branch builds the package again.

To deploy a connected package from the command line, use --from-git:

revenexx deploy integration --from-git

A deploy from a repository, by push or with --from-git, always runs in deploy mode. To preview a version first, upload it with preview integration.

4. Follow the release round

Where the platform reviews releases, a package version reaches tenants only once its release round is approved. A version can have several rounds, numbered rc 1, 2 and so on. After the build, deploy integration prints a release <version> rc <n> (deploy): <state> line each time the round changes state, and waits for a decision.

• Approved. Tenants can use the version: its nodes appear in the Integration Studio palette.
• Rejected. The command fails and prints the reason. Fix it, bump the version if needed, and deploy again.
• Still in review. The build is done, but tenants cannot use the version yet. The command says so and prints the command to resume later. This is a wait, not a failure, so in CI read the JSON result rather than the exit code.

The built package is handed to Integration Studio before the review decides. That does not make it available: until the round is approved, only tenants on the candidate channel can use a preview version, and nobody else sees it.

Check where a round stands at any time:

revenexx release status --integration-id <INTEGRATION_ID>

Run from the package directory, the command finds the integration by name, and --integration-id is not needed. It lists each round with its version, round number, mode, state, gate results, decision due date and rejection reason. The integration's page under My Integrations in Cockpit shows the same round.

Deploy or preview

deploy integration submits a round in deploy mode: once a reviewer approves it, the version is released.

preview integration runs the same flow in preview mode:

revenexx preview integration

A preview version is a release candidate. It is available on the candidate channel, to tenants that opted in to release candidates, while every other tenant keeps the last approved version. It goes out to everyone only after your go and the reviewer's approval. Give your go once you have tried the candidate in a workflow:

revenexx preview accept --integration-id <INTEGRATION_ID> --release-version <VERSION> --rc <N>

• --release-version defaults to the version in package.json. Without one, it takes the newest preview candidate.
• --rc defaults to the version's current candidate round.
• --integration-id skips the lookup by name.

Your go does not replace the reviewer's approval. The command prints the round's state after accepting, and if a reviewer still has to approve, it says so. In Cockpit, a preview that waits for your go shows a link to accept it on the integration's page.

After the release

The nodes appear in the Integration Studio palette, grouped under the label from your package.json, together with the credential types and templates the package ships. A new version does not change workflows that already use your nodes: a node on a canvas keeps the node version it was placed with until an author re-places or re-saves it. See Package manifest.

Troubleshooting

• The build fails without a manifest. The build script does not run rvnxx-nodes manifest, or the compiled entry point does not export the arrays it reads. Run npm run build locally and check for the manifest in the output.
• The command fails with "release … was rejected". A reviewer or one of the checks rejected the round. The reason follows the colon, and the rejection column of revenexx release status shows it too.
• The deploy ends with the release still in review. Nothing is wrong. Check with revenexx release status --integration-id <INTEGRATION_ID>. Tenants can use the version once a reviewer approves it.
• The nodes do not show up in a tenant's palette. The round is not approved yet, or the tenant is not on the candidate channel for a preview. Check revenexx release status.
• "this gateway does not offer release rounds yet". The platform you deploy to does not review releases. release status and preview accept have nothing to show there.

Where to go next

• Custom nodes — building the nodes in the package.
• Package manifest — what one package can contain, and how versions work.
• Integration Node SDK — the authoring reference.
• Deploy and verify an App — the same release round, as it applies to Apps and Themes.