Seqera Platform Feature Requests

Currently a run-name can only be specified when using the workflow/{}/launch endpoint and not when using the action/{}/launch endpoint. As a result all runs generated using the action endpoint have randomly-generated names. This is problematic for organizations trying to integrate Seqera API into a durable execution framework such as Temporal that work best when individual activities are idempotent. Without the ability to define our activities with the logic: if not (seqera_runs.query(run_name = 'sample_id'): seqera_action.launch(run_name = 'sample_id') There is the risk that duplicate pipelines for the same sample but with different run names will be launched. The workaround is using the workflow endpoint. But this requires us to put details about the configuration profiles, pinned versions, and other details in our orchestration platform when we'd prefer to keep that just within Seqera. This ask is also mentioned as part of https://feedback.seqera.io/feature-requests/p/actions-improvements , but I thought it was worth splitting this out as a separate item when the item shifted back to evaluating, as this seems like a small change, but is essential for enabling certain types of automation.

There is quite a lot of white space in the CE list. It would be very helpful to have information such as: Resource labels Who created the CE When the CE was created (less important than the two above) This would be very helpful for customers who are struggling with CE cleanup. It is difficult to know which CEs can be deleted, and who to email/ask before deleting them.

In our Seqera Platform pipelines, we frequently work with input parameters organized by functionality. It would be helpful to have the ability to dynamically reveal or hide certain parameters based on the value of another parameter. This approach would make the interface cleaner and focus only on the parameters relevant to the current pipeline configuration. Could this be achieved by modifying something in the schema?

It would be great if datasets stored in a bucket could be added directly from a URI (otherwise, we need to download them locally and upload).

The current Launch user role permissions in Seqera Platform is problematic due to two key restrictions that the role applies (due to the inability to adjust the "Pipeline Settings" during pipeline launching). These are: the need to change Git revision (so users can compare results from different pipeline versions) the need to submit pipeline run using a params JSON instead of the Platform user interface Both of these have ended up being critical deficiencies in the Launch user role. It's become a basic requirement for even the most simple usages that all Platform users need to be able to modulate the version (Git revision) of the pipeline they are running. Also, considering the sheer number of input parameters for many pipelines from nf-core (I think the nf-core rnaseq pipeline has ~60 input parameters) the usage of the Platform Launchpad UI to manually "click-ops" through the selection of a large set of custom parameters is not feasible. Even the most basic users end up needing to resort to using the params JSON for pipeline submission, both due to the size and complexity of the input pipeline params, but also for record-keeping so that they don't have to manually click ~60+ buttons in a UI every time they want to submit a Run with a given input params setup.

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'd like to be able to turn those Emails off, or better filter them for the user.

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.

We're trying to track down an issue where our registered pipeline specs (specifically the git revision) are changing and we don't know why. I checked the audit logs, and they capture pipeline creation, but not pipeline updates. This is audit-log-worthy - which repo and what revision a pipeline runs controls what code a Nextflow user runs when they use a pre-defined pipeline, so changes to that are of interest for security reasons.

It is currently possible to set CE-level environment variables. If a workspace has multiple CEs, the variable needs to be set in each CE individually. There is also no way of changing the variable value after CE creation. A workspace-level environment variable might allow the possibility of managing a single common variable inherited by all CEs in that workspace, reducing administrative work and ensuring that all CEs have the same value for the variable.