<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[GitLab]]></title><description><![CDATA[GitLab]]></description><link>https://forum.cloudron.io/category/25</link><generator>RSS for Node</generator><lastBuildDate>Wed, 17 Jun 2026 16:09:54 GMT</lastBuildDate><atom:link href="https://forum.cloudron.io/category/25.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 22 May 2026 08:15:18 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Database &#x27;main&#x27; is using PostgreSQL 16.11, but this version of GitLab requires PostgreSQL 17]]></title><description><![CDATA[Roll back for GitLab is a no-go thing. Let's hope that Gitlab does not do something in future update release which would prevent using it.
]]></description><link>https://forum.cloudron.io/topic/15538/database-main-is-using-postgresql-16.11-but-this-version-of-gitlab-requires-postgresql-17</link><guid isPermaLink="true">https://forum.cloudron.io/topic/15538/database-main-is-using-postgresql-16.11-but-this-version-of-gitlab-requires-postgresql-17</guid><dc:creator><![CDATA[tobiasb]]></dc:creator><pubDate>Fri, 22 May 2026 08:15:18 GMT</pubDate></item><item><title><![CDATA[Cannot add group images: Error 403 Forbidden]]></title><description><![CDATA[Perfect, thanks a lot!
]]></description><link>https://forum.cloudron.io/topic/15297/cannot-add-group-images-error-403-forbidden</link><guid isPermaLink="true">https://forum.cloudron.io/topic/15297/cannot-add-group-images-error-403-forbidden</guid><dc:creator><![CDATA[pathab]]></dc:creator><pubDate>Wed, 25 Mar 2026 20:33:51 GMT</pubDate></item><item><title><![CDATA[Cannot login after restoring from backup to v.1.112.4]]></title><description><![CDATA[@davejgreen I have responded on support@ . Let's continue there and I will report back my findings here.
]]></description><link>https://forum.cloudron.io/topic/15198/cannot-login-after-restoring-from-backup-to-v.1.112.4</link><guid isPermaLink="true">https://forum.cloudron.io/topic/15198/cannot-login-after-restoring-from-backup-to-v.1.112.4</guid><dc:creator><![CDATA[joseph]]></dc:creator><pubDate>Mon, 09 Mar 2026 16:53:55 GMT</pubDate></item><item><title><![CDATA[PostGres SQL Error update from v1.112.4 to v1.113.0]]></title><description><![CDATA[I had the exact same problem and the post of arnaudguy fixed it like a charm. So please

set the app in repair mode
use the postgres button on the top to enter postgres
follow the steps of arnaudguy

  SELECT
  tc.constraint_name,
  kcu.column_name,
  ccu.table_name AS foreign_table_name,
  ccu.column_name AS foreign_column_name
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
  ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage ccu
  ON ccu.constraint_name = tc.constraint_name
WHERE tc.table_name = 'user_agent_details'
  AND tc.constraint_type = 'FOREIGN KEY';

SELECT COUNT(*) AS nb_violations
FROM user_agent_details
WHERE organization_id IS NULL;

BEGIN;
DELETE FROM user_agent_details
WHERE organization_id IS NULL;
COMMIT;
ALTER TABLE user_agent_details VALIDATE CONSTRAINT check_17a3a18e31;
BEGIN
DELETE 1
COMMIT
ALTER TABLE

SELECT conname, convalidated
FROM pg_constraint
WHERE conname = 'check_17a3a18e31';


Exit postgres \q
deactivate repair mode

