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

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.

I am trying to record, track, and modify the state of my Seqera Platform instance. Its proven to be extremely difficult to adequately write out descriptions of all the settings and configurations I end up using in a simple README.md file. I have started resorting instead to the export and update functions of the CLI, such as: tw compute-envs export --workspace 1234567890 --id AbcAbcAbc > My_dev_CE_AbcAbcAbc.json tw participants list tw participants update ... tw workspaces list tw workspaces update ... tw pipelines list tw pipelines update ... While the CLI tool is invaluable for the ability to do all this Seqera Platform management from the cli, and in a potentially scripted manner, ultimately what I actually need is the ability to export all of the "configurable" components of Seqera Platform to a file, update that file as needed, and then upload it back to Seqera Platform to apply the changes. Essentially I think what I need is "Terraform for Seqera Platform", or something to that effect. Some way to not just manipulate individual aspects of the Platform but to also snapshot all of its configurations to a file that can be tracked in version-control, manipulated outside of Platform, and then used to apply the needed configuration changes to Platform. This would also have the benefit of allowing you to see the entire state of the Platform at once, instead of having to pull out single attributes one at a time. At a bare minimum, some sort of export all + import all in a YAML or JSON would help. Let me know what you think, thanks.

AWS will be phasing out support for F1 FPGAs in the very near future in favor of purely supporting F2 instances. However, F2 instances do not benefit from the automated AWS configurations that Batch Forget provides. It would be convenient to have these instances configured automatically via Batch Forge.