Seqera Platform Feature Requests

Co-Scientist's git connection currently only accepts GitHub personal access tokens. Teams whose code lives in GitLab can't connect their repositories, so they can't point Co-Scientist at their own pipelines. The request is to add GitLab support (personal access tokens, including self-hosted instances) so GitLab users get the same connect, clone, read, and push experience that GitHub users have today. Ideally this builds on the git credentials users already store in Seqera Platform, which supports GitHub, GitLab, and Bitbucket. Reusing those credentials would give Co-Scientist multi-provider support without a separate token flow per provider, and would extend naturally to Bitbucket as well.

When launching a pipeline, some parameters depend on the value of other parameters (e.g., selecting a genome assembly should filter available annotation files, or selecting a project should populate available sample lists). Currently, all parameter values must be statically defined in the schema. Add support for dynamic parameter lookup — where selecting a value in one field triggers an API call or lookup to populate dependent fields — so users see only valid, context-appropriate options without manual entry.

This page: https://docs.seqera.io/platform-enterprise/enterprise/advanced-topics/manual-aws-batch-setup#create-the-batch-compute-environments suggests that graviton support is not possible in a manual CE setup. Is there any plan for this to be possible (and why is it not?), as we would be interested in swapping to graviton in the future.

I want to copy the co-scientist provided answer in a nice way. I can highlight the text, but it copies the (dark mode) font colors and the layout gets messed up when I try and paste into a third party system like Microsoft Teams.

I want to be able to share chat links with other people in my organization.

I'm in the process of moving data to a different storage location, and it would it be nice to bulk export a set of samplesheets

We’d love to see Seqera Platform support cloud identity passthrough, allowing pipelines to securely access cloud resources (like storage, compute, secrets) using native identity mechanisms from AWS, Azure, and GCP — without needing to manage long-lived credentials. (Seqera Platform already supports this for HPC). This would allow access to cloud services to be governed directly by cloud IAM policies, improving both security and enterprise integration. Why this matters Today, jobs typically authenticate to cloud services using infrastructure-level credentials (e.g., an IAM role or service principal attached to the compute environment). These credentials are: Shared across users Often over-permissioned Not user-aware — cloud services can’t tell who requested access This limits enterprises from applying their existing IAM policies and can create operational or audit complexity. ✅ What we’re asking for Enable Seqera Platform to support cloud-native, credential-less authentication, such as: AWS: IAM Roles with identity federation (e.g., via IAM Identity Center or OIDC) Azure: System- and user-assigned Managed Identities GCP: Workload Identity Federation tied to user or workspace context This would allow: Per-user or per-pipeline IAM role/identity selection Fine-grained access controls to cloud resources, managed entirely in the cloud provider’s IAM system Removal of static secrets (like service principal keys or access tokens)

Currently there are two ways to launch a pipeline via the API: Populate the body of a POST /workflow/launch request , which requires getting a number of details such as the compute environment and configuration Create an action and POST /actions/${actionId}/launch , which only take pipeline params as options It would be nicer to reconcile the two and have a simpler flow: Create pipeline on Seqera Platform Launch specified pipeline using an endpoint, e.g. POST /pipeline/${pipelineId}/launch Importantly you would only be able to modify a very limited subset of options with this option, e.g. the pipeline parameters. This would save the automation developer the time and effort in writing a number of requests to GET settings before launching a pipeline via automation. The revision, compute environment, working directory, staging options and many other settings would be fixed and require addition of a new pipeline for a launch. This has some overlap with some other feature requests such as: API equivalent of this feature request

Problem / motivation Creating a Google Cloud compute environment (the single-VM google-cloud type, which is the only GCP CE that Studios supports) requires the provisioning credential to hold resourcemanager.projects.setIamPolicy - i.e. the "Project IAM Admin" role. Several customers consider this too broad to grant, since whoever holds it can bind any role to any principal across the whole project. There is currently no way to provision this CE type without it. for exactly this reason. Current behavior The google-cloud CE is always Forge-provisioned ( isForgeEnv is unconditionally true). During creation, Forge: Creates a new, per-CE service account ( iam.serviceAccounts.create ). Grants it roles/storage.objectAdmin on the work-dir bucket (bucket-level setIamPolicy ). Edits the project IAM policy to grant that SA four roles — logging.logWriter , monitoring.metricWriter , storage.bucketViewer , storage.objectViewer — which is what requires resourcemanager.projects.setIamPolicy . The same project-level setIamPolicy is invoked again at teardown to remove the bindings before deleting the SA. GoogleCloudConfig.serviceAccountEmail exists but is an output (populated by Forge), not an input — there is no path for a user to supply an existing SA and have Forge skip steps 1 and 3. Code (platform/master): modules/platform-compute-platforms/impl/src/main/groovy/io/seqera/tower/service/platform/gcp/GoogleCloudForgeClientImpl.groovy — createServiceAccount L392; project setIamPolicy L520; removal L570 .../service/forge/GoogleCloudForgeDelegate.groovy — isForgeEnv L125; serviceAccountEmail set from Forge result L68 Requested behavior Add an option on the Google Cloud (single-VM) CE to use a customer-provided service account instead of creating one. When a service account is supplied: Forge skips SA creation and skips the project-level IAM policy edit. The customer is responsible for pre-granting that SA the required roles (we document the exact set). Provisioning then only needs permissions to attach the existing SA to the VM, not resourcemanager.projects.setIamPolicy . This mirrors how the Google Batch CE already behaves — it reuses the credential's own service account ( GoogleBatchPlatformProvider.groovy:717 ) and never touches the project IAM policy. Acceptance criteria A google-cloud CE can be created with a user-supplied service account and no use of resourcemanager.projects.setIamPolicy at create or delete time. When no SA is supplied, behaviour is unchanged (Forge creates and binds as today), so this is backward compatible. Docs list the exact roles the supplied SA must already hold. Teardown does not attempt to remove project bindings it did not create. Notes / scope This is the CE that GCP Studios runs on; there is no GoogleBatchStudioProvider , so customers can't sidestep it by switching CE type. setIamPolicy is inherently project-scoped, so a narrower-scope grant is not possible — a BYO-SA path is the only way to remove the requirement.

I've noticed a recurrent error when running many workflows/jobs at the same time. AWS ECS seems to have trouble supporting pulling large numbers of containers from AWS ECR. When this happens, the AWS job fails (and doesn't retry) killing the workflow and reporting this error: Caused by: Task failed to start - CannotPullContainerError: context canceled Discussing with AWS support and they suggested that the job definition should be updated to include something along the lines of: > Sometimes this error could also be caused due to intermittent network connectivity issues, registry related issue when the ECS Agent/Docker Daemon is not able to connect to the registry and pull the image onto the host instance successfully. You can workaround this error by using the "Retry Mechanisim" in your job definition. Example: ********** "retryStrategy": { "attempts": 5, "evaluateOnExit": [ { "onStatusReason": "Host EC2*", "action": "RETRY" }, { "action": "RETRY", "onReason": "Task failed to start" (You can change the "onReason" statement as per error) }, { "onReason": "*", "action": "EXIT" } ] } ********** Is this something that can be updated in a future release so when the platform creates job definitions workflow don't fail due to not being able to pull a container and instead retries the container pull at least once?