Skip to content

Jimothyfile

A Jimothyfile is a file named Jimothyfile at the root of a repository that lists the commands pipelines use there: how to set it up, test it, lint it, and anything else. It’s committed with the code, so the commands travel with the branch and anyone using Jimothy on the repository gets the same ones.

It’s an alternative to typing the commands into a project’s Commands fields.

One name: command per line, Procfile style:

# Jimothyfile
setup: npm ci
test: npm test -- --run
lint: npm run lint
e2e: npx playwright test
  • A line starting with # is a comment. Blank lines are ignored.
  • A line ending in \ continues on the next line.
  • Names use letters, digits and _, and start with a letter.
  • Spaces around the : are optional.

Every name becomes a variable {{vars.<name>Command}}. The file above gives {{vars.setupCommand}}, {{vars.testCommand}}, {{vars.lintCommand}} and {{vars.e2eCommand}}. Use them in shell steps with | raw:

{{vars.setupCommand | raw}} && {{vars.e2eCommand | raw}}

setup, start, test, build and lint match the app’s Commands fields. Any other name works the same way in templates.

A run reads the Jimothyfile from its own workspace, not from your clone:

  • when the run starts, after the workspace is ready, and
  • again before every step.

So a branch that changes how tests run brings its own version, and a step that edits the file is picked up by the next step. The run log lists the commands it found, for example Jimothyfile: setup, test, lint, e2e, or api/Jimothyfile: … for a repository in a folder of several.

Commands set in the app win over the Jimothyfile:

  • At the workspace root, the Jimothyfile’s commands sit under everything else: the project’s Commands, project variables, pipeline variables and per-run overrides. A pipeline variable named testCommand hides the file’s test command, so don’t define one if you want the file to apply.
  • In a step that runs in each repository, the repository’s own commands come first: the command set on the repository in the app, then its Jimothyfile, then everything above.

When you create a pipeline from a built-in template in a project whose workspace root has a Jimothyfile, the template’s command variables that the file provides are dropped, so they don’t hide it.

Problems in the file don’t stop the run. They’re reported in the run log:

  • a line that isn’t name: command: Jimothyfile line 4: expected "name: command";
  • a name with nothing after the colon: Jimothyfile line 6: "e2e" has no command, and the line is ignored;
  • a name defined twice: Jimothyfile line 9: "test" is defined twice; the last one wins.

The Commands fields of a project, and of each repository in a folder of several, show the Jimothyfile:

  • With a file, the section says “Uses this folder’s Jimothyfile”, and each field shows the file’s command as a greyed placeholder with the hint “From Jimothyfile; type to override”. Typing a command in the field overrides the file. Names beyond the five standard ones are listed in the note.

  • Without a file, Fill in from the files fills the empty fields with commands guessed from the repository:

    Files Guesses
    package.json npm, pnpm, yarn or bun, depending on the lockfile. A plain vitest test script gets --run.
    Pipfile, pyproject.toml (Poetry, uv), requirements.txt Install command; pytest or Django’s manage.py test; ruff or flake8.
    Makefile test, lint, build, and install or setup targets.
    go.mod, Cargo.toml The Go or Cargo commands.
    *.tf terraform init -backend=false, terraform validate, terraform fmt -check.
  • Save as Jimothyfile writes the commands in the fields to a new Jimothyfile in the folder, then clears the fields so the file is what runs use. It never replaces an existing file. Commit the file with the code. It’s only available in the desktop app, not over remote access.