Generate go-licenses during tidy again

[silverwind]

We can not have the frontend target depend on golang because of they way drone is set up. Move the go-licenses generation back into tidy where it will now also be checked for consistency during tidy-check.

(I assume all main branch builds should currently fail like this).

The reasony why it shouldn't be treated the same as for example go generate is because output files are checked in. tidy is imho the optimal target to run this after.

[zeripath]

No. Do not do this during tidy.

Now that we no longer vendor dependencies we have to run make vendor EVERY TIME we check out a branch - I do not need to have go-licenses run making that checkout EVEN SLOWER.

Just make it part of generate.

[silverwind]

Now that we no longer vendor dependencies we have to run make vendor EVERY TIME we check out a branch

Why are you even running vendor at all during development? Go functions normally without a vendor directory by resolving what is in go.mod within GOPATH. I'd say you should definitely not run vendor during development and just rely on GOPATH magic. The only purpose of it is to vendor dependencies for the src release tarball.

Just make it part of generate.

That will introduce another complexity layer where we need to run go -> node -> go tools and thus require an additional step on CI, I'm against such additional complexity. I'd either run it after tidy or don't run it automated at all, it's not much work to generate licenses manually after a dependency update.

[zeripath]

Why are you even running vendor at all during development? Go functions normally without a vendor directory by resolving what is in go.mod within GOPATH. I'd say you should definitely not run vendor during development and just rely on GOPATH magic. The only purpose of it is to vendor dependencies for the src release tarball.

At least with the way vscode is set up for me I have the vendor directory.

This is highly helpful when looking for bugs & errors, otherwise when there is a bug report with a random error how do find where the problem has come from?

Without the vendor directory grep will fail to find the error. VSCode will not be able to jump directly to the affected line.

Do you suggest we grep over the whole of pkgs? How do you propose I change my way of development and bug fixing to cope with new process?

Just make it part of generate.

That will introduce another complexity layer where we need to run go -> node -> go tools and thus require an additional step on CI, I'm against such additional complexity. I'd either run it after tidy or don't run it automated at all, it's not much work to generate licenses manually after a dependency update.

The license file is a GENERATED file.

It belongs in GENERATE.

[silverwind]

Without the vendor directory grep will fail to find the error. VSCode will not be able to jump directly to the affected line.

Don't know about vscode, but in Sublime Text, I can jump to files in GOPATH just fine and I'd be surprised if VSCode can't do the same. Grepping in dependency code is probably a valid use case, but I guess you could just manually create/delete the vendor directory for such a rare purpose. Thought I do feel such a grep is something go tools should support, e.g. go mod grep akin to git grep.

It belongs in GENERATE.

May be but the conditions for regenerations are very narrow as opposed to other generated stuff, that's why I thougth we get away with this simple method of running it after tidy. Otherwise we will need to introduce another drone step just for this one task.

Anyways, I suggest we land this as a intermediate solution to unbreak main build (and all PR branches).

[silverwind]

I've removed the tidy dependency of vendor. I see no sense in having that dependency and it will enable you to make vendor without issue at any time.

[silverwind]

After latest commit, vendor now also has proper dependencies to allow make to skip it when unnecessary.

[silverwind]

I guess if we really want to be sure that the licenses are generated for branch switches (which may not run tidy) and such, we'd have to add this discussed separate target for it, so would be the go (licenses) -> node (webpack) -> go (go-generate and build) chain. It'll at minimum require 1 extra step on drone in all pipelines that build.

[silverwind]

Should be good now I think.

1. I added a workaround regarding unstable output of google/go-licenses for the top-level module, that is what @zeripath has seen as well.
2. If the vendor change breaks any workflows, I can revert it, but I think it's the right thing to do to not have it phony and with dependencies.
3. I added the dependency back to tidy because otherwise one would have to do a build to get the file updated, which they may or may not do. By hooking it into tidy, we can ensure it's up to date and verified with tidy-check.

[a1012112796]

🚀

[techknowlogick]

ping lg-tm