You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds a minimal lifecycle for editable, named versions of individual prompt files in Prompt repositories.
A version is created only when the user explicitly requests one. Saving an existing named version updates the Git commit referenced by that version; it does not create another version automatically. Git history continues to retain each underlying file revision.
The change adds:
A prompt_versions table keyed by prompt repository, file path, and version name.
APIs to create, list, read, and update a named prompt-file version.
Git-ref based prompt parsing so version reads resolve the commit stored by the version record.
Read/write permission checks using the existing Prompt repository permissions.
Validation for .jsonl paths and the existing single-content prompt format.
Why do we need this feature?
Prompt files currently expose only the latest default-branch content. Users need stable, user-controlled version names without generating a new managed version for every typo or save. This provides the smallest general-purpose version lifecycle while keeping existing Prompt APIs and file formats compatible.
Who is this feature for?
Users and integrations that manage prompt files in Prompt repositories and need to address named versions such as v1 and v2.
Implementation notes
A prompt is identified by repository ID plus file path; renaming a file starts an independent version sequence.
Version names are trimmed, must be non-empty, and are unique per prompt file.
Creating a version stores a Git commit reference rather than copying prompt content.
Updating a named version writes the prompt to the repository default branch and advances that version's commit pointer.
Existing prompt create, edit, list, and view APIs remain unchanged.
Local test results
go test ./component ./api/handler -run 'Prompt' -count=1
go test ./builder/store/database -run '^TestPromptVersionStore$' -count=1 -v
go test ./api/router -run '^$'
go test ./builder/parquet ./builder/temporal -count=1
make swag
golangci-lint run --new-from-rev=HEAD — 0 issues
The full repository test run passed all executed packages. Two initial dependency downloads timed out and their affected packages were rerun successfully after configuring a reachable Go proxy.
Which issue(s) does this PR fix?
N/A
Special notes for your reviewer:
This PR intentionally excludes variables, multi-role messages, version comparison, rollback, dedicated publish permissions, and business audit integration.
@helloxjade Thanks for your contribution. CSGHub support create named version for prompt repo, Is it match your case? Can you describe what is your use case in detail to help us verify this commit?
Thanks for the clarification. The existing Prompt Repo named-version feature may cover part of the use case, but the use case behind this PR is file-scoped version management.
A Prompt Repo may contain multiple prompt files, for example summary.jsonl and classification.jsonl. We want each file to have an independent version sequence, so clients can address a prompt by (repository, file_path, version).
For example:
summary.jsonl can have v1 and v2
classification.jsonl can remain at v1
Saving changes to summary.jsonl/v1 updates that named version
A new v2 is created only when the user explicitly requests it
This is intended as an editable named version/pointer for one prompt file, rather than an immutable snapshot of the whole Prompt Repo. Repository-level versions would also include unrelated prompt files and couple their version lifecycles.
If the existing Prompt Repo named-version feature already supports file-scoped version creation, version-specific reads, and updating an existing named version, then it may already match this use case. Could you please point me to the related API or implementation? I would be happy to reuse or adapt the existing mechanism instead of introducing a duplicate one.
@helloxjade Thanks for your contribution. CSGHub support create named version for prompt repo, Is it match your case? Can you describe what is your use case in detail to help us verify this commit?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this feature?
Adds a minimal lifecycle for editable, named versions of individual prompt files in Prompt repositories.
A version is created only when the user explicitly requests one. Saving an existing named version updates the Git commit referenced by that version; it does not create another version automatically. Git history continues to retain each underlying file revision.
The change adds:
prompt_versionstable keyed by prompt repository, file path, and version name..jsonlpaths and the existing single-content prompt format.Why do we need this feature?
Prompt files currently expose only the latest default-branch content. Users need stable, user-controlled version names without generating a new managed version for every typo or save. This provides the smallest general-purpose version lifecycle while keeping existing Prompt APIs and file formats compatible.
Who is this feature for?
Users and integrations that manage prompt files in Prompt repositories and need to address named versions such as
v1andv2.Implementation notes
Local test results
go test ./component ./api/handler -run 'Prompt' -count=1go test ./builder/store/database -run '^TestPromptVersionStore$' -count=1 -vgo test ./api/router -run '^$'go test ./builder/parquet ./builder/temporal -count=1make swaggolangci-lint run --new-from-rev=HEAD— 0 issuesThe full repository test run passed all executed packages. Two initial dependency downloads timed out and their affected packages were rerun successfully after configuring a reachable Go proxy.
Which issue(s) does this PR fix?
N/A
Special notes for your reviewer:
This PR intentionally excludes variables, multi-role messages, version comparison, rollback, dedicated publish permissions, and business audit integration.