Seqera Platform Feature Requests

We’d love to see a “pre-flight check” feature in Seqera Platform that helps users catch common issues before a pipeline is submitted. This would improve the success rate of runs by validating key parts of the configuration and cloud environment up front. Specifically, this check could: Generate a clear, consolidated summary of the final configuration (combining Nextflow config, Platform overrides, workspace settings, etc.) Verify authentication and authorization to external resources (e.g., object storage, compute queues) Flag missing or potentially conflicting settings Suggest fixes or helpful links if something looks off This would help users answer questions like: “What credentials will my job use?” “Am I allowed to access this S3 bucket / Azure container?” “Is my configuration valid?” It could be surfaced as: A button in the UI before submitting a pipeline A CLI command (e.g., nextflow nf-launch --check) Or even integrated into the pipeline submission flow as an optional step This kind of validation would be especially valuable in cloud or enterprise environments with complex policies and configurations. It would reduce frustration, support burden, and unnecessary trial-and-error.

This project will introduce versioning capabilities to Seqera Platform, allowing users to create, save, and reference different versions of pipelines based on their configuration and parameters. Planned Features Automatic Version Tracking Automatic snapshot creation whenever a pipeline is created, modified, or launched with edited versioned parameters Checksum-based tracking for pipeline integrity and provenance All configuration changes preserved in version history Version Management Users with pipeline edit capabilities can assign custom names to snapshot versions Ability to set any named version as the default for launch Option to save completed workflow runs as new named versions Named versions can be reassigned to different snapshots Versioned Parameter Control By default, parameter changes trigger automatic version creation Custom nextflow_schema.json files can define which parameters should not trigger versioning Launch users can modify parameters and automatically create snapshots Version Selection at Launch All users see the default named version in the launch form Users with pipeline edit capabilities can select and launch any version (named or snapshot) Launch users can view and launch named versions from the pipeline details page Launch users create snapshots through parameter modifications but cannot publish named versions Commit ID Tracking Commit IDs are stored alongside branch/tag information for reproducible pipeline execution Users can pin to specific commits or update to the latest branch version Pull latest toggle sets commit ID for dynamic branch tracking Target Users This functionality is intended for bioinformaticians who customise platform pipelines for themselves or their users, applicable to all customers including Enterprise requiring pipeline execution control.

Our primary use case for the Seqera Platform involves one user setting up a workspace with preconfigured pipelines, accessible to others in the organization. We aim to preconfigure pipelines to a large extent, yet allowing for minor, user-specific or pipeline-specific customizations. If variables could be included in paths, which are evaluated at pipeline launch, a tidier directory structure accommodating many different users and pipelines would be possible. Therefore, I propose that a distinct set of variables should be supported by Seqera Platform/Tower: username , pipelinename , pipelinerevision , workspacename and date come to my mind. All are "known" to the Platform when launching a pipeline, but may not exist yet. Therefore, the respective paths must be created automatically by the agent, if not available on the HPC / cloud provider. For instance, a work directory could be preconfigured as: /path/to/a/work/directory/{{username}}/{{pipelinename}}/{{runname}} Parameter files could be specific to a pipeline revision: /path/to/a/params/{{pipelinename}}/params-{{pipelinerevision}}.json and account for changing parameters. This would streamline the management of configurations, parameters, work directories, launch directories, and outputs across numerous users and pipeline runs.

This post consolidates multiple related requests around managing pipeline run data on the Seqera Platform, specifically in the areas of log persistence and cleanup of scratch/intermediate data. Persistent Logs After Run Completion Support for archiving essential execution data — including .log, .timeline, .sh scripts, and reports — to a persistent S3 bucket (Tower-managed or user-defined). Allows run logs and metadata to remain visible in the Tower UI after work directories are deleted. Enables integration with custom lifecycle rules for scratch storage. Preserves artifacts critical for auditability, troubleshooting, and provenance. Manual Clean-Up via Tower UI ( A “Clean” action in the run details interface to: ) Trigger cleanup of intermediate files and caches (e.g., nextflow clean -l <run_name> ). Reclaim storage post-execution while retaining archived logs. Offer fine-grained control over data cleanup, one run at a time. Auto Clean-Up Option at Launch A toggle in the pipeline launch form to enable automatic cleanup when a run completes. Useful for test or debug workflows where data retention is not required. Prevents accumulation of scratch data without manual intervention. Clean-Up on Run Deletion An optional checkbox when deleting a run to also remove associated scratch/workdir data. Ensures that run deletion can include cleanup of underlying execution storage. Offers a single-step way to retire a workflow and its resource footprint. Out of Scope Automatic deletion of archived logs when a run is deleted. Cleanup functionality for in-progress or running workflows. Advanced or rule-based retention policies; current scope is limited to manual actions and simple toggles.

