5.2 Basic fkit Operations

5.2.1 Sign-In and Authentication

fkit is the authoritative interface between the local orchestration layer and the BioLine platform. Sign-in requires an AccessKey and AccessSecret. They are used only as command-line arguments to fkit login and are not written to the repository, Job directory, or parameter-override files.

Use fkit flow list --limit 1 --json for a non-interactive authentication check. Do not use a bare fkit project command as an automated probe: it opens an interactive project selector and may produce corrupted output or interfere with diagnostics in a non-TTY shell.

5.2.2 File Management

Common file operations include:

• fkit upload — Upload local data to a BioLine path.
• fkit ls — List files under a BioLine path.
• fkit download — Download required results or non-sequencing files.

Common BioLine path categories are:

• /Store/...
• /personal/<user>/...
• /open/...

5.2.3 Flow Inspection and Task Submission

Before formal submission, the system uses fkit to inspect the flow:

• fkit flow list — Find flows by keyword.
• fkit flow inspect — View flow inputs, parameters, and version details.
• fkit job create — Submit a real job.
• fkit job list, fkit job search, and fkit job get — Inspect job status.

5.2.4 Check and Update Tools with fkit

Start with fkit update NAME to inspect positive integer versions, the next version number, and the available modes, then explicitly choose a mode. fkit does not scan Flow references locally. In-place mode requires an exact NAME:VERSION; if BioLine still finds a Flow reference, its server rejects the edit, and fkit surfaces that error unchanged without retrying or creating a fallback version.

Examples:

fkit update NAME
fkit update NAME:VERSION --mode in-place --config tool.json --dry-run
fkit update NAME --mode new-version --dry-run --json

New-version mode reuses the image already stored on the server for the baseline (fkit reads the baseline path automatically and no longer uploads a local image), makes one creation request for max+1, and verifies that the version list gained exactly the expected positive integer version. --config supplies only the fields to change; it is merged into the baseline configuration and the resulting command is validated. --summary supplies the full replacement summary and defaults to the baseline summary when omitted (an empty baseline summary is rejected). Because the creation request itself carries the command and the summary, one write is normally enough. After creation fkit reads the version back; only if the server did not persist the configuration carried by the request does it send one corrective update for that just-created version — never more, never a loop. --dry-run performs local and read-only validation without remote mutation. --json prints check or operation status, where configSource reports whether the configuration came from the creation request or the corrective update, and remoteWriteCalls reports the actual number of writes (normally 1).