GitLab Agent for Kubernetes is an integration for the GitLab CI/CD pipeline that provides kubectl access from pipeline jobs, allowing Continuous Deployment into a live Kubernetes Cluster. However, the default role for this Agent is cluster-admin when doing a basic Helm install, which is far too permissive and needs to be scoped down to only … GitLab: least privilege for Kube-API calls from GitLab Agent for Kubernetes
GitLab pipelines are frequently used for the building of binaries and publishing of images to container registries, but do not always follow through with Continuous Deployment to a live environment. One reason is that pipelines do not usually have access to the internal systems where these applications are meant to be deployed. In this article, … GitLab: Continuous Deployment with Agent for Kubernetes and GitLab pipeline
The globally shared set of GitLab runners for CI/CD jobs works well for building binaries, publishing images, and reaching out to publicly available endpoints for services and infrastructure building. But the ability to run a private, self-managed runner can grant pipelines entirely new levels of functionality on several fronts: Can communicate openly to private, internal … GitLab: self-managed runner for CI/CD jobs on GCP VM instances
If you have a previous investment in Ansible Configuration Management for command line automation, you may now want to invoke that same logic from a GitLab CI/CD pipeline. The cleanest way to provide Ansible to a pipeline job is to create a custom Docker image that contains all the Ansible binaries and required Galaxy modules. … GitLab: invoking Ansible from a GitLab pipeline job
When a GitLab CI/CD pipeline needs to persist job output or a rendered report, it will typically save it as an artifact on the job, or perhaps write it to an external storage service or as a GitLab Release archive. But it is also capable of pushing this file to its own git repository, stored … GitLab: add files to source repository as part of GitLab pipeline
The Gitlab documentation shows how to use a ‘dotenv’ artifact to pass values from one job to another in a CI/CD pipeline. In this article, I want to show an example of this method, but also another method using a custom artifact. dotenv artifact for passing variable between jobs Here is how a variable set … GitLab: passing values between two jobs in pipeline
GitLab CI/CD pipelines can be used to automatically build and push Docker images to the GitLab Container Registry. Beyond building a simple image, in this article I will show how to define a workflow that builds and pushes a multi-platform image (amd64,arm64,arm32) with manifest index to the GitLab Container Registry. This is enabled by using … GitLab: automated build and publish of multi-platform container image with GitLab pipeline
If you are within the context of a CI/CD tool, you may run into the scenario where a newly applied git tag has initiated a pipeline action. Depending on the tool, the pipeline will provide you with either a SHA of the last commit and/or the tag name – but not the branch where the … Git: find branch name of newly applied tag
The forked workflow is popularized by the Open Source community where your personal contributions are made by having your own personal fork of a repository and pushing a GitLab Merge Request to a central repository. A GitLab Merge Request can be submitted from the web UI by clicking on “Merge requests” and manually selecting the … GitLab: generating URL that can be used for Merge Request from fork to upstream
Gitlab has an official CLI tool that allows you to perform many of the operations you may currently perform in the web UI. Among its many uses, the ‘glab‘ utility will allow you to fork repositories, manage issues, merge PR, and create releases all from the console for ease of use or automation. Below I … GitLab: glab official CLI tool for repository operations