Auto-Detected Projects

You don’t always have to write a runnables.yaml by hand. If a repository contains no runnables.yaml at all, Fileglancer looks for recognized project formats at the repository root and generates a manifest automatically. This means many existing Nextflow pipelines and Pixi projects work as Fileglancer apps with no extra files.

A hand-written manifest always wins

Auto-detection runs only when the repository contains no runnables.yaml anywhere, and it inspects the repository root only. Adding a single runnables.yaml — even in a subdirectory — disables auto-detection for the whole repository. To customize an auto-detected app — change the command, add resources, or reorganize parameters — commit a runnables.yaml at the repository root and it will be used instead.

Nextflow Pipelines

If a directory contains a nextflow_schema.json (and no runnables.yaml), Fileglancer generates a manifest from the Nextflow schema. The generated app:

• Sets requirements to ["nextflow"].
• Defines a single entry point named “Run pipeline” with the command nextflow run repo -ansi-log false and working_dir: work, so it launches from the job’s work directory. Running there (rather than inside the project checkout) keeps Nextflow’s .nextflow.log, .nextflow/ cache, and work/ directory in the per-job work directory instead of the checkout shared by jobs on the same app version. repo is a symlink to the checkout, and the directory form lets Nextflow resolve the pipeline’s main script from its main.nf or manifest.
• Derives the app name from the repository name (e.g. rnaseq for nf-core/rnaseq), and takes the description from the schema’s top-level description.
• Converts each JSON Schema parameter into a Fileglancer parameter, preserving types, defaults, descriptions, required flags, enum options, and hidden status. Generated parameters use Nextflow-safe emission forms: values are joined with = (--input=/data) so a value starting with - stays attached to its parameter, and booleans are emitted explicitly as --flag=true/--flag=false so unchecking a switch overrides a pipeline default of true. Path parameters only require existence when the schema property sets "exists": true, following the nf-schema convention.
• Groups parameters into sections based on the schema’s definitions/$defs, ordered by the schema’s allOf list. Section titles and descriptions come from each definition’s title, description, and help_text. All sections start expanded.
• Surfaces Nextflow-specific options on the launch form’s Environment tab:
  • Profiles (-profile) — comma-separated list of Nextflow profiles (e.g. standard,docker)
  • Extra Arguments — additional Nextflow CLI arguments (e.g. -resume, -with-tower), appended to the end of the command without shell quoting

The -profile flag is emitted before the pipeline parameters, and extra arguments are appended at the end, so the generated command is well-formed:

nextflow run repo -ansi-log false \
  -profile standard,docker \
  --input=/data/input \
  --skip_qc=false \
  -resume

These Nextflow-safe forms are applied when the command is built, so they also fix apps that were added under older Fileglancer versions — no re-add needed (see Command Building).

Most nf-core and Nextflow pipelines that follow the standard schema convention work out of the box — just add the repo URL in Fileglancer.

Pixi Projects

If a directory contains a pixi.toml, or a pyproject.toml with a [tool.pixi.tasks] table (and no runnables.yaml), Fileglancer generates a manifest from the Pixi configuration. Each Pixi task becomes its own runnable. The generated app:

• Sets requirements to ["pixi"].
• Uses pixi run <task_name> as the command for each runnable, with the task name as both the id and display name.
• Takes each runnable’s description from the task’s description field.
• Converts task arguments (args) into parameters: an arg with choices becomes an enum, an arg with a default carries it over, and an arg with neither is marked required.
• Carries over each task’s env variables as the runnable’s default environment variables. They are exported in the generated job script and appear on the launch form’s Environment tab, where users can override them.
• Prepends export PATH="$HOME/.pixi/bin:$PATH" as a pre_run step so the pixi binary is on $PATH.
• Derives the app name from the Pixi project metadata name, falling back to the Git repository name, and takes the description from the project metadata.
• Collects tasks from both the top-level task table and feature-specific task sections.

Tasks are skipped when they are:

• Hidden — the task name starts with an underscore (_).
• Dependency-only — the task has no cmd (it only declares depends-on).

Example

Given this pixi.toml:

pixi.toml

[project]
name = "demo"
description = "A small demo project"

[tasks.greet]
cmd = "python greet.py"
description = "Print a greeting"
args = [
  { arg = "message", default = "Hello" },
  { arg = "style", choices = ["plain", "fancy"], default = "plain" },
]

Fileglancer generates an app with a single greet runnable that runs pixi run greet, offering a free-text message parameter and a style dropdown (plain / fancy).