Release builds don&#39;t seem to serve js/css #4477

@lunny commented on GitHub (Dec 12, 2019):

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.

@lunny commented on GitHub (Dec 12, 2019): 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.

GiteaMirror commented

@axifive commented on GitHub (Dec 12, 2019):

@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

@axifive commented on GitHub (Dec 12, 2019): @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

GiteaMirror commented

@silverwind commented on GitHub (Dec 12, 2019):

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.

@silverwind commented on GitHub (Dec 12, 2019): 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.

GiteaMirror commented

@ashimokawa commented on GitHub (Dec 13, 2019):

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...

@ashimokawa commented on GitHub (Dec 13, 2019): 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...

GiteaMirror commented

@lunny commented on GitHub (Dec 13, 2019):

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

TAGS="bindata sqlite sqlite_unlock_notify" make build

@lunny commented on GitHub (Dec 13, 2019): @ashimokawa How did you compile the source? Here is work ``` TAGS="bindata sqlite sqlite_unlock_notify" make build ```

GiteaMirror commented

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

@ashimokawa commented on GitHub (Dec 13, 2019):

@lunny
From our build wrapper:

TAGS=bindata make -j1 generate build install

@ashimokawa commented on GitHub (Dec 13, 2019): @lunny From our build wrapper: `TAGS=bindata make -j1 generate build install` https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/Makefile

GiteaMirror commented

@lunny commented on GitHub (Dec 13, 2019):

@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.

@lunny commented on GitHub (Dec 13, 2019): @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.

GiteaMirror commented

@silverwind commented on GitHub (Dec 13, 2019):

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.

@silverwind commented on GitHub (Dec 13, 2019): 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`.

GiteaMirror commented

@gsantner commented on GitHub (Dec 15, 2019):

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

@gsantner commented on GitHub (Dec 15, 2019): For me everything seems to be broken since about 2 weeks..is this relevant for #9362 ?

GiteaMirror commented

@silverwind commented on GitHub (Dec 15, 2019):

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

@silverwind commented on GitHub (Dec 15, 2019): @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.

GiteaMirror commented

@ashimokawa commented on GitHub (Dec 15, 2019):

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 ;)

@ashimokawa commented on GitHub (Dec 15, 2019): 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 ;)

GiteaMirror commented

@silverwind commented on GitHub (Dec 15, 2019):

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 commented on GitHub (Dec 15, 2019): 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`.

GiteaMirror commented