News for hackers. Stuff that matters.
Re:Incident with GitHub Actions and Codespaces by dbrgn on Thursday April 14, 2022 @04:16AM (#31024464)
Don't enable unattended updates for GitLab. The migrations don't always work and sometimes need manual work. (This is rarely the case, but can happen.)

(Also, when upgrading GitLab, make sure to upgrade version-by-version and always wait for background migrations to finish before upgrading to the next version. You can check background migrations at /admin/background_migrations.)

Re:Incident with GitHub Actions and Codespaces by mindwok on Thursday April 14, 2022 @06:07AM (#31024975)
Interesting, thanks for the heads up - We didn't have any issues while I was there and probably would just restore if we needed to, but nice to know the footguns.
Re:Incident with GitHub Actions and Codespaces by dijit on Thursday April 14, 2022 @04:39AM (#31024584)
interesting, this isn't my experience. I've been running a gitlab instance for about 300 people for about 7 years now. :\

To be fair though I'm using docker and watchtowerr to keep it updated, there was 1 time where I had to use an older docker image because the latest wasn't working.

Re:Incident with GitHub Actions and Codespaces by sciurus on Thursday April 14, 2022 @08:30AM (#31026008)
For those like me who went familiar with it: https://containrrr.dev/watchtower/
Re:Incident with GitHub Actions and Codespaces by Kelteseth on Thursday April 14, 2022 @08:32AM (#31026027)
This happened to me exactly _once_ in the last three years of successful monthly update on our self-hosted GitLab instance. I got an error because the backup script expected a folder where no folder was. Updating GitLab is a breeze!
Re:Incident with GitHub Actions and Codespaces by Aeolun on Thursday April 14, 2022 @05:38AM (#31024844)
It’s incredibly dumb that it allows you to start the next upgrade before the background migrations finish.

Not unrecoverable though, so saying you need to worry about it may be a bit too alarmist.