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
it is useful to track additional metadata (text, links, etc) related to software installed on a release on the balena-cloud dashboard / within the API. for example, a call to /V6/release(XXXXX) may look like:
In this, we can only see a few main places for storing UGC (build notes, etc.) -- "known issues", "notes" and release tags. All of these correlate to the release overall, but don't provide metadata for the individual software components. Being able to track this metadata can help users track software details end-to-end thru the dashboard.
A real world example:
CI/CD may build an updated balena release, generating a release like the above payload.
When a user opens this release on the balena dashboard, it isn't trivial to determine what the actual software is. It may involve parsing the docker-compose.yml view to find the related image URL, then correlating that software with a git repo, then navigating to that repo and finding the correlated software version (by ref, etc).
Instead, the CI/CD can tag the software in the release with an API call after it generates the updated balena release, such as:
Now, that metadata (a label/url in this case) can be reflected on the dashboard to provide better end-to-end understanding of what exact software a release has:
For my team, tracking a balena release with multiple different services becomes a tricky day-to-day process, especially since we have separate versioning for the individual services plus the balena release itself. Being able to add this metadata would help our team better understand + more quickly determine the exact version and info of software running within a release.
it is useful to track additional metadata (text, links, etc) related to software installed on a release on the balena-cloud dashboard / within the API. for example, a call to /V6/release(XXXXX) may look like:
In this, we can only see a few main places for storing UGC (build notes, etc.) -- "known issues", "notes" and release tags. All of these correlate to the release overall, but don't provide metadata for the individual software components. Being able to track this metadata can help users track software details end-to-end thru the dashboard.
A real world example:
For my team, tracking a balena release with multiple different services becomes a tricky day-to-day process, especially since we have separate versioning for the individual services plus the balena release itself. Being able to add this metadata would help our team better understand + more quickly determine the exact version and info of software running within a release.
cc @rosswesleyporter
The text was updated successfully, but these errors were encountered: