search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.39k stars 5.43k forks source link

Heatmap loads forever + Repository list fails to load entirely #10441

Closed theAkito closed 4 years ago

theAkito commented 4 years ago
Component Version
Kernel 4.19.0-8-amd64 x86_64
Distro Debian GNU/Linux 10 (buster)

Description

Web Console

TypeError: Illegal constructor. index.js:2429:20
    e index.js:2429
    c runtime.js:45
    _invoke runtime.js:271
    t runtime.js:97
    n asyncToGenerator.js:3
    s asyncToGenerator.js:25
    exports asyncToGenerator.js:32
    exports asyncToGenerator.js:21
    jQuery 2
        l
        c
Service worker event waitUntil() was passed a promise that rejected with 'TypeError: Cache got basic response with bad status 404 while trying to add request https://domain.tld/js/clipboard.js'. serviceworker.js:52:8

Screenshots

Gitea-error_20200224

jolheiser commented 4 years ago

Have you tried forcing a cache reload? Or un-registering the serviceworker and letting it re-install?

theAkito commented 4 years ago

@jolheiser No, did not try that, yet. How would I go about doing that?

Meanwhile, I got the old binary back and use this one in the new installation and all is back to normal, as long as this issue ain't fixed, yet.

silverwind commented 4 years ago

Was this built from source? Does public/js/clipboard.js exist in your source checkout?

theAkito commented 4 years ago

@silverwind

Yes. I have an update.sh that I use to update Gitea successfully since more than a year. It fetches the newest sources, gets dependencies, etc. then it builds everything from source.

Does public/js/clipboard.js exist in your source checkout?

Yes.

silverwind commented 4 years ago

Try starting up once with ui.USE_SERVICE_WORKER = false, open the page and then with true again, this should unregister/re-register the service worker.

There is a underlying bug somewhere, but I wonder if SW re-registration helps any or if the error is persistent.

theAkito commented 4 years ago

@silverwind

Well, turns out, that I changed my update.sh script and forgot to add a go get ... line. I updated most of the dependencies and stuff works now. Thanks everyone.

That said, I encounter 2 other errors when trying to fetch dependencies using go get...:

  1. https://github.com/go-kit/kit/issues/940
  2. https://github.com/influxdata/influxdb/issues/16901

I wasn't able to fix No2, because I don't know which mod/depedency depends on influxdb as a mod/depedency. Therefore I can't fiddle with the go.mod, etc. I just know the most basic stuff about Go, so maybe someone of the more experienced people here could easily solve this.

silverwind commented 4 years ago

Weird that go dependencies would cause JS errors, I don't believe it. Maybe your build was just unclean. Regarding go modules, I don't think you actually need to go get as we vendor them all inside the repo currently.

theAkito commented 4 years ago

@silverwind

So the go get ... is redundant?

Maybe your build was just unclean.

Certainly cannot guarantee it wasn't, however it never caused any remarkable issue, like this one. That said, if it was unclean, it's probably still unclean, as I didn't change the folder or anything like that. All I did was:

  1. go get ... 'ing around
  2. re-building the binary, after inability to fix the influxdb issue
  3. re-running the newly created binary

So, at least it appears to be connected to dependencies, though I wouldn't know how to confirm it.

silverwind commented 4 years ago

Regarding cleaning: Running make clean-all should get you absolutely clean minus node_modules which you can optionally delete too, so rm -rf node_modules && TAGS=bindata make clean-all build should suffice.

I'm no expert on go build, but I've been building without any go get a long time now.

theAkito commented 4 years ago

@silverwind

I've been building without any go get a long time now.

Same here. I just didn't know about the vendoring possibility.

Regarding cleaning: Running make clean-all should get you absolutely clean minus node_modules which you can optionally delete too, so rm -rf node_modules && TAGS=bindata make clean-all build should suffice.

Should this be run before every new build?

silverwind commented 4 years ago

Ideally, our make process should figure out what needs rebuilding but to avoid any potential bugs in that complex process, it never hurts to clean-all. Build will of course take a minute or two longer.

silverwind commented 4 years ago

Please close if resolved.

theAkito commented 4 years ago

Big thank you to everyone involved in helping!