Wave Feature Requests

You can set up Wave Freeze to work with a private registry using Nextflow configuration, but it would make sense to include this as something configurable within the platform, perhaps joining it with the container registry credentials.

These two container URIs both contain MultiQC 1.25.1: community.wave.seqera.io/library/multiqc:1.25.1--dc1968330462e945 . (Bioconda) community.wave.seqera.io/library/pip_multiqc:0bef1f1da1c1ae8e (Pip) While the version number is preserved for the containers with tools from Bioconda, it is lacking for those from pip. This also applies for containers with multiple packages: community.wave.seqera.io/library/pip_multiqc-plugins_multiqc:5a119b172a89a538 Since there is no API that allows resolving the contained tool versions from a given URI, it is easy to lose track of them, e.g. when that container is specified in a nf-core module. Therefore, I suggest to always retain the software versions in the URI: community.wave.seqera.io/library/pip_multiqc-plugins:1.3.0_multiqc:1.2.5--5a119b172a89a538 This simplifies removing outdated images from large container caches or to consolidate Singularity and Docker images with the exact same tools. Alternatively, I propose the creation of such a public API. It could be backed by a simple key-value store, that uses the hashed URIs as keys and stores a JSON of the contained tool versions and ideally also the architecture. New entries would be added by Wave/Seqera Containers when a new container image is build.

We'd like to be able to turn those Emails off, or better filter them for the user.

Installations of the Seqera Platform more recent than v23.3.0 use Fusion v2, which requires Wave. However, many Enterprise deployments don't allow container building outside of their network nor allowing an untrusted third-party offsite service to push containers to internal repositories. This issue could be resolved by a self-hosted version of the Wave service.

Our internal enterprise requirements include the requirement for all containers running in our infrastructure to have build logs and security scan logs saved. When using Wave + Fusion, our internal ECR-hosted containers (which have build and scan logs already saved) get replaced with Wave containers. Wave containers have build and scan logs available, but they are hosted externally on the Wave server. In order to retrieve them, you must have a-priori knowledge of the Wave container build ID's and API endpoints to do a 'curl' request to retrieve the logs ( curl https://wave.seqera.io/v1alpha1/scans/<scan_id> ) . Then, the user must manually save the logs somewhere. Instead of writing our own custom code to try to automatically retrieve and store all the build and scan logs for all Wave containers used by Nextflow when running with Wave + Fusion, it would be much easier if Nextflow itself could just save them via some configurations. Consider for example the current pre-existing configuration for storing the Wave container in our ECR; https://www.nextflow.io/docs/latest/wave.html wave.build.repository = '123456789.dkr.ecr.eu-west-1.amazonaws.com/wave/build' wave.build.cacheRepository = '123456789.dkr.ecr.eu-west-1.amazonaws.com/wave/cache' it seems like we should be able to use this same method to also store the Wave logs, like this wave.logs.buildLog = 's3://my-bucket/systems/ecr/wave-logs' wave.logs.scanLog = 's3://my-bucket/systems/ecr/wave-logs' Also note that the current wave cli tool has similar capabilities; wave --freeze -i ubuntu:22.04 --build-repo 123456789.dkr.ecr.us-east-1.amazonaws.com/wave/build so I would hope this feature could also extend to that as well with something like wave --freeze -i ubuntu:22.04 --build-repo 123456789.dkr.ecr.us-east-1.amazonaws.com/wave/build --build-log s3://my-bucket/systems/ecr/wave-logs --scan-log s3://my-bucket/systems/ecr/wave-logs Also related; https://github.com/seqeralabs/wave/issues/608

Wave is used for container authentication or to enable running Fusion in pipelines. However, when Wave is enabled, the container's name reported in the task table is modified to include the hostname of the Wave service and a unique temporary token. This results in container names like " wave.seqera.io/wt/1234567890/nextflow/bash:latest " instead of the expected "nextflow/bash:latest." This may be perceived as an undesired side effect or even an error in the system. Our goal is to improve the transparency of Wave containerization. In the task table, we aim to display the expected container name for each task and provide users with the ability to inspect the associated Wave container metadata. Proposed Solution When rendering the tasks table, the system should identify the use of a Wave container and take the following actions: Remove the Wave-specific prefix and display the original container name, e.g., "nextflow/bash:latest." Introduce a visual identifier (e.g., an icon or badge) to mark the container as a "Wave" container. Make the container name a link, allowing users to access the corresponding container metadata information page. On the container metadata page, report the information presented at this reference link .