Closed lseppala closed 2 years ago
It links to the directory and not the go.mod file itself?
@pcarlisle
It links to the directory and not the go.mod file itself?
Yes. My first thought was to link to the go.mod file. My reasoning against it was that linking to the the go.mod file gives the impression that it's tied directly to the go.mod file (that is, the versions come from the go.mod file itself). The directory seemed a good option because that's where the go
commands are run from. Happy to hear alternative arguments
Isn't the only (or at least primary) significance of the directory that it contains go.mod? I even see us making that check in the code. It's true that we aren't just transcribing versions from that file, but it is the source that we start with to derive our versions. I think we communicate that in the ui (at least for now text will say "associated with go.mod" for the snapshot).
Maybe the best argument is that go.mod is still the place someone needs to update to see a change the results.
Maybe the best argument is that go.mod is still the place someone needs to update to see a change the results.
@pcarlisle this is a good argument that this is where the user can take an action. Updated!
I think the failing build is due to switching over to publish the toolkit on npmjs.com. This one may need to merge first to pass: https://github.com/actions/go-dependency-submission/pull/21
Merged #21 and merged in main
, build now passes :tada: merging
This will create a link in Dependency Graph that links to the directory containing
go.mod
and all build targets.