Seqera Platform Feature Requests

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.

We can the use the resourceLabels directive to attach labels to runs which are extremely useful for higher resolution cost tracking. A common request is to be able to see the cost of runs per user . At the moment this is impossible because the Platform does not pass the username to Nextflow. A quick win would be to set the SP username as an environment variable in the head job. This can be read by Nextflow and used as a resourceLabel tag (if the user provided the appropriate configuration)

This would allow quicker identification by eye. Proposed order of precedence: Custom icon upload via Seqera Platform UI Defined in Nextflow manifest GitHub / BitBucket / GitLab organization icon Generic Tower placeholder icon

We have a custom, managed, and standardized software stack in an EFS volume that we use throughout our organization. It includes a series of command line tools under a specific directory. We want to mount that EFS volume in a Data Studios session so all the standardized CLI tools are available to the end user. In the platform today, when creating a compute environment you can add an existing EFS volume mount. We want this same functionality at the Data Studio session level.

For each of the various container template images (JupyterLab, RStudio, VSCode), once a Data Studio session is in running state, allow users to run their local installation of the application but with the code and terminal running in the remote Data Studio session via a SSH tunnel. There is a VSCode plugin available that can be reviewed for inspiration.

Can we replace in the filename all spaces by underscores when one file is uploaded in Datasets? All nf-core pipelines expect the samplesheet not to contain any space, and except if you're fluent in regex you don't understand the error coming from the schema.

The only current method to authenticate Seqera with GitHub is using a PAT. This requires a full GitHub account, for us it means paying for an additional organization license. GitHub supports the option of using "deploy keys" that can be added at the repository level for exactly the use-case of continuous deployments. It would be great if Seqera which already supports storing SSH private keys as credentials, it could use this method to authenticate GIT pulls.

Add the ability to export the Run history of a workspace via the Seqera Platform user interface directly or via the API. I appreciate that all Runs save an execution trace, DAG and report to the specified output folder, but the nice thing about the Seqera Platform is, of course, the ability to see a history of all Runs within a workspace.

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.

We are migrating a couple of workspaces to a new organization. We like to migrate everything in the workspace, including, users, workflows, compute environment, and the history of the runs. Do you have any recommendations on how to do this? It seems that we can do most of these resources apart from migrating the history of the runs. Is there any workarounds?