The repo should contain the go.mod as it was before the go generate was run. If it did then your additional go mod tidy before the go generate should do nothing.
It looks (maybe) like the wrong go.mod is in the repo. If I ensue the vjson is a direct dependency (as it is before the go generate) then the build still fails.
The corresponding GtiHub Action run will show you the failure.
So I m not convinced ATM. Also I cannot reproduce the issue locally (deleting the generated files makes and running go mod tidy either side of go generate makes no difference).
The panic you are seeing in the build failure above I do see locally.
That's due to a change in the headless-shell container that was released 13hrs ago (as I write this) so that's some sort of change/bug on their side. As yet I have no idea what's changed.
Hi Brad,
I don't believe this is the fix.
The repo should contain the
go.modas it was before thego generatewas run. If it did then your additionalgo mod tidybefore thego generateshould do nothing.It looks (maybe) like the wrong
go.modis in the repo. If I ensue thevjsonis a direct dependency (as it is before thego generate) then the build still fails.See my my commit n my fork:
https://github.com/vugu/vugu/compare/master...owenwaller:vugu:PR/fix_tests_go_dot_mod
The corresponding GtiHub Action run will show you the failure.
So I m not convinced ATM. Also I cannot reproduce the issue locally (deleting the generated files makes and running
go mod tidyeither side of go generate makes no difference).The panic you are seeing in the build failure above I do see locally.
That's due to a change in the
headless-shellcontainer that was released 13hrs ago (as I write this) so that's some sort of change/bug on their side. As yet I have no idea what's changed.