Seqera Platform Feature Requests

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).

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.

We aim to improve how actions are supported in Seqera Platform, streamlining user interactions and making them more efficient. To achieve this goal, we have several objectives: Allow users to clone actions from the UI, providing a quick and convenient feature enhancement. Enable users to specify additional fields in action calls, such as the run name (supported by the API). Explore broader Actions improvements, including options for cron/scheduled hooks. Implement the ability to import/export actions as JSON, providing users an easy way to manage and share actions. Actions based on pipeline lifecycle events (start, complete, fail) These enhancements will enhance user experiences and make managing actions in Seqera platform more versatile and user-friendly.

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.

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. Remove Dataset limit: Users are currently limited to 1000 datasets per workspace. Action: Raise or remove limit 2. Dataset creation from Pipeline Launch UI: Currently, creating datasets requires users to navigate away from the pipeline launch page, disrupting workflow and causing friction. Action: Integrate dataset creation directly within the pipeline launch interface, users can seamlessly upload or enter sample data without leaving their primary task. 3. 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. 4. Keep a record of Dataset usage in Runs: Currently, it’s difficult / impossible 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. 5. 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. 6. Manual inline Dataset editing: Users currently must create or edit sample sheets externally, and upload these files to create or edit Datasets, which is inefficient. Action: An embedded spreadsheet editor within the platform would allow users to quickly and intuitively enter data and make edits directly. 7. "Archive" or "deactivate" 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 inactive/disabled/"archived"/"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 inactive/disabled/"archived"/"deactivated" entries. Action: Allow datasets to be tagged as “inactive/disabled/archived/deactivated” and allow filtering of datasets to show/hide archived entries. 8. Support for YAML and JSON formatted data: Support for non-tabular datasets (eg. arbitrary YAML and JSON) is useful for users. Action: Allow upload and editing of YAML and JSON datasets. Future potential milestones: Integration with new Nextflow data lineage

I'd like to be able to chain pipelines together within Seqera Platform, and not rely on an external service such as lambda functions to chain demultiplex => rnaseq => differentialabundance together for example

Features such as Data Explorer do not currently allow preview/download/upload for the Launch role and require at least Maintain role permissions. This FR merges all the specific requests.

We would like to build custom launch interfaces for nf-core pipelines in our Seqera Platform instance. By that I mean a restricted, minimal interface that only allows to set a minimal set of parameters while the rest is either frozen to a predefined default, or derived from these parameters. For instance, for the nf-core/demultiplex pipeline, the only thing we'd like launch users to be able to set is the flowcell ID, the filename of the samplesheet and to which project this flowcell belongs. The input and output path shall be derived from the flowcell and project ID, and other options (e.g. demultiplexer ) shall not be editable by the user. For instance, to derived the outdir from the project_id , we'd envisage something like params.outdir = "s3://some-company-namespace-${params.project_id}/demultiplex" . To achieve this, for now, we built a custom Nextflow pipeline that wraps the nf-core pipeline with a custom schema. Example . However, ideally, the same could be achieved directly in Seqera Platform. For that, I believe the following would be necessary: support for custom schemas outside the pipeline repo, see also support for custom nextflow.config outside the pipeline repo some sort of scripting to manipulate params and possibly input samplesheets (i.e. generate params and samplesheets from whatever is specified in the custom schema).

Pipeline development in Nextflow is often done using docker. When inside a VS Code environment within Studios, I want to be able to run: nextflow run main.nf -with-docker The requirement is to run fast, "local" iterations rather than requiring an external service like AWS Batch or similar, which has delays.