this is probably an opinion question, but the "dep...
# community-support
c
this is probably an opinion question, but the "dependency submission" for github. Should that be based on main or a release tag. which might have the better question of "who is the consumer here", are you looking at the repo, or for the information of the final artifact. The repo might be securely up to date, but without a cut release.
v
Isn't that dependency submission API in relation to the commit SHA for which you submit?
c
it has the sha and the ref
but even so it's more on whether not you should submit every build or simply on the released build
c
its a matter of preference. We submit on every merged PR (on main/release branches), such that GitHub can check the dependency graph for security vulnerabilities (lest we have surprises closer to release).
c
with dynamic versions, boms, auto-merging and testing (even thinking about auto release)
v
I guess on every build / commit. Gradle usage example does on each push to
main
. NuGet usage example (GitHub maintained) does on each push. Go usage example (GitHub maintained) does on each push to
main
.
👍 1
c
👆its intended to be forward looking information - if it flags a CVE you’d want to know about that (and perhaps action it) before releases.
👍 1
c
I mean, you can do it safely on every push, pushes not on the default branch aren't used anyways
v
And depending on branching / working model release tags are not necessarily on the default branch, so another sign that just doing on every push on default branch is the way to go. 🙂
c
I have a ticket open about that. if the release tag is available on the default branch it should still work
but it doesn't