I know a separate Releases page was discussed in #722 and the recommended approach is a release job plus dashboard gadgets. This request is not about the UI. It is about tools that need to discover the latest release of a project hosted on OneDev without a human in the loop.

Use case

Package managers and update bots (Chocolatey AU, Scoop, winget manifests, Renovate, Homebrew livecheck, ...) all have built-in support for “latest release” on GitHub and GitLab. For a project on OneDev, each of them has to be taught a project-specific query. For example, to package tod for Chocolatey, the updater currently does this:

GET /~api/builds?query="Project" is "onedev/tod" and "Job" is "Release" and successful&offset=0&count=1
-> version, number, projectId
-> /~downloads/projects/<projectId>/builds/<number>/artifacts/windows-amd64/tod.exe

This works, but it depends on knowing that the job happens to be called Release in this project. Another project might call it release, Publish or Deploy, and nothing in the API says which builds are releases. A generic integration (“support OneDev as a release source”) is therefore not possible today.

Possible approaches (any of these would solve it)

A job-level flag such as “this job produces releases”, exposed in the builds API (e.g. a release: true field, or a query criterion like is release). A per-project setting naming the release job, readable through the API. A small dedicated endpoint, e.g. /~api/projects//latest-release, returning version, build number, tag and artifact list of the newest successful build of that job. The UI could keep working exactly as it does now (builds list and gadgets). The goal is only a stable, project-independent answer to “what is the latest release and where are its files”.

Would something along these lines fit OneDev’s design?