On 7/30/2021 at 1:36 AM, MrSqueak said:

Hello,

 

On June 22, 2021 Gitlab updated from major version 13 to 14. When starting the docker the logs say that I need to update to the newest major version and then it shuts down the image. I could possibly manually update within the image but I cannot get the image to stay up past logging that I need to update. I would appreciate any suggestions that could get me through this as this is my only source control that I am currently using. Thanks!

Hello. You need downgrade your version on 13.9.2. Then you need upgrade gitlab version step by step  13.9.2 -> 13.12.6 -> 14.0.5 -> 14.1.0 -> latest

How can I downgrade the docker container ? I tried the command in the terminal: docker pull gitlab/gitlab-ce:13.9.2-ce.0

On 7/31/2021 at 10:09 AM, ScratchCat said:

Hello. You need downgrade your version on 13.9.2. Then you need upgrade gitlab version step by step  13.9.2 -> 13.12.6 -> 14.0.5 -> 14.1.0 -> latest

 

3 hours ago, andre4k14 said:

How can I downgrade the docker container ? I tried the command in the terminal: docker pull gitlab/gitlab-ce:13.9.2-ce.0

On 7/31/2021 at 4:09 AM, ScratchCat said:

 

You do that by editing the docker template page. Goto the DOCKER tab, click on Gitlab-CE and select "Edit"

 

 

Locate the field labeled Repository. It should be set to gitlab/gitlab-ce:latest

 

 

This is what controls what version of Gitlab-CE you are using.

 

A quick breakdown of the components of this string is:

 

gitlab: user on dockerhub

gitlab-ce: name of the repository

latest: version

 

To change it to something else, first find out what the official tags are from the dockerhub page for that project here.

 

Click on the Tags tab and search for the version that you want. For example, 13.9.2, would correspond to 13.9.2-ce.0

 

 

Now enter that version instead of latest in the Repository field of the Gitlab-CE docker template:

 

Repository:   gitlab/gitlab-ce:13.9.2-ce.0

 

Hope that helps!

Edited August 15, 20214 yr by frakman1

Thank you, you made my day.
May the Force be with you

So what's the default username/password to use for a new install? And where exactly is that documented, just curious to see why I had trouble finding it.

On 8/26/2021 at 11:50 AM, Adrian said:

So what's the default username/password to use for a new install? And where exactly is that documented, just curious to see why I had trouble finding it.

Had a similar issue, I fixed it this way...

 

Run this command in the gitlab docker CLI (not unraid CLI):

gitlab-rake "gitlab:password:reset[root]"

 

This will start the password reset process for root.

After testing, I try to explore gitlab deploy for my cloudways php apps and after generating the SSH Key, uploading them and deploying the app, I got the stuff I need and it's indeed one interesting platform to surf. Thanks for the headsup and for opening the tab. Highly appreciated! 

On 8/28/2021 at 7:13 AM, tjb_altf4 said:

Had a similar issue, I fixed it this way...

 

Run this command in the gitlab docker CLI (not unraid CLI):

gitlab-rake "gitlab:password:reset[root]"

 

This will start the password reset process for root.

 

Just got back in town, thank you! this worked.

Leaving this here for anyone else who may have similar issues:

 

After moving the appdata folder (due to changing cache drive setup) and copying data across, my GitLab-CE was crashing unraid server randomly. On my previous hardware it would hard lock up and become 100% unresponsive. My new hardware would detect the hard lock and auto restart the server causing a parity recheck due to unclean shutdown. By the end it was crashing the server in less than 5 minutes of the docker container active.

 

The fix was to start the container and execute the below command from the unraid terminal:

sudo docker exec GitLab-CE update-permissions 

 

Container is working fine without crashing. Additionally the issue was likely caused by a recursive permissions command run in the wrong folder. Because of this running New Perms or Docker Safe New Perms from the tools page before the above command is a good idea.
 

Edited October 6, 20214 yr by firetime

I wonder if that will work for my Nextcloud docker. Hmmm

Hi Guys !

After the latest update, my GitLab-ce won't boot anymore 😭
It launch, take it's time like always and progressively take memory, but never it is accessible again by the WebUI/DNS
It respond to ping but that's all...

Please, help ! I'm developping a website+app for my own brand new company and all the projects are on it 😱

 

I'll gladly share any more log you'll need, but it seems to have a lot, just tell me the one that can help please 😇
Attached is a copy/paste of the log windows in unraid GUI.

 

Thank you very much !

P.S. : If it's more convenient to redo a docker and import the DB (is it even possible ? My projects are not totally lost ?), no problem ^^

 

GitLab-ce logs.txt

 

Edit SOLVED :

Back online again !

Phew~~ 😌

 

That was a problem with external_url param.

With some little changes and a downgrade/upgrade, all working again, thanks nonetheless

Edited December 5, 20214 yr by AinzOolGown
Solved

Hi @AinzOolGown

In my case I faced a problem with my gitlab-ce docker installation during updates because:

1) no autoapdates, and

2) I did not follow the update path recommended by gitlab.

 