Currently there are two ways to launch a pipeline via the API: Populate the body of a POST /workflow/launch request , which requires getting a number of details such as the compute environment and configuration Create an action and POST /actions/${actionId}/launch , which only take pipeline params as options It would be nicer to reconcile the two and have a simpler flow: Create pipeline on Seqera Platform Launch specified pipeline using an endpoint, e.g. POST /pipeline/${pipelineId}/launch Importantly you would only be able to modify a very limited subset of options with this option, e.g. the pipeline parameters. This would save the automation developer the time and effort in writing a number of requests to GET settings before launching a pipeline via automation. The revision, compute environment, working directory, staging options and many other settings would be fixed and require addition of a new pipeline for a launch. This has some overlap with some other feature requests such as: API equivalent of this feature request

In each workflow run, there's a table of individual tasks within the "Tasks" section. Some workflow runs may involve thousands of individual processes, and enabling search and filtering by process, tag, status, and more would greatly assist users in managing and analyzing their tasks, similar to how you can search and filter the list of workflow runs. The current Task widget presents a large amount of data in a confined space. Users must navigate the table through pagination, which can be cumbersome. Additionally, the absence of sorting options in the table can prevent effective pattern recognition. To address these issues, we propose several enhancements. Firstly, we recommend incorporating an expand/collapse feature for the table, allowing users to view it in full-screen mode for a more comprehensive and user-friendly experience. Additionally, where supported, we suggest enabling sorting of table columns. Finally, we propose the implementation of a data export to csv. These improvements will enhance the user experience by providing more effective ways to manage and analyze the data associated with individual tasks within workflow runs.

Enable users to use pipeline secrets in the head node, for example in the post-run script so to enable automation and integration with 3rd party tools and APIs

In the Launchpad when launching a pipeline when the input field has a long list of options add an type-ahead option to facilitate the search for required parameters.

Similar & related: https://feedback.seqera.io/feature-requests/p/ability-to-pass-data-from-the-oidc-user-token-info-into-the-compute-pipeline-con https://feedback.seqera.io/feature-requests/p/template-resource-labels Right now, Nextflow has the built-in implicit task , workflow , and nextflow variables that provide important information inside the pipeline about the execution contexts. (docs: https://www.nextflow.io/docs/latest/script.html#implicit-variables ) This should ideally be expanded, somehow (?), to give an easy and consistent interface to metadata about the Seqera Platform execution context. So that there could be perhaps an implicit variable such as workflow.tower or tower which could include things like Run ID, User, Pipeline details, etc.. As the linked Feature Request details, this could also encompass things such as Okta auth user metadata provided by Seqera Platform. And as the other linked Feature Request details, this information would be critical for inclusion in things like resourceLabels tagging for cloud resource labels and cost tracking. Along with whatever other purposes people typically use things like workflow and nextflow variables for. If there was some easy method to pass these critical metadata values into your Nextflow pipeline, then you could also easily leverage this by making Nextflow config files that utilize these metadata's in various ways at the config-level, so you wouldnt have to actually hard-code it into your main pipeline script. And these config files could be applied at the Compute Environment level ( https://feedback.seqera.io/feature-requests/p/allow-setting-nextflowconfig-settings-on-compute-environments-or-seqera-platform ) or based on other desired criteria. I dont know what "Category" to apply for this Feature Request so please update the category here if you are able to, thanks. ----- here is a tl;dr: with a real-world use case that would be able to utilize this to put all these things together make metadata available inside the Nextflow pipeline with some magic implicit variable use those implicit variables in a config file to apply things like resourceLabels for the AWS Batch cloud resource tagging stick those config files in the Compute Environment (in Tower) so that all pipelines executed on that CE automatically get their Batch jobs tagged

In our current internally-developed system that we are migrating away from, we have two views which are very valuable to our bio-operations team: An inline module execution status display view: this shows workflow runs with integrated module status in-line, which is colour-coded. A live DAG in the website equivalent to the Seqera Platform: this shows the status of the module execution, again colour-coded according to the status of the module execution. Both of these features would really help the operations team. Ticket attachments: [Redacted for privacy]