and voilá it works again...
thanks a lot to you guys...
]]></description><link>https://forum.cloudron.io/topic/15158/postgres-sql-error-update-from-v1.112.4-to-v1.113.0</link><guid isPermaLink="true">https://forum.cloudron.io/topic/15158/postgres-sql-error-update-from-v1.112.4-to-v1.113.0</guid><dc:creator><![CDATA[m-si]]></dc:creator><pubDate>Mon, 02 Mar 2026 07:31:39 GMT</pubDate></item><item><title><![CDATA[S3 Artifacts]]></title><description><![CDATA[In /app/data/gitlab.yml, there is a artifacts section. You can just set it to enabled. You don't need S3 as such, it stores in filesystem by default into /app/data/shared/artifacts
  artifacts:
    enabled: true

]]></description><link>https://forum.cloudron.io/topic/14811/s3-artifacts</link><guid isPermaLink="true">https://forum.cloudron.io/topic/14811/s3-artifacts</guid><dc:creator><![CDATA[joseph]]></dc:creator><pubDate>Mon, 29 Dec 2025 08:43:45 GMT</pubDate></item><item><title><![CDATA[Gigantic blunder caused by a lack of warnings]]></title><description><![CDATA[@nebulon said in Gigantic blunder caused by a lack of warnings:

Curiously nothing about that possible side-effect is mentioned in the gitlab docs either https://docs.gitlab.com/administration/incoming_email/ or at least I didn't see it.

It could be clearer but it does say

„We recommend using an email address that receives only messages that are intended for the GitLab instance“

and it goes on about „dedicated“ addresses….
]]></description><link>https://forum.cloudron.io/topic/14185/gigantic-blunder-caused-by-a-lack-of-warnings</link><guid isPermaLink="true">https://forum.cloudron.io/topic/14185/gigantic-blunder-caused-by-a-lack-of-warnings</guid><dc:creator><![CDATA[necrevistonnezr]]></dc:creator><pubDate>Wed, 13 Aug 2025 15:08:32 GMT</pubDate></item><item><title><![CDATA[&quot;Unlock instructions&quot; email due to brute force attack on gitlab users]]></title><description><![CDATA[Hello @allanbowe
Not by default from Cloudron. (Maybe in the future)
I would advise to temporary edit the GitLab NGINX file to only allow certain IP addresses.
This manual change will get reset with every Cloudron / Server / App restart.
So it is really temporary.
Example for APP ID 682ca768-93e5-4bcb-a760-677daa9a8e3b
Go into the application NGINX config folder:
cd /home/yellowtent/platformdata/nginx/applications/682ca768-93e5-4bcb-a760-677daa9a8e3b

Edit the sub.domain.tld.conf file, in this case dokuwiki.cloudron.dev:
nano dokuwiki.cloudron.dev.conf

Inside this section, add:
# https server
server {
    
    # allow localhost
    allow 127.0.0.1;
    # allow cloudron proxy
    allow 172.18.0.1;
    # allow this servers public ipv4
    allow REDACTED-IPV4;
    # allow this servers public ipv6
    allow REDACTED-IPV6;
    # Allow some other specific IPv4 e.g VPN
    allow VPN-IP;
    # deny all other
    deny all;
    [...]
}

Reload the NGINX service:
systemctl reload nginx.service

This will result for other IPs that are not explicitly allowed to return a 403 Forbidden:
[image: 1753639364452-52b04087-811c-4d9f-8a90-2b20cb5de9f4-image.png]
Keep in mind, every Cloudron / Server / App Restart will reset this change!
]]></description><link>https://forum.cloudron.io/topic/14102/unlock-instructions-email-due-to-brute-force-attack-on-gitlab-users</link><guid isPermaLink="true">https://forum.cloudron.io/topic/14102/unlock-instructions-email-due-to-brute-force-attack-on-gitlab-users</guid><dc:creator><![CDATA[james]]></dc:creator><pubDate>Mon, 21 Jul 2025 08:46:09 GMT</pubDate></item><item><title><![CDATA[Gitlab runners fail every 30th build]]></title><description><![CDATA[We solved this in the end by adding some clean up to the GitLab runner's after_script in our .gitlab-ci.yml file:
  before_script:
    - stat -c %m /tmp
    - du -sh /tmp
    - ls /tmp -la
    - export XDG_CACHE_HOME=$(mktemp -d)

# Each job leaks files into the gitlab-runner's private /tmp
  after_script:
    - rm -rf $XDG_CACHE_HOME
    - du -sh /tmp
    - ls /tmp -la
    - find /tmp -mindepth 1 -maxdepth 1 -user gitlab-runner -exec rm -rf {} +
    - du -sh /tmp
    - ls /tmp -la

