Seqera Platform Feature Requests

Once connecting VScode studios to a local VSCode IDE is possible via SSH tunneling, there are different potential user flows how to most easily connect to the running studio session. One very user-friendly and easy way could be to add a studio session view into the Nextflow extension for VSCode that shows running VScode studio sessions and lets a user connect to it via clicking, similar to Gitpod ( https://www.gitpod.io/docs/gitpod/editors/vscode ). This request relates to SSH connection to a running studio .

Now that Wave is using Postgres as its backend, it would be nice to be able to consolidate down to one database. Support for using Postgres in Nextflow Tower would allow us to consolidate a bunch of our infrastructure - it's one of our only apps using MySQL/Maria

Seqera Platform won't accept Docker images that have an ENTRYPOINT . Nextflow itself (on my laptop) successfully ignores a hardcoded ENTRYPOINT and runs the Nextflow task bash script. Our devs stumble over this from time to time and can't debug the issue without help from one of our NF experts. Additionally, this slows down our transition from other workflow runners that require an ENTRYPOINT . Would it be possible to have Seqera Platform also ignore hard-coded ENTRYPOINTs? Currently we make an extra Dockerfile and image like this: FROM <other image> ENTRYPOINT [] This leads to confusing clutter in our repos and artifact store. I hear that one cannot use the workaround of setting a container option with an empty entrypoint because of an incompatibility with Fusion

Currently Seqera only supports OIDC. We would prefer using a SAML2 based IDP so that we can take advantage of the SCIM features.

Similar to Ken's request [1] - but for users who might need to use a custom AMI that already has aws cli installed, they would need to modify the launch template to remove the Batch Forge commands which reinstall the aws cli. To go beyond simply appending to the launch template, it would be helpful to give users the option to specify an existing custom launch template. This would mirror the approach we currently provide that allows users to provide the IDs for existing IAM roles during Batch Forge CE creation. [1] https://feedback.seqera.io/feature-requests/p/more-flexibility-in-tower-forge-ability-to-add-lines-to-launch-template

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

We've always had to create service account keys for authentication of workloads against Google Batch/GLS. This isn't ideal due to service account keys being highly sensitive credentials, and the difficulty in rotating keys and updating them in Seqera Platform / Tower. I'd love to see Seqera Platform offer support for Google's Workload Federated ID, which will mean no longer having to create service account keys and upload them as credentials. I see you are rolling out something similar for Azure Entra (beta) in Seqera Platform? This will allow us to continue to adhere to SecOps best practices, and ensure the risk of leaked keys is kept to a minimum.

GCP has a new feature designed for AI/ML use, zonal buckets, which promise lower read/write latency but are pinned to one specific zone. We can accomplish this by adding a clause to the nextflow.config override for the compute environment, but it would be good to be able to just set this on the compute environment directly.

It would just be nice to have code or code-like elements in the HTML font to use monospaced fonts. Thanks!

Currently we have to run GET against individual workflows which can saturate the API. It would be more efficient to run batch requests, e.g. instead of for workflowId in workflows: GET workflow/${workflowId} We could do: GET workflowsBatch?workspaceId=12345678?params=["abcd", "efghi"] This would reduce API burden and not hit rate limits. This could also go for other endpoints, e.g. participants, pipelines etc.