Conversation
…t versions are created after updates
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
src/main/java/io/seqera/tower/cli/commands/pipelines/versions/ListCmd.java
Outdated
Show resolved
Hide resolved
src/main/java/io/seqera/tower/cli/commands/pipelines/versions/ListCmd.java
Outdated
Show resolved
Hide resolved
...n/java/io/seqera/tower/cli/responses/pipelines/versions/ListPipelineVersionsCmdResponse.java
Show resolved
Hide resolved
src/test/java/io/seqera/tower/cli/pipelines/PipelineVersionsCmdTest.java
Outdated
Show resolved
Hide resolved
…versioning-support
tcrespog
left a comment
There was a problem hiding this comment.
Tested and worked successfully.
| // - Server already named it (fixed API) → just report it. | ||
| // - Unnamed draft + --allow-draft → report draft ID, let user manage it manually. | ||
| // - Unnamed draft (default behavior) → auto-generate a name, assign it, and promote to default | ||
| // (mirrors the frontend naming algorithm from version-name-resolver.ts). |
There was a problem hiding this comment.
I think there's no need to reference the explicit file name where the algorithm is supposedly implemented here.
|
|
||
| /** | ||
| * Names an unnamed draft version and promotes it to default. This mirrors the frontend's | ||
| * behavior in version-name-resolver.ts: derive an incremental name from the current default |
There was a problem hiding this comment.
Similar comment about referencing explicit file names in another project.
| // Query published versions and find the one marked as default. We use the published filter | ||
| // because draft versions should not be considered as the "current default" for naming. | ||
| ListPipelineVersionsResponse versionsResponse = pipelineVersionsApi() | ||
| .listPipelineVersions(pipelineId, wspId, null, null, null, true); |
There was a problem hiding this comment.
Given that all published versions are retrieved here, there would be an edge case with the max page size on the server side (although it is large) in case the default version is not found in the first page. Anyway, can't we assume the default version if the launch.id attached to the pipeline? Isn't that what determines that the version is the default one?
| * Strips trailing -{number}, increments (or starts at 1). | ||
| * E.g., "pipeline-3" → "pipeline-4", "rnaseq" → "rnaseq-1" | ||
| */ | ||
| public static String generateNextVersionName(String baseName) { |
There was a problem hiding this comment.
This method seems to be used only here and for testing: it might be worth making it protected or package-private (no access modifier).
Summary
pipelines versionssubcommand group (list,view,update) to manage pipeline versions--version-id/--version-nameinto existing commands:pipelines view,pipelines export,pipelines update, andlaunchpipelines addgains--version-nameto name the initial version on creationpipelines updatedetects when a versionable field change creates a new version: auto-generates a name (mirroring the frontend naming algorithm), assigns it, and promotes it to default. Use--allow-draftto skip auto-naming and keep the new version as an unnamed draft for manual management.pipelines viewdisplays version info (name, default flag, hash) when a version is specifiedpipelines exportincludes the version name in the exported JSON so it survives import round-tripspipelines labelscommands into alabels/sub-package mirroring theversions/structureTest plan
./gradlew test— all unit tests passTOWER_CLI=./build/native/nativeCompile/tw ./gradlew test— all unit tests pass in binary modeTesting guidelines
Setup
Test 1: Create pipeline with initial version name
Verify: Pipeline is created successfully.
Test 2: List versions
Verify: All list variants return v1.0 as the single published version.
Test 3: View version by name and by ID
Verify: Both show version details (ID, name, hash, default flag, creator, timestamps).
Test 4: View pipeline with version targeting
Verify: The first two show Version Name, Version Is Default, and Version Hash rows. The third (no version) omits version info.
Test 5: Update non-versionable field (no new version)
Verify: Output says "Pipeline updated" without any new version message.
Test 6: Update versionable field (auto-names and promotes new version)
Verify: Output says "Pipeline updated" followed by "New version 'v1.0-1' created and set as default, available in the Launchpad." (name is derived from the current default version name).
Test 7: Confirm auto-named version appears in version list
Verify: Two published versions shown — v1.0 and v1.0-1 (or similar). The new one is marked as default.
Test 7b: Update versionable field with --allow-draft (keeps unnamed draft)
Verify:
DRAFT_IDis a non-null version ID. Output includes "New draft version created" message.Test 8: Rename draft version
Verify: Version updated successfully.
Test 9: Set version as default
Verify: Version updated successfully.
Test 10: Update a specific version by name
Verify: Pipeline updated without creating a new draft.
Test 11: Export with version targeting
Verify: The first two include
"version": {"name": "v1.0"}in the JSON. The third (default version) omits the version field.Test 12: Export + import round-trip
Verify: Imported pipeline exists and can be viewed.
Cleanup