We could see the files that got left over when we added the logging lines.
]]></description><link>https://forum.cloudron.io/topic/13934/gitlab-runners-fail-every-30th-build</link><guid isPermaLink="true">https://forum.cloudron.io/topic/13934/gitlab-runners-fail-every-30th-build</guid><dc:creator><![CDATA[davejgreen]]></dc:creator><pubDate>Fri, 13 Jun 2025 15:38:06 GMT</pubDate></item><item><title><![CDATA[Persistent memory issues—how to reduce&#x2F;remove extra features?]]></title><description><![CDATA[Thanks for the answers—so to be clear it’s not possible to reduce the features as their docs suggest? (Through some rb config)
To be honest the gitea instance was hacked, so that was not ideal, and I switched from gogs to gitea awhile ago and cannot exactly recall why.
]]></description><link>https://forum.cloudron.io/topic/12620/persistent-memory-issues-how-to-reduce-remove-extra-features</link><guid isPermaLink="true">https://forum.cloudron.io/topic/12620/persistent-memory-issues-how-to-reduce-remove-extra-features</guid><dc:creator><![CDATA[sixfold_distract]]></dc:creator><pubDate>Thu, 10 Oct 2024 20:21:38 GMT</pubDate></item><item><title><![CDATA[How to run a GitLab container registry (2024)]]></title><description><![CDATA[@timconsidine Yes, this is what I run today and it has worked really, really well ... integrates nicely with Gitlab. But the deprecation the Gitlab folks have in mind for 3rd party registries is a worry (https://docs.gitlab.com/administration/packages/container_registry/#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint). There's talk about them doing a hard deprecation which I'm taking to mean would stop it working completely rather than just being unsupported as today
]]></description><link>https://forum.cloudron.io/topic/12334/how-to-run-a-gitlab-container-registry-2024</link><guid isPermaLink="true">https://forum.cloudron.io/topic/12334/how-to-run-a-gitlab-container-registry-2024</guid><dc:creator><![CDATA[jamesgallagher]]></dc:creator><pubDate>Thu, 22 Aug 2024 00:44:25 GMT</pubDate></item><item><title><![CDATA[Pushing to a branch doesn&#x27;t trigger callbacks]]></title><description><![CDATA[@lukaszj could it be same as https://gitlab.com/gitlab-org/gitlab/-/issues/348565 ? From a comment there, One "workarround" that seems to work is to trigger the HouseKeeping on the general settings . The issue is still not fixed but maybe you can look for log string "Internal API error" ? There are some detailed logs in /run/gitlab/log/ (only available via Web Terminal)
]]></description><link>https://forum.cloudron.io/topic/12075/pushing-to-a-branch-doesn-t-trigger-callbacks</link><guid isPermaLink="true">https://forum.cloudron.io/topic/12075/pushing-to-a-branch-doesn-t-trigger-callbacks</guid><dc:creator><![CDATA[joseph]]></dc:creator><pubDate>Thu, 11 Jul 2024 06:26:14 GMT</pubDate></item><item><title><![CDATA[Error During GitLab Update (16.11.2 -&gt; 17.0.1): Insufficient Disk Space]]></title><description><![CDATA[So despite having 11Gb free, the restore fails due to insufficient disk space? I am not sure how we can help here though. Can you install a fresh gitlab instance fine?
]]></description><link>https://forum.cloudron.io/topic/11862/error-during-gitlab-update-16-11-2-17-0-1-insufficient-disk-space</link><guid isPermaLink="true">https://forum.cloudron.io/topic/11862/error-during-gitlab-update-16-11-2-17-0-1-insufficient-disk-space</guid><dc:creator><![CDATA[nebulon]]></dc:creator><pubDate>Wed, 05 Jun 2024 11:02:48 GMT</pubDate></item><item><title><![CDATA[Service Desk does not generate tickets from emails]]></title><description><![CDATA[@girish Works like a charm. Many thanks for the fix!
]]></description><link>https://forum.cloudron.io/topic/11455/service-desk-does-not-generate-tickets-from-emails</link><guid isPermaLink="true">https://forum.cloudron.io/topic/11455/service-desk-does-not-generate-tickets-from-emails</guid><dc:creator><![CDATA[pathab]]></dc:creator><pubDate>Tue, 02 Apr 2024 09:21:48 GMT</pubDate></item><item><title><![CDATA[Cannot log in through cmd line after update]]></title><description><![CDATA[@Zoldir Looks like you are using http auth, is that correct? Any reason to not use SSH for git push/pull?
In any case, the recent update of GitLab moved from LDAP to OIDC. Once you login to gitlab , visit https://git.domain.com/-/user_settings/personal_access_tokens. You can use that personal access token for HTTP auth ("You can also use personal access tokens to authenticate against Git over HTTP.")
]]></description><link>https://forum.cloudron.io/topic/11240/cannot-log-in-through-cmd-line-after-update</link><guid isPermaLink="true">https://forum.cloudron.io/topic/11240/cannot-log-in-through-cmd-line-after-update</guid><dc:creator><![CDATA[girish]]></dc:creator><pubDate>Tue, 05 Mar 2024 08:47:26 GMT</pubDate></item><item><title><![CDATA[Can&#x27;t login after upgrade to 1.88]]></title><description><![CDATA[FYI the changed username fixed it, everything is running fine now. 
]]></description><link>https://forum.cloudron.io/topic/11224/can-t-login-after-upgrade-to-1-88</link><guid isPermaLink="true">https://forum.cloudron.io/topic/11224/can-t-login-after-upgrade-to-1-88</guid><dc:creator><![CDATA[klawitterb]]></dc:creator><pubDate>Sun, 03 Mar 2024 09:01:16 GMT</pubDate></item><item><title><![CDATA[Unable to access Rails Console from web terminal]]></title><description><![CDATA[Damned, it was too obvious to be seen.
It works, thanks 
]]></description><link>https://forum.cloudron.io/topic/11144/unable-to-access-rails-console-from-web-terminal</link><guid isPermaLink="true">https://forum.cloudron.io/topic/11144/unable-to-access-rails-console-from-web-terminal</guid><dc:creator><![CDATA[Zoldir]]></dc:creator><pubDate>Tue, 20 Feb 2024 10:28:41 GMT</pubDate></item><item><title><![CDATA[Sidekiq Loop takes down GitLab instance]]></title><description><![CDATA[I did read through those pages, and that is in fact how I arrived at the queue state representation that I posted above. Unfortunately clearing the queue did not help for long: The tasks kept reappearing.
I have, however -through many trials and tribulations- possibly managed to resolve this problem over the weekend: Logging into the GitLab postgres DB, I found a table called container_repositories which contained references to the repos that were used to test the registry feature. After truncating that table, clearing the queued jobs and restarting GitLab (as well as the entire instance for good measure), it seems to have slowly reverted back to normal over the past 24 hours, at least for the time being. I'm gonna keep an eye on it some more, but it's looking like that might've been it.
It's a bit weird that GitLab would keep spinning tasks endlessly like this, but then again it's a massive piece of software, so perhaps this is simply a strange bug in GitLab itself. In any case, the container registry instructions for GitLab integration did not seem to work that well for us as they produce this behavior whenever I try them out (I tried it twice to make sure), so maybe another look at those could be warranted.
]]></description><link>https://forum.cloudron.io/topic/11119/sidekiq-loop-takes-down-gitlab-instance</link><guid isPermaLink="true">https://forum.cloudron.io/topic/11119/sidekiq-loop-takes-down-gitlab-instance</guid><dc:creator><![CDATA[timwedde]]></dc:creator><pubDate>Fri, 16 Feb 2024 15:39:56 GMT</pubDate></item><item><title><![CDATA[SPAM classification for GitLab adding users with Google email address]]></title><link>https://forum.cloudron.io/topic/11111/spam-classification-for-gitlab-adding-users-with-google-email-address</link><guid isPermaLink="true">https://forum.cloudron.io/topic/11111/spam-classification-for-gitlab-adding-users-with-google-email-address</guid><pubDate>Thu, 15 Feb 2024 14:18:17 GMT</pubDate></item><item><title><![CDATA[V1.85.0-1 broke app deployment]]></title><description><![CDATA[@timconsidine since the difference is mostly the postgresql fixes, it might be worth updating already in your case.
]]></description><link>https://forum.cloudron.io/topic/10985/v1-85-0-1-broke-app-deployment</link><guid isPermaLink="true">https://forum.cloudron.io/topic/10985/v1-85-0-1-broke-app-deployment</guid><dc:creator><![CDATA[nebulon]]></dc:creator><pubDate>Mon, 29 Jan 2024 15:52:39 GMT</pubDate></item><item><title><![CDATA[GitLab Upgrade Error]]></title><description><![CDATA[Yes after upgrading it solved
]]></description><link>https://forum.cloudron.io/topic/10927/gitlab-upgrade-error</link><guid isPermaLink="true">https://forum.cloudron.io/topic/10927/gitlab-upgrade-error</guid><dc:creator><![CDATA[DualOSWinWiz]]></dc:creator><pubDate>Wed, 24 Jan 2024 19:33:42 GMT</pubDate></item><item><title><![CDATA[Gitlab Mailroom fails to start]]></title><description><![CDATA[This should be fixed from 16.7 onwards I believe.
]]></description><link>https://forum.cloudron.io/topic/10816/gitlab-mailroom-fails-to-start</link><guid isPermaLink="true">https://forum.cloudron.io/topic/10816/gitlab-mailroom-fails-to-start</guid><dc:creator><![CDATA[D3PSI]]></dc:creator><pubDate>Sun, 07 Jan 2024 19:11:14 GMT</pubDate></item><item><title><![CDATA[Gitlab Runner - OK on the same machine?]]></title><description><![CDATA[@djxx I wouldn't say running a CI runner a "little thing"  But anyway, it's up to you if you feel comfortable and are aware of the repercussions of installing things give access to all your containers.
I have no idea about sysbox, never tried it.
]]></description><link>https://forum.cloudron.io/topic/10426/gitlab-runner-ok-on-the-same-machine</link><guid isPermaLink="true">https://forum.cloudron.io/topic/10426/gitlab-runner-ok-on-the-same-machine</guid><dc:creator><![CDATA[girish]]></dc:creator><pubDate>Wed, 15 Nov 2023 16:12:31 GMT</pubDate></item><item><title><![CDATA[Long startup and hourly crash]]></title><description><![CDATA[It's better now, using 3250MB of RAM.
]]></description><link>https://forum.cloudron.io/topic/10409/long-startup-and-hourly-crash</link><guid isPermaLink="true">https://forum.cloudron.io/topic/10409/long-startup-and-hourly-crash</guid><dc:creator><![CDATA[robi]]></dc:creator><pubDate>Sun, 12 Nov 2023 22:37:50 GMT</pubDate></item><item><title><![CDATA[gitlab multiDomain]]></title><description><![CDATA[@girish I'll test it and let you know, but if multiDomain doesn't cut it i'm pretty sure httpsPorts would, at least for the basic setups.
]]></description><link>https://forum.cloudron.io/topic/9638/gitlab-multidomain</link><guid isPermaLink="true">https://forum.cloudron.io/topic/9638/gitlab-multidomain</guid><dc:creator><![CDATA[c0decafe]]></dc:creator><pubDate>Fri, 14 Jul 2023 21:41:53 GMT</pubDate></item><item><title><![CDATA[Gitlab deletes new branches instantly -&gt; &#x2F;home&#x2F;git is not writable.]]></title><description><![CDATA[@opensourced that warning comes from bundler and it can be ignored (it's not an error).
Are you able to see the issue on git.cloudron.io ?
]]></description><link>https://forum.cloudron.io/topic/8899/gitlab-deletes-new-branches-instantly-home-git-is-not-writable</link><guid isPermaLink="true">https://forum.cloudron.io/topic/8899/gitlab-deletes-new-branches-instantly-home-git-is-not-writable</guid><dc:creator><![CDATA[girish]]></dc:creator><pubDate>Wed, 29 Mar 2023 05:29:43 GMT</pubDate></item></channel></rss>