When I manually updated, it jumped from a very old version to latest. The container was not starting because db was failing; I think the db upgrade scrips failed.

 

So I manually updated step by step, using specifically the respective tags in the docker, based on this info below:

https://docs.gitlab.com/ee/update/#upgrade-paths

 

This resolved the issue.

Maybe this is already common knowledge for many, but I hope it helps someone failing like me...

 

-a

 

 

 

Fresh install. Somehow I cant access the webui on the https port. The default http port works fine.

Bug or something with my setup, i cant figure out.

Edited December 5, 20214 yr by KrisMin

I am using this Gitlab with Hotio's Caddy2 (for serving) and ddclient (for ddns).  I have many other projects that work fine, but for some reason, Gitlab will not accept the external_url. 

 

I change the external_url to 'https://git.SITE.COM' and run gitlab-ctl reconfigure.  When I try to go to the external site, I get a blank page. 

 

If I comment it out, everything appears to work fine until I start using Gitlab... I will get 500 errors anytime I try to import a project and when I go to clone projects, The address is localhost instead of SITE.COM.

 

I am obviously improperly configuring Gitlab, but I am not sure what I am doing wrong.  Any assistance would be greatly appreciated.

 

- Caddy2 Config -

git.SITE.COM {
    reverse_proxy 192.168.1.7:9080
    encode gzip
    log {
        output file /config/log/git-SITE.log
    }
}

 

I've left all Gitlab configs default.

I had a similar problem with localhost URL instead of my actual server when I clone.

 

In the docker template page in Unraid, I had to add the external_url parameter to Extra Parameters and set it to my Gitlab WebUI IP:PORT. In your case, you may want to change it to your actual site URL.

 

--log-opt max-size=10m --log-opt max-file=1 --env GITLAB_OMNIBUS_CONFIG="external_url 'http://MY-UNRAID-IP:9080/'; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;"

 

I use NginxProxyManager to manage the internet-facing URL.

frakman1,

 

Edit: That didn't work....

 

I added two variables on the configure page;

 

"log-opt" with a value of  max-size=10m

 

and

 

"env" with a value of  GITLAB_OMNIBUS_CONFIG="external_url 'https://git.MYSITE.COM/'; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;"

 

So, question... should I use the IP address of my unraid server or the actual url I am expecting to work?  and do I include the https if I am using the url?

 

Didn't seem to respond to that.  I am still getting 500 errors on imports and other weird things.  Of note, the gitlab.rb didn't seem to change either.

 

Edit 2:

