LUKI NOTES

GitLab allows us to deploy CI/CD pipeline runners on our own resources within our environment. This option is available not only for the self-hosted plan but also for the cloud service plan (gitlab.com). With this setup, unlike GitHub Action, we can avoid incurring additional costs for extended pipeline runtime. This is because we can deploy the runner on an on-demand server and optimize its usage. GitLab CI offers several options for setting up resources to run CI/CD pipelines. A runner can be configured to handle jobs for specific groups or projects using designated tags. It can also be set to use different executors, such as Shell, Docker, Kubernetes, or VirtualBox. A comparison table of the supported executors is available in the executor documentation . Some executors offer greater flexibility and ease of use, while others may be more rigid but enhance server security. Installing the runner in our machine For example, we will deploy the runner on an Ubuntu serve...

Gitlab actively updates its products including the Community Edition (CE). The easiest way to install Gitlab CE on a Linux machine is by using the package manager. To add the repository to our system, we can run the following command. sudo apt update curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash Before we run the upgrade process, we should follow the recommendation of the version order. If not, we may end up breaking our Gitlab service. Upgrading one version to another version far greater may require upgrading from previous versions first, step by step. To check our current Gitlab version, we can visit <OUR_GITLAB_ADDRESS>/help . The upgrade recommendation can be found  HERE . Note, we are also suggested to upgrade our Gitlab regularly for security reasons. We can get the list of available versions HERE . To apply the upgrade on our machine, we can run the following command. sudo apt-get install gitlab-ce=<VERSI...

Gitlab CE or EE is shipped with the capability to send messages through SMTP service as the basic feature to send notifications or updates to the users. The configuration parameters are available in /etc/gitlab/gitlab.rb . Each SMTP service provider has a different configuration, therefore the Gitlab configuration parameters should be adjusted according to the requirements. Some examples have been provided by Gitlab here . This is an example if you use the Zoho service. gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "smtp.zoho.com" gitlab_rails['smtp_port'] = 587 gitlab_rails['smtp_authentication'] = "plain" gitlab_rails['smtp_enable_starttls_auto'] = true gitlab_rails['smtp_user_name'] = "gitlab@mydomain.com" gitlab_rails['smtp_password'] = "mypassword" gitlab_rails['smtp_domain'] = "smtp.zoho.com" This is another example of using Amazon SES w...

I manage a self-hosted Gitlab instance on a server in DigitalOcean. A few months ago, I got a notification from DigitalOcean Security Center that my instance has been disconnected from the network because it was detected performing a kind of Distributed Denial of Service (DDoS) attack. I tried to solve the issue, I suspected that it was just a Gitlab runner process that made some requests that were falsy detected as a DDOS attack. DigitalOcean has very strict rules for this case that it becomes difficult for me to re-activate the network connection of my server before I perform a kind of recovery process and system scanning. That's why I choose to deploy a new server and back up the repository. After I managed to deploy a new instance and re-run the repository server, I upgraded the server with the latest patch that is suitable. I also thought that the issue was only caused by falsy security detection. After that moment, I left my server untouched for months lat...