MBS-13488: Provide a basic health check for starting a new instance
reosarevok
Comes up, it's amazingly slow, but works, it seems
yvanzo
bitmap, reosarevok: apparently, we might have to specify the organization name too? `@metabrainz/xgettext-js`
reosarevok
Slow is probably a docker thing without search indexes and materialized tables
bitmap
hmm
reosarevok
So, it seems good?
bitmap
yvanzo: it's not published on npm (maybe we should though)
yvanzo
bitmap: I removed `yarn.lock` and ran `yarn add "@metabrainz/xgettext-js@https://github.com/metabrainz/xgettext-js#0301681a479c1796ff6850c9bd2a169074386d92"` ; and now the script works.
bitmap
oh I see, I didn't know you could do that...interesting
yvanzo
reosarevok: Slow is more probably Docker files on a slow disk.
reosarevok
That could be it too :)
Anyway, seems good to me, feel free to merge unless you want me to test specific things
yvanzo
(No search indexes and no materialized tables would just make the startup faster.)
twodoorcoupe has quit
BrainzGit
[musicbrainz-docker] 14yvanzo merged pull request #276 (03schema-change-2024-q2…perl5dot38): MBS-13358 (III): Upgrade Perl version to 5.38.2 for mirrors https://github.com/metabrainz/musicbrainz-docke...
reosarevok
No, I meant loading a big artist page is slow for example :)
Assuming your xgettext fix works for bitmap on macos too, I guess we can push that?
bitmap
it works for me (I just did `yarn remove xgettext-js` first instead of `rm yarn.lock`)
bitmap, reosarevok: Might it actually be a bad idea to specify the organization name if it supposed to replace an existing package?
outsidecontext
lucifer: I tried the windows package for the LB app you shared yesterday. that one does not run for me. there are actually two problems:
1. the installer exe itself is not code signed, so windows complains. I see code signing got set up, maybe it is just signing the contained app?
2. the installer fails with a NSIS Error: Installer integrity check has failed. This is on Windows 11. I see aerozol had also tried and it seems to have worked for him, so not sure where the difference is. I tried downloading multiple times to rule out bad / incomplete download
bitmap
yvanzo: it would affect the imports, at least, AFAIK
I'm not sure if it's an issue besides that...
reosarevok
It consistently fails with that error, anyway
monkey
lucifer: I also tried installing the LB DMG on mac, it's working fine with no issues
On a separate note, I'm getting 500 errors when loading any artist page on beta and test, but working fine in production. The error looks odd and is not code that has been modified since last prod deployment: https://www.irccloud.com/pastebin/I7YeVNHh/
Wondering if you have an idea of what's going on there
BrainzGit
[musicbrainz-server] 14mwiencek merged pull request #3243 (03schema-change-2024-q2…mbs-11962): MBS-11962: Update privileges for all database users on schema changes https://github.com/metabrainz/musicbrainz-serve...
yvanzo
reosarevok: which branche[s]?
reosarevok
The xgettext one
yvanzo
on your bare system?
reosarevok
Yes
yvanzo
It doesn’t resolve the initial error in CI test to start with.
bitmap
for some reason the postgres-jimmy container was missing barman's pubkey, so no base backup was made recently (leading to many WAL files being stored). fixed that and started a new base backup (which I need for testing anyway)
yvanzo
It doesn’t have anything to do with the organization name, it is something else.
It seems to be rather related to the compression level.
bitmap
when I extracted the (different) cached packages, the contents were different for me
monkey: any PRs to merge, will do a release. the beta/prod difference is because i deployed fixes directly to prod.
BrainzGit
[listenbrainz-server] 14amCap1712 merged pull request #2865 (03master…popularity-recording): LB-1563: add API endpoints to retrieve total listen and listener count https://github.com/metabrainz/listenbrainz-serv...
(Which I tried to using `corepack install -g yarn@4` but compilation still fails using Yarn 4.0.1.)
bitmap
yvanzo: for me it actually downloaded the non-forked package from npm (so it's no surpsise the hashes were different in that case)
yvanzo
Same but I’m trying to make it work in CircleCI tests too.
See the latest link: “If there is no Known Good Release for the requested package manager, Corepack looks up the npm registry for the latest available version and cache it for future use.”
bitmap
so IIUC, on CircleCI it's downloading the correct fork from github, but the hashes still differ due to the package manager not being specified?
nvm I misread your text
yvanzo
We actually specify `"packageManager": "yarn@4.0.1"`in our `package.json`.
So that’s probably not related. Just trying to find a cause or at least a solution.
but rerunning an new instance takes just a few seconds :)
bitmap
right, thanks :)
yano joined the channel
yvanzo
I modified package.json and yarn.lock to match my previous patch but it still fails.
bitmap
I'll have to trigger a new build anyway, because it doesn't have my ssh key
yvanzo
K
bitmap
that's weird though: Using Yarn Classic for bootstrap. Reason: "__metadata" key not found in yarn.lock, must be a Yarn classic lockfile
I thought we regenerated the lockfile after switching to Yarn v4
oh that's referring to the xgettext-js source
it looks like CircleCI is doing the correct thing (downloading the fork, which I verified by extracting the archive), so I think the current hash in the lockfile is correct