News for hackers. Stuff that matters.
Re:GitLab 10.4 released by jancsika on Tuesday January 23, 2018 @11:26AM (#16214766)
I like Gitlab a lot, but I still struggle with things that shouldn't be hard.

For example: I have a single build box with a VM for linux, a VM for Windows, and one for OSX. When I commit, CI queues up the runners. Great. Except that there is some hard coded value of 1 hour after which the remaining jobs in the queue will get dropped. That means if a single job takes over an hour the remaining jobs will automatically fail, even if you up the job timeout limit. No error messages at all. Just failed jobs with blank logs.

You have to go in to a ruby configuration file and up the timeout to something big enough to accommodate your total time executing all runners, which means you must know that value in advance. Each update of gitlab kills that conf file so you have to log in and change it back and the stop/start the Gitlab instance.

Edit: clarification

Re:GitLab 10.4 released by ayufan on Tuesday January 23, 2018 @11:47AM (#16214942)
Thanks. We are aware of this issue, and we even know what is causing that, we also have ideas how to fix that. The plan is to release a fix with 10.5: https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55....

GitLab CI/CD Lead

Re:GitLab 10.4 released by jancsika on Wednesday January 24, 2018 @10:59AM (#16223646)
What's frustrating is that is a regression-- I used to be able to queue up many jobs and never got the job failures (which, again, give no error message whatsoever).
Re:GitLab 10.4 released by pault on Tuesday January 23, 2018 @11:49AM (#16214968)
I started using gitlab yesterday and during one merge request cycle I managed to lose my textfield contents several times. Keeping form contents backed up to session storage is a trivial task and it's maddening that they haven't implemented it in an area where you might be spending 20 minutes writing a comment then lose it when you change some value in a select menu. Really bad UX. Changing a merge target shouldn't require a full page refresh.
Re:GitLab 10.4 released by Snappy on Tuesday January 23, 2018 @12:29PM (#16215342)
My issue comment drafts are always persisted locally and not lost on refresh. Not sure why you're seeing otherwise. It is supposed to work that way. If you're seeing otherwise, please consider opening an issue.
Re:GitLab 10.4 released by stevekemp on Tuesday January 23, 2018 @12:47PM (#16215506)
Same here. I often force-reload issues/merge-requests because I see a popup "Press Ctrl-Enter to submit" which won't disappear, and obscures the content I'm trying to write/preview.

I've been pleased the text-content persists.