omnibus-gitlab VS gitlab-foss

There are several ways to configure the GitLab server as can be observed in the config template. For the next step, I plan to configure it to store objects and uploads in Cloudflare's R2 (S3-compatible) storage which is currently free for up to 10G/month (please Cloudflare, don't make us start paying for this!). After that, who knows? I'll take each day as it comes and ensure I document the config changes as I go along.

It's not available on RHEL 9 as of yet. Issue is still open and can be found here

Check out https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5673

I'm not able to find much except this unresolved issue and this old forum thread.

I check i to this. Looks like GL is waiting on their build product, packagecloud, that they use internally to support RHEL 9. Check out https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6878

Wait a sec... this is from the feature request[1]:

> Just because I don't think I said it explicitly anywhere above: Because we are using an obfuscated, non-free component (the preprocessor), we can't include spamcheck in CE (users of CE expect no proprietary code to be included in the pacakge), but only in EE.

So... is it available in the current version of gitlab-ce or not? I don't want to waste time trying to get it running only to find out you've only made it available for enterprise editions and gitlab.com.

1: https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259

> docker logs -f gitlab Thank you for using GitLab Docker Image! Current version: gitlab-ce=14.7.0-ce.0 Configure GitLab for your system by editing /etc/gitlab/gitlab.rb file And restart this container to reload settings. To do it use docker exec: docker exec -it gitlab editor /etc/gitlab/gitlab.rb docker restart gitlab For a comprehensive list of configuration options please see the Omnibus GitLab readme https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md If this container fails to start due to permission problems try to fix it by executing: docker exec -it gitlab update-permissions docker restart gitlab Cleaning stale PIDs & sockets Preparing services... Starting services... Configuring GitLab... /opt/gitlab/embedded/bin/runsvdir-start: line 37: /proc/sys/fs/file-max: Read-only file system Starting Chef Infra Client, version 15.17.4 resolving cookbooks for run list: ["gitlab"] Synchronizing Cookbooks: - gitlab (0.0.1) - package (0.1.0) - logrotate (0.1.0) - postgresql (0.1.0) - redis (0.1.0) - monitoring (0.1.0) - registry (0.1.0) - mattermost (0.1.0) - consul (0.1.0) - gitaly (0.1.0) - praefect (0.1.0) - gitlab-kas (0.1.0) - gitlab-pages (0.1.0) - letsencrypt (0.1.0) - nginx (0.1.0) - runit (5.1.3) - acme (4.1.3) - crond (0.1.0) Installing Cookbook Gems: Compiling Cookbooks... Recipe: gitlab::default * directory[/etc/gitlab] action create (up to date) Converging 243 resources * directory[/etc/gitlab] action create (up to date) * directory[Create /var/opt/gitlab] action create (up to date) * directory[Create /var/log/gitlab] action create (up to date) * directory[/opt/gitlab/embedded/etc] action create - create new directory /opt/gitlab/embedded/etc - change mode from '' to '0755' - change owner from '' to 'root' - change group from '' to 'root' * template[/opt/gitlab/embedded/etc/gitconfig] action create - create new file /opt/gitlab/embedded/etc/gitconfig - update content in file /opt/gitlab/embedded/etc/gitconfig from none to 5a725a

* Gitlab EE (enterprise edition) is closed, but Gitlab CE (community edition) is open source (https://gitlab.com/gitlab-org/gitlab-foss/)

* I didn't follow the Gitea drama too closely, but my understanding is that Forgejo was a fork born out of that situation

* I've heard the SourceHut guy is a controversial figure, so avoiding it because of that isn't unreasonable. I will just say that "spite forks" tend not to last very long

Gitlab uses an UrlBlocker class to prevent malicious users from exploiting SSRF via the webhook URL. This class validates the URL and blocks everything which is a local network, but before the 11.5.1 version, they didn't think about an IPv6 format, which maps to IPv4: [0:0:0:0:0:ffff:127.0.0.1]. Replacing the part of 127.0.0.1 to any IP address also worked, and this vulnerability made it possible to send requests to the internal network of a GitLab instance. You can read the issue report here: (https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53242 )[https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53242]

I recommend Auto DevOps and hooking your project up to the Kubernetes cluster. Auto DevOps is a standard CI/CD template that GitLab uses by default when .gitlab-ci.yml is not present. It can automatically package up certain types of applications, including those with a Dockerfile in the root of the repo. If the project is hooked up to a Kubernetes cluster and all the right variables are present, it builds that docker image and then fills in a Helm chart template containing that image and deploys it to the cluster.

Thanks. This was also requested for the UI 7 years ago

https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12776

and then closed with the claim that this was implemented, when in fact, it was not.

Similar to fsync, these are designed to ensure data integrity, but in a test setup, they don't matter. You can read more about these in the Postgres doc on non-durability. and explore some benchmarks from Gitlab here. Interestingly, CircleCI's old Postgres images had these features disabled by default, but the newer ones don't seem to.

Most all of those things are possible with Argo Workflows or Tekton with very great effort. But a sustainable system with all the features built-in.

If you wish to clone a copy of GitLab without proprietary code, you can use the read-only mirror of GitLab located at https://gitlab.com/gitlab-org/gitlab-foss/. However, please do not submit any issues and/or merge requests to that project.

GitLab versions 10.7 and later, allow the HTTP(S) protocol for Git clone or fetch requests done by GitLab Runner from CI/CD jobs, even if you select Only SSH.

it sure does