Gitea: Release builds don't seem to serve js/css

[silverwind]

Don't think we have an issue on this one yet:

The master release builds https://dl.gitea.io/gitea/master/ seem to have some issue serving js/css and instead serve either a 404 or redirect to /install depending on the INSTALL_LOCK setting.

I see no issue in the relevant drone steps, they do seem to complete fine and files should be generated and generate definitely runs (as part of the release dependencies):

https://drone.gitea.io/go-gitea/gitea/17228/3/3
https://drone.gitea.io/go-gitea/gitea/17228/3/4

When I run make release locally, it does produce working binaries, so I think the issue is something specific to drone. I'm not sure how to troubleshoot further without access to a drone server. I'd attempt a merge of the relevant steps like https://github.com/go-gitea/gitea/pull/9316, but drone documentation says that files are shared between steps, so it may not help.

[lunny]

In master release binary, when visit index.css/index.js it will return HTMLs. But other css/js files is normal.
So a gitea extract could let use know if we package error files or that's another reason.

[axifive]

@lunny for me this only happens on the install page. If Gitea is already installed it returns 404 for index.css/index.js/gitgraph.js

[silverwind]

For me, all webpack/less-generated files were 404. It really looks to me like drone loses build context between the steps, there seems to be no other explanation.

I'm not sure how to extract/decompile a go binary. I did try go tool objdump <binary> but it did not give any meaningful output regarding bindata.

Opened https://github.com/go-gitea/gitea/pull/9338 to experimentally combine the steps into one. I hope we can get it landed soon so I can watch the release-master job and inspect the resulting binaries.

[ashimokawa]

I had the same problem without any CI/CD, just when building gitea master for codeberg-test.org from scratch.
Then I did random things like calling make with random targets int the build dir and after a few tries the resulting binary served the files.
I know that does not help much but it smells like dependencies are broken in Makefile...

[lunny]

@ashimokawa How did you compile the source? Here is work

TAGS="bindata sqlite sqlite_unlock_notify" make build

[ashimokawa]

@lunny
From our build wrapper:

TAGS=bindata make -j1 generate build install

https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/Makefile

[lunny]

@ashimokawa please remove generate and try again. On master or future gitea 1.11, you should remove generate that has been invoked in build after all resouces generated.

[silverwind]

The presence of generate in this case should not be hindering, it's just inefficient and can be removed. In this case, generate build install will translate to roughly generate js css generate go install.

[gsantner]

For me everything seems to be broken since about 2 weeks..is this relevant for #9362 ?

[silverwind]

@gsantner your issue is a duplicate to this one. It was caused by https://github.com/go-gitea/gitea/commit/d9c67a8c903fa9927bad28f5fcb816f89f8200eb, we will have a fix soon in https://github.com/go-gitea/gitea/pull/9338.

[ashimokawa]

I have no idea why you are talking about drone/parallel/depends_on when this simply also happens by running make... But if it fixes the problem, good ;)

[silverwind]

Your issue is a different one caused by the extra generate and it looks to me that running generate build actually translates to generate js css go install (make skips the second generate it seems) which results in a invalid build. I think we should just bake-in generate into build and deprecate generate.

[silverwind]

@ashimokawa fixed your issue in https://github.com/go-gitea/gitea/pull/9338 as well, now it won't make a difference whether you run make generate build or make build.

[theAkito]

@ashimokawa fixed your issue in #9338 as well, now it won't make a difference whether you run make generate build or make build.

I was having trouble upgrading Gitea from ef798d4b8 to 6af13dbac2179c8fd2c63bcf175c04a112f8c080.

After some debugging, I found this thread and changed make generate build to make build and now it is working. Apparently, it matters which one you choose.

The problem was the following:

After doing the aforementioned, no 404s are present, anymore.

[silverwind]

make generate build may cause a wrong order of execution which leads to missing webpack files. It's best to always use make build.