Seqera Platform Feature Requests

There is currently a hard limitation on the file size that tower-agent can serve via Seqera Platform (3.7MB). This is a problem because many generated reports (such MultiQC) can be up to 10MB. Increasing the limit to 10MB will satisfy display of most MultiQC reports. Additionally, displaying a helpful error message for when the file size maximum is reached would be very beneficial for troubleshooting.

Update the current user role permissions to manage more fine-grained permissions (Role Based Access Control, etc).

Devcontainers is a standard format developed by Microsoft to configure development environments for VSCode and GitHub codespaces . It’s also going to be supported by GitPod . It would be great if there was an equivalent for version-controlling the configuration of Studio sessions that allows users to programmatically encode settings for Studios using a well adopted standard.

Datasets within Seqera Platform facilitate structured handling of input sample sheets required for genomics pipelines such as RNA-seq. Currently, researchers often face friction in assembling these datasets, needing to prepare CSV files externally. This could be improved by the following: 1. Improved Dataset listing: Currently, the dataset listing is relatively basic and low density. Around 6 datasets can be viewed in a typical desktop browser window size. This density plus lack of tooling hinders users from effectively navigating or identifying datasets quickly. Action: A metadata-rich table view, such as those used on the Runs page and elsewhere would be preferable. Such a table could include the dataset name, number of rows, author, creation date, last used date, and potentially the start of the description. The table will be sortable. 2. Enhanced Dataset details user interface: Currently, viewing dataset details emphasizes metadata over actual dataset content, causing users unnecessary scrolling and inefficiency. Action: Prioritizing the dataset’s actual content prominently at the top ensures users quickly verify the dataset's accuracy and completeness, reducing errors and improving productivity. 3. "Show" or "hide" a Dataset: Datasets are often used once or twice, and then no longer actively needed. For GxP/clinical environments, the dataset should not be deleted/removed, but made hidden/"deactivated". This allows inspection of the dataset, but it would be excluded from any pipeline launches. The table of datasets can be filtered to remove "hidden"/"deactivated" entries. Action: Allow datasets to be tagged as “hidden” and allow filtering of datasets to show/hide entries. 4. Keep a record of Dataset usage in Runs: Currently, it’s difficult to know if a dataset has ever been used. This makes their utility post-usage very limited. Action: With a record of Dataset usage within Run history, Datasets suddenly become a powerful tool for the user. They act as a rich history of run inputs, agnostic to the specifics of pipeline design and file usage. 7. Improve how Dataset versioning works: A user should be able to choose any dataset and version as the source of a pipeline run, and that dataset and version is displayed in the pipeline Run details page in the “Datasets” tab correctly. Additional potential milestones Integration with new Nextflow data lineage

Similar to how there are already metrics for non-GPU environments that enable users to see their utilization and make optimization decisions, add support for GPU environments as well.

When modifying a compute environment, we need to create a new one, migrate the pipelines to it, and delete the old one. However, the compute environment needs to be idle before it can be deleted. Users will often relaunch jobs without updating the compute environment, which can make it tedious to delete a compute environment. Adding an option to Disable a compute environment - in other words, to mark it so no new jobs can be started - would make this much easier. We could then create the new environment, migrate the pipelines, mark the old one as disabled, and just wait a day or two for existing jobs to finish.

On a run detail page, the menu dropdown has an option called "Save as pipeline". However, if the run was launched outside of Seqera Platform (ie. nextflow run -with-tower ) this does not work. The UI is not intuitive - an error is thrown to the browser console and "nothing happens" in the front end. Suggestion is to remove this option from the dropdown completely on such runs, and add an admonition to the docs here: https://docs.seqera.io/platform/23.3.0/monitoring/overview#save-run-as-pipeline See https://community.seqera.io/t/save-as-pipeline-requirements/375 for context.

It would be great to access non-AWS S3 bucket. The S3 API is used by many vendors, first of all Openstack swift, used by many institutes (in Italy this is the platform technology proposed by many national resources), and now by most on-premise solutions (DELL, Qumulo, VAST, etc all propose an S3 API). Being able to add any S3 compatible endpoint would be super-useful.

Users frequently request the ability to associate cloud service provider tags with workflow runs. This feature aims to annotate resources utilized by workflow runs with cloud-specific tags, enhancing cost allocation, monitoring and tracking capabilities from the cloud provider's administration console. The current limitations include the inability to add tags to Seqera Platform elements in shared workspaces. Additionally, resource labels lack parametric/dynamic behavior (such as workflowId=${workflowId} , making it challenging to track users and individual workflows for cost allocation reporting. The proposed change is two-fold: Add resource labels to items in shared workspaces. Introduction of template resource labels, allowing fixed names with flexible values at launch (e.g. ${workflowId} and ${sessionId} ). This enhancement significantly improves cost allocation tracking capabilities and management experience. Implementing these enhancements aligns the resource label system with user expectations, providing a more flexible and powerful solution for resource annotation and tracking.

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.