Seqera Platform Feature Requests

Seqera supports running workflows across many different types of compute infrastructure. Pipelines in some cases may have unutilised compute, which increases costs. The start up time, especially on some types of batch compute, may significantly increase. Scheduler is a multi-phased project designed to simplify compute configuration options and reduce the time and cost of running a pipeline by intelligently choosing the right configuration for a workflow and scaling the infrastructure at the correct tasks within the pipeline to remove overprovisioning or resource contention issues

Datasets are becoming increasingly available via URL links (in S3 buckets, API query results, etc). Currently, users are forced to fetch locally and add them, adding friction and wasting storage, and the original reference of the source is lost. The Datasets feature should support direct URL import/linking (and previewing).

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 version creation whenever a pipeline is created, modified, or launched with edited restricted parameters Checksum-based tracking for pipeline integrity and provenance Version Management Users with pipeline edit capabilities can assign custom labels to pipeline versions Ability to set any version as the default for launch Option to save completed workflow runs as new versions Restricted Parameter Control Users with pipeline edit capabilities can modify restricted parameters at the pipeline level Locked configurations for users with launch-only permissions to ensure controlled pipeline execution Support for custom nextflow_schema.json files to define editable parameters Version Selection at Launch Default version shown in launch form for all users Users with pipeline edit capabilities can select and launch any version Launch-only users can select from available labelled versions Commit ID Tracking Store commit IDs alongside revision information for deterministic pipeline execution Option to pin to specific commits or use latest branch updates 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.

Currently we have no way to integrate with GitHub Apps to allow for checking out of GitHub repositories. This means we need to use a full fledged GitHub account with a personal-access-token which can be a security risk as the account would only be used for Seqera Tower. This also makes us burn an organization wide account seat because of this limitation. We do not want to tie this access to a single user as we then have to update the GitHub access token after the person leaves. Please add support for GitHub Apps to checkout repositories instead of a full GitHub account + personal-access-token.

Currently, AWS Batch without Fargate and AWS Cloud CE are the only supported compute environments (CE) for Studios. Adding support for HPC environments (like Slurm) would benefit many customers who want to adopt interactive analyses within their HPC deployments.

It can be tough to quickly tell what page you are on when using Seqera Platform. Having headers displaying your place in the page map could assist. It would be great if it were easier to contextualize where you were in Seqera Platform at a glance and if there were a clearer hierarchy of menus. Also, breadcrumb navigation would be beneficial: Organization > Workspace > Participants Organization > Members Admin > Users With some colored highlighting, it might help to keep from getting lost in the menus and pages.

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

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.

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

The Seqera Platform will implement a "Generate Downloadable Support Bundle" feature on the Run Details Page that allows users to download a compressed ZIP archive containing: Nextflow execution logs Structured compute environment details (JSON/YAML format) Task logs for failed tasks Direct integration with support ticket systems and automatic ticket creation are planned for future releases. ORIGINAL REQUEST: It would be great to have a feature built directly in to the Seqera Platform that allows users to generate a support ticket with all logs attached automatically or even just a feature in the platform that a user could click to gather all relevant support logs in one zip that they can download to their system and then upload to their support ticket.