3 ms·

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

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

ayufan 9y ago
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_55320316 https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55.... GitLab CI/CD Lead
- jancsika 9y ago
  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).
pault 9y ago
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.
- Snappy 9y ago
  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.
  - stevekemp 9y ago
    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.

ayufan 9y ago

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_55320316 https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55.... GitLab CI/CD Lead

jancsika 9y ago
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).

pault 9y ago

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.

Snappy 9y ago
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.
- stevekemp 9y ago
  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.