Seqera Platform Feature Requests

Many users develop their Python or R notebooks, or Nextflow pipelines in VSCode, on remote EC2 instances. Once a Studio session is in a running state, users should be able to connect to the remote Studio session via a SSH tunnel to the EC2 instance with their existing VSCode/Vim/Bash environment(s). There is a VSCode plugin available that can be reviewed for inspiration.

It would be helpful to be able to shortcut from the Reports tab directly to Data Explorer, either to download a file that is too big to be downloaded from Reports or to further explore the results directory.

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.

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.

In the "About" tab of a completed task, it would be nice to have a link to launch a studio environment using the same image, and with the input data linked/copied into the environment. It would be a convenient way to quickly test different settings on a given step/tool.

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.

I tried to build a container with this Bioconda package which has been online for more than 4 months: https://anaconda.org/bioconda/esme_mpich_4_2_3 but there is an error message indicating that it is not found (whereas I can install it on my laptop with conda). I guess that the Seqera Wave database or channel synchronization may not be up to date. Can you help sort it out?

Currently in the Launchpad, when you register a pipeline, there is a Description box. We end up having to write a custom description for every pipeline for the users to read. However, we already have a README.md in every pipeline repo with similar details, and we even have external pipeline docs too. So being forced to re-write a static description here ends up with duplicated docs that can also get outdated easily. I think it would be easier if there was some way that the Launchpad could (optionally?) use the contents of the pipeline repo's README.md file and render it in the Description field instead. So we could just updated the repo's files itself and they would be reflected in the Launchpad, somehow. Or maybe the pipeline README.md could be displayed in a separate box on the pipeline's Launchpad page?

After I generate a container on Seqera Containers, there is no way to share it with a collaborator except the URI to the container image itself. Instead, it would be great to share a link to the Seqera Container page with the build details etc. This would allow other users to check the build details before pulling the image.

Although the Open API docs exist, there are no details on the fields themselves (e.g. when to use it, why to use it, what are its limitations etc) that could provide information about the nf-tower maps and their field limits and size.