shiftlabs Start free
Menu Projects

Projects

A project is a folder with a shiftlabs.config.ts that lists your workflows. shiftlabs deploy makes all of them current together, as one release.

The config file

shiftlabs.config.ts names each workflow and the file it is in. It can also list agents and schedules. Its default export must be project({...}).

shiftlabs.config.ts
import { project, schedule } from "shiftlabs";

export default project({
  workflows: {
    "refund-check": "./workflows/refund-check.ts",
    "nightly-report": "./workflows/nightly_report.py",
  },
  schedules: {
    nightly: schedule("nightly-report", { cron: "0 3 * * *" }),
  },
});
  • workflows

    Each workflow's name and its file, .ts, .js or .py, relative to the config file. Names are lowercase letters, digits and hyphens.

  • agents

    Each agent's definition, made with agent({...}). See Agents.

  • schedules

    Each schedule, made with schedule(...). They replace every schedule the workspace has. Leave schedules out to keep the workspace's; {} removes them all.

  • shiftlabs deploy reads shiftlabs.config.ts, then .mts, .js or .mjs, from the current folder. --config <file> names another.
  • Each workflow's file can import other files and, in TypeScript, npm packages. deploy sends them with it. See Files and packages.
  • shiftlabs init --template <name> writes a project to start from. See Templates.
  • shiftlabs types writes your workspace's secret and var names next to the config file, for your editor. See Editor types.

Deploy a project

shiftlabs deploy with no files deploys the project to the workspace of SHIFTLABS_API_KEY. It stages each workflow, then makes every workflow, agent and schedule the project lists current together in one release. Nothing goes live until the release does. Projects in the CLI shows each step and what deploy prints.

  • A developer key can deploy a project.
  • When nothing changed, deploy records no release, so CI can deploy on every push.
  • deploy deletes nothing. It lists the workspace's workflows and agents that the project doesn't name, and leaves them as they are.
  • shiftlabs deploy <file>... makes each workflow it names current at once. That isn't a release, and the release history doesn't show it.

Releases and rollback

The workspace doesn't store your project. It stores what deploy sends: each workflow's new version, and the release that made them current.

shellterminal
npx shiftlabs deploy
# release 8
#   workflow refund-check: 3f9a0c7e (was 1d9a281e)
#   workflow nightly-report: 8be21f04 (unchanged)
npx shiftlabs releases
npx shiftlabs rollback 7

A rollback makes an earlier release's versions and schedules current again, as a new release. See History and rollback.

Staging and production

Deploy the project to a staging workspace, then promote its release to a linked production workspace with shiftlabs promote <release> --to <workspace>.

A promotion copies the release's workflow versions byte for byte. Each workspace keeps its own secrets, vars and connections, and the target must have the ones the code reads. See Promote a release, and Deploy from GitHub to do it from CI.

Reference