Another thing I noticed is the logs are going wild.  I get about 40 lines every 3 to 4 seconds.  Mostly puma, sidekiq and gitaly.  It's going so fast that I can't even see if my requests are hitting the logs. (but it doesn't appear to be)

Edited December 7, 20214 yr by xer01ne

Unfortunately, I'm not sure I can help with your specific setup as I have it configured very differently.  I use Cloudflare for my DNS and Let's Encrypt for the SSL certificate management within  NginxProxyManager. You may need to map my logic to your specific setup. 

 

After some trial and error, I was able to get the external URL to work with SSL and have the Clone button in my repo point to the external URL instead of the local IP address:

 

Browser Location bar:

 

Gitlab Clone panel:

How come you are setting env variables manually?

I put them all as one string under Extra Parameters:

I changed external_url to https://mysite.com/

 

I then made the following changes to gitlab.rb:

 

external_url 'https://mysite.com'
nginx['listen_port'] = 9080
nginx['listen_https'] = false

and ran gitlab-ctl reconfigure

 

In Nginx Proxy Manager:

With the appropriate SSL certificate details for Let's Encrypt

 

 

The problem I now have is that I am unable to do a git clone on either https or ssh without getting some authentication/SSL error. It used to work when I used the local server's IP address before I changed it to external URL. 

 

 

 

 

Edited December 8, 20214 yr by frakman1

Works perfect!  I am now using NginxProxyManager and on the Details tab of the domain, I didn't check any of the options (cache assets, block common exploits, etc) and the clone works perfectly!

 

Thank you very much for sharing!

On 8/25/2020 at 4:10 PM, andr0id said:

Hello

I have a problem with my gitlab container. After starting it, it's running great. After round about one day, I only get a "

502 Whoops, GitLab is taking too much time to respond." message. If I look into my logs, it seams that the Redis database it not available anymore. I can restart the container, but after one day it's the same again. What is going wrong?

 

My container settings:

Extra Parameters: --env GITLAB_OMNIBUS_CONFIG="external_url 'https://myurl.com/'; gitlab_rails['lfs_enabled'] = true;"

Network Type: Custom network with a LetsEncrypt Container

Ports  HTTP: 5090   HTTPS:5443

Application Data Storage Path: /mnt/user/git/git files/       <-- Share with Cache enabled (Use cache: yes)

Config Storage Path and Config Storage Path: Default Path (/mnt/cache/appdata/gitlab-ce)

Custom Path:  - Container Path: /var/opt/gitlab/gitlab-rails/shared/lfs-objects  

- Host Path: /mnt/user/git/git lfs files/ <-- Share with Cache enabled (Use cache: yes)

 

gitlab.rb Changes:

To prevent the integrated nginx from trying to reach letsEncrypt and communicating with my letsEncrypt container via http instead.

nginx[‘listen_port’] = 9080;

nginx[‘listen_https’] = false;

 

The GitLab Container Log: 

==> /var/log/gitlab/sidekiq/current <==
{"severity":"ERROR","time":"2020-08-25T19:40:21.824Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:22.825Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:23.443Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:23.443Z","message":"/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/redis-4.1.3/lib/redis/client.rb:362:in `rescue in establish_connection'"}

{"severity":"WARN","time":"2020-08-25T19:40:23.444Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0}

{"severity":"ERROR","time":"2020-08-25T19:40:23.445Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"WARN","time":"2020-08-25T19:40:23.445Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0}

{"severity":"ERROR","time":"2020-08-25T19:40:23.826Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:24.828Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}


==> /var/log/gitlab/redis-exporter/current <==
2020-08-25_19:40:24.88917 time="2020-08-25T19:40:24Z" level=error msg="Couldn't connect to redis instance"


==> /var/log/gitlab/sidekiq/current <==
{"severity":"ERROR","time":"2020-08-25T19:40:25.014Z","message":"heartbeat: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:26.468Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"WARN","time":"2020-08-25T19:40:26.469Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0}

{"severity":"ERROR","time":"2020-08-25T19:40:26.470Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"WARN","time":"2020-08-25T19:40:26.470Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0}

{"severity":"ERROR","time":"2020-08-25T19:40:26.830Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:27.831Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:28.446Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"ERROR","time":"2020-08-25T19:40:28.447Z","message":"/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/redis-4.1.3/lib/redis/client.rb:362:in `rescue in establish_connection'"}

{"severity":"WARN","time":"2020-08-25T19:40:28.447Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0}

{"severity":"ERROR","time":"2020-08-25T19:40:28.448Z","message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

{"severity":"WARN","time":"2020-08-25T19:40:28.449Z","error_class":"Redis::CannotConnectError","error_message":"Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)","error_backtrace":["config/initializers/zz_metrics.rb:198:in `connect'","lib/gitlab/instrumentation/redis_interceptor.rb:15:in `call'"],"retry":0}


==> /var/log/gitlab/puma/puma_stdout.log <==
{"timestamp":"2020-08-25T19:40:28.795Z","pid":322,"message":"PumaWorkerKiller: Consuming 3111.04296875 mb with master and 4 workers."}

==> /var/log/gitlab/sidekiq/current <==
{"severity":"ERROR","time":"2020-08-25T19:40:28.832Z","message":"Heartbeat thread error: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ECONNREFUSED)"}

 

I was getting this error as well. I also had qBittorrent running. I ended up moving it off of port 8080 on to another port (8888).

 

This did involve having to add a custom port and removing the previously allocated one for 8080. Apparently the reason is that the internal container also needs to be on the same port (8888). So if you just update the existing parameter to 8888, the internal port is still 8080 and you won't be able to connect to it.

 

So just create a new port parameter and set both of them to be 8888 (or whatever you want the new port to be) and then erase the old 8080 port mapping (for me it was Host Port 3). Then I restarted GitLab and it's been running stable since (it's been about 4 days so far)

On 8/28/2021 at 5:13 AM, tjb_altf4 said:

Had a similar issue, I fixed it this way...

 

Run this command in the gitlab docker CLI (not unraid CLI):

gitlab-rake "gitlab:password:reset[root]"

 

This will start the password reset process for root.

I am new to docker / unraid so sorry if this seems trivial. 

How does one access the gitlab docker CLI?

6 minutes ago, francknoahk said:

How does one access the gitlab docker CLI?

 

You right click on the GitLab-CE entry in the Docker tab of the UnRaid webpage, then select Console

 

 

Hope that helps!

Is it normal for this docker to create entries in the log every few seconds or so? I just worry about the log size and if there is a possible issue causing this.

On 2/5/2022 at 7:35 PM, live4soccer7 said:

Is it normal for this docker to create entries in the log every few seconds or so? I just worry about the log size and if there is a possible issue causing this.

 

Gitlab is s a complex and busy app for sure, mine is constantly writing logs as well. How long has your Gitlab instance been running, a week? Check out how much space the log files are using in /mnt/cache/appdata/gitlab-ce/log - Are they being rotated? 

I just turned it off for now since I'm not using it at the moment. I do plan to soon, so I will check on this. Thank you

On 2/5/2022 at 8:35 PM, live4soccer7 said:

Is it normal for this docker to create entries in the log every few seconds or so? I just worry about the log size and if there is a possible issue causing this.

You can limit log file sizes by changing the environment variable in your Edit docker template page. Mine looks like this. I disabled prometheus because it's a giant hog.

 

--log-opt max-size=10m --log-opt max-file=1 --env GITLAB_OMNIBUS_CONFIG="external_url 'http://MY-UNRAID-IP:9080/'; postgresql['shared_buffers'] = '256MB'; sidekiq['concurrency'] = 15; prometheus_monitoring['enable'] = false;"