Seqera Platform Feature Requests

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, creation date, last used date, and potentially the start of the description. 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. 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.

Preview is currently supported for the following file types: Nextflow output files ( .command.* , .fusion.* and .exitcode ) Text CSV and TSV PDF HTML Images (JPG, PNG, SVG, etc.) Parquet files are a very common columnar storage format for datasets and preview for this file type should be supported.

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.

We just discovered dataset names must be unique to an organization instead of a workspace. This is troublesome since we want to have dev and prod workspaces that run in parallel and have essentially the same setup, including datasets. But if the dev space has dataset project_00 then prod cannot and vice versa. Even if we combined the dev and prod workspaces so they both have access to the dataset (which is non-ideal for other reasons), we'd run into a different issue: both the dev and prod upstream processes would update the same dataset potentially allowing the dev environment to corrupt the dataset before prod uses it.

It is possible to encounter request timeouts in Seqera Platform as: ​Launching on the platform is a blocking operation There is only 1 connection to an HPC cluster over SSH permitted Creating an initial Nextflow job on a cluster may take many seconds which can lead to a timeout (this is cluster specific) If Seqera can make launching a not blocking action it may help reduce timeouts.

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

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.

AWS Batch provides some great compute resource sharing capabilities via scheduling policies and fair share job queues. This would allow within-queue job priority and resource allocation across different workflows in a compute environment. Minimal ask : for manual CEs add a parameter that defines the share identifier name . Bigger ask : for Batch Forge allow creation of scheduling policies within the job queue.

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.

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.