Tested March 2026<\/strong> on Ubuntu 24.04 LTS with GitLab CE 18.10.1, GitLab Runner 18.10.0, Python 3.12.3, Flask 3.1.1<\/em><\/p>\n\n\n\n Install the prerequisite packages first:<\/p>\n\n\n\n When the postfix configuration prompt appears, select Internet Site<\/strong> and use your server’s FQDN. Postfix handles notification emails from GitLab.<\/p>\n\n\n\n Add the official GitLab CE repository:<\/p>\n\n\n\n Install GitLab CE with your external URL. Replace the domain with your own:<\/p>\n\n\n\n The installation takes 3 to 5 minutes depending on your server specs. GitLab bundles its own Nginx, PostgreSQL, Redis, and Puma, so you do not need to install them separately. When it finishes, you will see:<\/p>\n\n\n\n Retrieve the initial root password before it gets auto-deleted:<\/p>\n\n\n\n Save this password somewhere safe. You will use it for the first login.<\/p>\n\n\n\n If GitLab’s built-in Let’s Encrypt integration fails (common with fresh DNS records and DNSSEC propagation delays), you can use certbot directly. Stop GitLab’s Nginx temporarily and run the standalone challenge:<\/p>\n\n\n\n Point GitLab’s Nginx to the Let’s Encrypt certificates by adding these lines to Add the following at the end of the file:<\/p>\n\n\n\n Apply the configuration:<\/p>\n\n\n\n Verify all services are running:<\/p>\n\n\n\n Every service should show Open your browser and navigate to your GitLab URL. Log in with username The runner is what actually executes your CI\/CD jobs. GitLab itself just orchestrates. Without a registered runner, pipelines sit in “pending” forever.<\/p>\n\n\n\n Add the GitLab Runner repository and install it:<\/p>\n\n\n\n Confirm the installation:<\/p>\n\n\n\n You should see the version and build information:<\/p>\n\n\n\n GitLab 18.x uses the new runner registration flow. Create a runner token via the API (you need a personal access token with The response includes a The output confirms successful registration:<\/p>\n\n\n\n Verify the runner is online:<\/p>\n\n\n\n The runner should show “Service is running” and “is valid” respectively.<\/p>\n\n\n\n We need a real codebase to build pipelines against. Create a new project in GitLab (either through the web UI or API), then clone it locally and add a simple Flask app with tests.<\/p>\n\n\n\n Create Create Create The tests use Flask’s built-in test client. No external services, no database, no mocking. Both tests validate response codes and JSON payloads.<\/p>\n\n\n\n GitLab pipelines are defined in a The pipeline has three stages that run sequentially. Jobs within the same stage run in parallel when multiple runners are available.<\/p>\n\n\n\n Build stage:<\/strong> Creates a Python virtual environment, installs dependencies from Test stage:<\/strong> Two jobs run here. The Deploy stage:<\/strong> Only triggers on the Commit all files and push to the main branch:<\/p>\n\n\n\n Navigate to your project’s Build > Pipelines<\/strong> page. The pipeline starts immediately after the push:<\/p>\n\n\n\n Click on the pipeline to see the stage graph. Build runs first, then lint and test run in parallel, and finally deploy_staging runs:<\/p>\n\n\n\n The build job creates the virtual environment and installs Flask 3.1.1 and pytest 8.3.5 with all their dependencies:<\/p>\n\n\n\n Both unit tests pass, confirming the Flask endpoints return the expected JSON responses:<\/p>\n\n\n\n Click on any test job to see the full log with timing and artifact details:<\/p>\n\n\n\n The deploy stage starts the Flask app and validates it with a health check. The GitLab tracks the deployment in the Operate > Environments<\/strong> page, showing the deployment history and status:<\/p>\n\n\n\n These two get confused constantly. Artifacts<\/strong> are files produced by a job that get passed to downstream jobs within the same pipeline. They are uploaded to GitLab and can be downloaded from the UI. Cache<\/strong> persists across pipelines. It is a best-effort optimization (might be cleared at any time) used for things like pip\/npm package caches. In our pipeline, the The The We used the shell executor because it runs commands directly on the runner’s host, with zero container overhead. This is perfect for getting started and for servers where Docker is not installed. The trade-off is that jobs share the host filesystem and can interfere with each other. For production CI\/CD with multiple teams, the Docker executor provides isolation by running each job in a fresh container. Switch by changing What You Need<\/h2>\n\n\n\n
\n
gitlab.computingforgeeks.com<\/code>). SSL certificates via Let’s Encrypt.<\/li>\n\nInstall GitLab CE 18.10 on Ubuntu 24.04<\/h2>\n\n\n\n
sudo apt-get update\nsudo apt-get install -y curl openssh-server ca-certificates tzdata perl postfix<\/code><\/pre>\n\n\n\ncurl -s https:\/\/packages.gitlab.com\/install\/repositories\/gitlab\/gitlab-ce\/script.deb.sh | sudo bash<\/code><\/pre>\n\n\n\nsudo EXTERNAL_URL=\"https:\/\/gitlab.yourdomain.com\" apt-get install -y gitlab-ce<\/code><\/pre>\n\n\n\nDefault admin account has been configured with following details:\nUsername: root\nPassword stored to \/etc\/gitlab\/initial_root_password. This file will be cleaned up in first reconfigure run after 24 hours.<\/code><\/pre>\n\n\n\nsudo cat \/etc\/gitlab\/initial_root_password | grep Password:<\/code><\/pre>\n\n\n\nConfigure SSL with Let’s Encrypt<\/h3>\n\n\n\n
sudo apt-get install -y certbot\nsudo gitlab-ctl stop nginx\nsudo certbot certonly --standalone -d gitlab.yourdomain.com --non-interactive --agree-tos -m your@email.com<\/code><\/pre>\n\n\n\n\/etc\/gitlab\/gitlab.rb<\/code>:<\/p>\n\n\n\nsudo vi \/etc\/gitlab\/gitlab.rb<\/code><\/pre>\n\n\n\nletsencrypt['enable'] = false\nnginx['ssl_certificate'] = \"\/etc\/letsencrypt\/live\/gitlab.yourdomain.com\/fullchain.pem\"\nnginx['ssl_certificate_key'] = \"\/etc\/letsencrypt\/live\/gitlab.yourdomain.com\/privkey.pem\"<\/code><\/pre>\n\n\n\nsudo gitlab-ctl reconfigure<\/code><\/pre>\n\n\n\nsudo gitlab-ctl status<\/code><\/pre>\n\n\n\nrun<\/code> status. The key ones are puma (web), sidekiq (background jobs), gitaly (git operations), postgresql, and redis:<\/p>\n\n\n\nrun: gitaly: (pid 19606) 323s; run: log: (pid 18562) 507s\nrun: gitlab-workhorse: (pid 37089) 120s; run: log: (pid 19237) 386s\nrun: nginx: (pid 42280) 1s\nrun: postgresql: (pid 18620) 504s; run: log: (pid 18637) 501s\nrun: puma: (pid 38802) 23s; run: log: (pid 19140) 398s\nrun: redis: (pid 18473) 516s; run: log: (pid 18488) 515s\nrun: sidekiq: (pid 38690) 47s; run: log: (pid 19184) 391s<\/code><\/pre>\n\n\n\nroot<\/code> and the initial password you retrieved earlier.<\/p>\n\n\n\n![\"GitLab](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/03\/01-gitlab-login-page-2.png\" "\\"\\"")
<\/figure>\n\n\n\nInstall and Register GitLab Runner<\/h2>\n\n\n\n
curl -s https:\/\/packages.gitlab.com\/install\/repositories\/runner\/gitlab-runner\/script.deb.sh | sudo bash\nsudo apt-get install -y gitlab-runner<\/code><\/pre>\n\n\n\ngitlab-runner --version<\/code><\/pre>\n\n\n\nVersion: 18.10.0\nGit revision: ac71f4d8\nGit branch: 18-10-stable\nGO version: go1.25.7\nBuilt: 2026-03-16T14:23:19Z\nOS\/Arch: linux\/amd64<\/code><\/pre>\n\n\n\nCreate a Runner Token<\/h3>\n\n\n\n
api<\/code> scope, which you can create in User Settings > Access Tokens<\/strong>):<\/p>\n\n\n\ncurl -sk --header \"PRIVATE-TOKEN: YOUR_ACCESS_TOKEN\" \\\n --request POST \"https:\/\/gitlab.yourdomain.com\/api\/v4\/user\/runners\" \\\n --data \"runner_type=instance_type&description=shell-runner&tag_list=shell,ubuntu&run_untagged=true\"<\/code><\/pre>\n\n\n\ntoken<\/code> field. Use it to register the runner with the shell executor:<\/p>\n\n\n\nsudo gitlab-runner register \\\n --non-interactive \\\n --url \"https:\/\/gitlab.yourdomain.com\/\" \\\n --token \"glrt-YOUR_RUNNER_TOKEN\" \\\n --executor \"shell\" \\\n --description \"shell-runner\"<\/code><\/pre>\n\n\n\nVerifying runner... is valid runner=Vof6vwBgD\nRunner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!\nConfiguration (with the authentication token) was saved in \"\/etc\/gitlab-runner\/config.toml\"<\/code><\/pre>\n\n\n\nsudo gitlab-runner status\nsudo gitlab-runner verify<\/code><\/pre>\n\n\n\n![\"GitLab](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/03\/07-gitlab-runners.png\" "\\"\\"")
<\/figure>\n\n\n\nCreate a Project with a Flask Application<\/h2>\n\n\n\n
app.py<\/code> with two endpoints:<\/p>\n\n\n\nfrom flask import Flask, jsonify\n\napp = Flask(__name__)\n\n\n@app.route(\"\/\")\ndef home():\n return jsonify({\"status\": \"running\", \"app\": \"flask-demo\", \"version\": \"1.0.0\"})\n\n\n@app.route(\"\/health\")\ndef health():\n return jsonify({\"healthy\": True})\n\n\nif __name__ == \"__main__\":\n app.run(host=\"0.0.0.0\", port=5000)<\/code><\/pre>\n\n\n\nrequirements.txt<\/code> with pinned versions:<\/p>\n\n\n\nflask==3.1.1\npytest==8.3.5<\/code><\/pre>\n\n\n\ntest_app.py<\/code> with two unit tests:<\/p>\n\n\n\nimport pytest\nfrom app import app\n\n\n@pytest.fixture\ndef client():\n app.config[\"TESTING\"] = True\n with app.test_client() as client:\n yield client\n\n\ndef test_home(client):\n response = client.get(\"\/\")\n data = response.get_json()\n assert response.status_code == 200\n assert data[\"status\"] == \"running\"\n assert data[\"version\"] == \"1.0.0\"\n\n\ndef test_health(client):\n response = client.get(\"\/health\")\n data = response.get_json()\n assert response.status_code == 200\n assert data[\"healthy\"] is True<\/code><\/pre>\n\n\n\nWrite the CI\/CD Pipeline<\/h2>\n\n\n\n
.gitlab-ci.yml<\/code> file at the root of your repository. Every push to any branch triggers the pipeline automatically. Create the file:<\/p>\n\n\n\nstages:\n - build\n - test\n - deploy\n\nvariables:\n PIP_CACHE_DIR: \"$CI_PROJECT_DIR\/.pip-cache\"\n\ncache:\n paths:\n - .pip-cache\/\n - venv\/\n\nbuild:\n stage: build\n script:\n - python3 -m venv venv\n - source venv\/bin\/activate\n - pip install -r requirements.txt\n - pip list\n artifacts:\n paths:\n - venv\/\n expire_in: 1 hour\n\nlint:\n stage: test\n script:\n - source venv\/bin\/activate\n - pip install flake8\n - flake8 app.py --max-line-length=120 --statistics\n dependencies:\n - build\n\ntest:\n stage: test\n script:\n - source venv\/bin\/activate\n - pytest test_app.py -v --tb=short --junitxml=report.xml\n artifacts:\n when: always\n reports:\n junit: report.xml\n paths:\n - report.xml\n expire_in: 1 week\n dependencies:\n - build\n\ndeploy_staging:\n stage: deploy\n script:\n - source venv\/bin\/activate\n - echo \"Deploying flask-demo v1.0.0 to staging...\"\n - nohup python3 app.py > \/tmp\/flask-staging.log 2>&1 &\n - sleep 3\n - curl -sf http:\/\/localhost:5000\/health | python3 -m json.tool\n - echo \"Staging deployment verified successfully\"\n - kill %1 2>\/dev\/null || true\n environment:\n name: staging\n url: http:\/\/localhost:5000\n dependencies:\n - build\n only:\n - main<\/code><\/pre>\n\n\n\nHow This Pipeline Works<\/h3>\n\n\n\n
requirements.txt<\/code>, and saves the venv\/<\/code> directory as an artifact. Downstream jobs receive this artifact automatically without reinstalling packages. The cache<\/code> block persists .pip-cache\/<\/code> across pipeline runs, so pip downloads are cached between pushes.<\/p>\n\n\n\nlint<\/code> job runs flake8 to catch style violations and syntax errors. The test<\/code> job runs pytest with verbose output and generates a JUnit XML report. GitLab parses this report and displays test results directly in the merge request UI. Both jobs use dependencies: [build]<\/code> to pull the venv artifact.<\/p>\n\n\n\nmain<\/code> branch. Starts the Flask app in the background, waits 3 seconds for it to initialize, then validates it with a health check via curl. The environment<\/code> block tells GitLab to track this as a “staging” deployment, which shows up in the Environments page. In production you would replace this with an SSH deploy, Ansible playbook<\/a>, or container push to a Docker registry<\/a>.<\/p>\n\n\n\nPush and Watch the Pipeline Run<\/h2>\n\n\n\n
git add -A\ngit commit -m \"Add Flask app with CI\/CD pipeline\"\ngit push origin main<\/code><\/pre>\n\n\n\n![\"GitLab](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/03\/04-gitlab-pipeline-list.png\" "\\"\\"")
<\/figure>\n\n\n\n![\"GitLab](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/03\/05-gitlab-pipeline-graph.png\" "\\"\\"")
<\/figure>\n\n\n\nBuild Job Output<\/h3>\n\n\n\n
$ python3 -m venv venv\n$ source venv\/bin\/activate\n$ pip install -r requirements.txt\nCollecting flask==3.1.1 (from -r requirements.txt (line 1))\n Downloading flask-3.1.1-py3-none-any.whl.metadata (3.0 kB)\nCollecting pytest==8.3.5 (from -r requirements.txt (line 2))\n Downloading pytest-8.3.5-py3-none-any.whl.metadata (7.6 kB)\nSuccessfully installed flask-3.1.1 pytest-8.3.5 ...<\/code><\/pre>\n\n\n\nTest Job Output<\/h3>\n\n\n\n
$ pytest test_app.py -v --tb=short --junitxml=report.xml\nplatform linux -- Python 3.12.3, pytest-8.3.5, pluggy-1.6.0\ntest_app.py::test_home PASSED [ 50%]\ntest_app.py::test_health PASSED [100%]\n============================== 2 passed in 0.12s ===============================<\/code><\/pre>\n\n\n\n![\"GitLab](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/03\/06-gitlab-test-job-log.png\" "\\"\\"")
<\/figure>\n\n\n\nDeploy Job Output<\/h3>\n\n\n\n
curl -sf<\/code> flag makes curl fail silently on HTTP errors, so the job fails if the app does not start correctly:<\/p>\n\n\n\n$ echo \"Deploying flask-demo v1.0.0 to staging...\"\nDeploying flask-demo v1.0.0 to staging...\n$ curl -sf http:\/\/localhost:5000\/health | python3 -m json.tool\n{\n \"healthy\": true\n}\n$ echo \"Staging deployment verified successfully\"\nStaging deployment verified successfully<\/code><\/pre>\n\n\n\n![\"GitLab](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/03\/08-gitlab-environments.png\" "\\"\\"")
<\/figure>\n\n\n\nKey CI\/CD Concepts Explained<\/h2>\n\n\n\n
Artifacts vs Cache<\/h3>\n\n\n\n
venv\/<\/code> directory is an artifact (guaranteed to reach the test and deploy jobs), while .pip-cache\/<\/code> is cache (speeds up pip downloads on subsequent runs).<\/p>\n\n\n\ndependencies vs needs<\/h3>\n\n\n\n
dependencies<\/code> keyword controls which artifacts a job downloads. Without it, a job downloads artifacts from all previous jobs. The needs<\/code> keyword (not used here) allows a job to start as soon as its listed dependencies finish, even if other jobs in the same stage are still running. Use needs<\/code> when you have a complex pipeline graph and want to skip waiting for unrelated parallel jobs.<\/p>\n\n\n\nJUnit Test Reports<\/h3>\n\n\n\n
--junitxml=report.xml<\/code> flag in pytest generates a JUnit XML file. When declared under artifacts.reports.junit<\/code>, GitLab parses this file and shows test results inline in merge requests. Failed tests appear with their error messages directly in the diff view, so reviewers do not need to dig through job logs.<\/p>\n\n\n\nShell Executor vs Docker Executor<\/h3>\n\n\n\n
--executor \"docker\"<\/code> during registration and specifying a default image.<\/p>\n\n\n\nPipeline Configuration Reference<\/h2>\n\n\n\n