Fix GO source vendoring

[ElXreno]

This commit fixes error like this:

CC= GOOS= GOARCH= go generate -mod=vendor -tags 'bindata pam sqlite sqlite_unlock_notify' 
go: inconsistent vendoring in /builddir/build/BUILD/gitea-1.12.1:
	src.techknowlogick.com/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt

run 'go mod vendor' to sync, or use -mod=mod or -mod=readonly to ignore the vendor directory
go: inconsistent vendoring in /builddir/build/BUILD/gitea-1.12.1:
	src.techknowlogick.com/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt

run 'go mod vendor' to sync, or use -mod=mod or -mod=readonly to ignore the vendor directory
make: *** [Makefile:518: generate] Error 1

Maybe somebody's got a better fix? I'm not sure if my decision is right because the vendor is already in the repository.

[techknowlogick]

The release targets in the makefile are useful shortcuts for the Gitea project itself for releasing Gitea via Drone. As well go modules are disabled during release steps. I am hesitant about this change as if you would like to build Gitea then the make build step is what you need to use.

[silverwind]

I think make vendor should fix inconsistent vendoring. Did someone forget to run it?

gitea/Makefile

Lines 332 to 343 in 121103f

	.PHONY: vendor
	vendor:
	$(GO) mod tidy && $(GO) mod vendor
	.PHONY: test-vendor
	test-vendor: vendor
	@diff=$$(git diff vendor/); \
	if [ -n "$$diff" ]; then \
	echo "Please run 'make vendor' and commit the result:"; \
	echo "$${diff}"; \
	exit 1; \
	fi;

[ElXreno]

@techknowlogick this pull request fixes the generation of an archive with all dependencies for offline build. It is generated, and is called as gitea-src-$VERSION.tar.gz, so I think it's required.

[ElXreno]

@silverwind Thank you for the find! I didn't even notice it once.

[silverwind]

test-vendor already runs as part of every CI job (example) and the build would fail if there were inconsistencies. So I don't think adding this to the release task is a good idea. Question is how did your vendoring get inconsistent, assuming you're building of one of our tested branches?

[ElXreno]

@silverwind To be honest, I don't know why it breaks. Everything was compiled without the Internet to version 1.11.6 inclusive. The next step was to manually re-pack the archive, pre-making a go mod vendor.
And sorry for my bad English, I may have misunderstood your question.

[silverwind]

I think the issue is that the release tasks do go get -u src.techknowlogick.com/xgo which will add xgo to the module dependencies. One way to workaround this would be to cd outside the project while installing global commands. I wonder why this doesn't fail for our release tasks.

[techknowlogick]

go get -u src.techknowlogick.com/xgo shouldn't be run when doing the release targets during drone because the docker container already has the xgo binary in it.

[silverwind]

This issue is essentially golang/go#30515.

We could potentially GO111MODULE=off go get -u src.techknowlogick.com/xgo to avoid having go touch the module files.

[silverwind]

Alternative PR: #12030