gitlab-runner
werf
gitlab-runner | werf | |
---|---|---|
47 | 15 | |
- | 3,916 | |
- | 0.7% | |
- | 9.8 | |
- | 3 days ago | |
Go | ||
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gitlab-runner
-
🦊 GitLab CI: Deploy a Majestic Single Server Runner on AWS
#!/bin/bash # ### Script to initialize a GitLab runner on an existing AWS EC2 instance with NVME disk(s) # # - script is not interactive (can be run as user_data) # - will reboot at the end to perform NVME mounting # - first NVME disk will be used for GitLab custom cache # - last NVME disk will be used for Docker data (if only one NVME, the same will be used without problem) # - robust: on each reboot and stop/start, disks are mounted again (but data may be lost if stop and then start after a few minutes) # - runner is tagged with multiple instance data (public dns, IP, instance type...) # - works with a single spot instance # - should work even with multiple ones in a fleet, with same user_data (not tested for now) # # /!\ There is no prerequisite, except these needed variables : MAINTAINER=zenika RUNNER_NAME="majestic-runner" GITLAB_URL=https://gitlab.com/ GITLAB_TOKEN=XXXX # prepare docker (re)install sudo apt-get -y install apt-transport-https ca-certificates curl gnupg lsb-release sysstat curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list >/dev/null sudo apt-get update # needed to use the docker.list # install gitlab runner curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash sudo apt-get -y install gitlab-runner # create NVME initializer script cat </home/ubuntu/nvme-initializer.sh #!/bin/bash # # To be run on each fresh start, since NVME disks are ephemeral # so first start, start after stop, but not on reboot # inspired by https://stackoverflow.com/questions/45167717/mounting-a-nvme-disk-on-aws-ec2 # date | tee -a /home/ubuntu/nvme-initializer.log ### Handle NVME disks # get NVME disks bigger than 100Go (some small size disk may be there for root, depending on server type) NVME_DISK_LIST=\$(lsblk -b --output=NAME,SIZE | grep "^nvme" | awk '{if(\$2>100000000000)print\$1}' | sort) echo "NVME disks are: \$NVME_DISK_LIST" | tee -a /home/ubuntu/nvme-initializer.log # there may be 1 or 2 NVME disks, then we split (or not) the mounts between GitLab custom cache and Docker data export NVME_GITLAB=\$(echo "\$NVME_DISK_LIST" | head -n 1) export NVME_DOCKER=\$(echo "\$NVME_DISK_LIST" | tail -n 1) echo "NVME_GITLAB=\$NVME_GITLAB and NVME_DOCKER=\$NVME_DOCKER" | tee -a /home/ubuntu/nvme-initializer.log # format disks if not sudo mkfs -t xfs /dev/\$NVME_GITLAB | tee -a /home/ubuntu/nvme-initializer.log || echo "\$NVME_GITLAB already formatted" # this may already be done sudo mkfs -t xfs /dev/\$NVME_DOCKER | tee -a /home/ubuntu/nvme-initializer.log || echo "\$NVME_DOCKER already formatted" # disk may be the same, then already formated by previous command # mount on /gitlab-host/ and /var/lib/docker/ sudo mkdir -p /gitlab sudo mount /dev/\$NVME_GITLAB /gitlab | tee -a /home/ubuntu/nvme-initializer.log sudo mkdir -p /gitlab/custom-cache sudo mkdir -p /var/lib/docker sudo mount /dev/\$NVME_DOCKER /var/lib/docker | tee -a /home/ubuntu/nvme-initializer.log ### reinstall Docker (which data may have been wiped out) # docker (re)install sudo apt-get -y reinstall docker-ce docker-ce-cli containerd.io docker-compose-plugin | tee -a /home/ubuntu/nvme-initializer.log echo "NVME initialization succesful" | tee -a /home/ubuntu/nvme-initializer.log EOF # set NVME initializer script as startup script sudo tee /etc/systemd/system/nvme-initializer.service >/dev/null <
-
Atlassian prepares to abandon on-prem server products
GitLab team member here, thanks for sharing.
> Still not a big fan of how stiff Yaml pipelines feel in Gitlab CI
Maybe the pipeline editor in "Build > Pipeline editor" can help with live linting, or more advanced features such as parent-child pipelines or merge trains.
If you need tips for optimizing the CI/CD pipeline, suggest following these tips in the docs https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.... or a few more tips in my recent talk "Efficient DevSecOps pipelines in cloud-native world", slides from Chemnitz Linux Days 2023 in https://docs.google.com/presentation/d/1_kyGo_cWi5dKyxi3BfYj...
> and that tickets for what seems like a simple feature [1] hang around for years, but it is nice.
Thanks for sharing. (FYI for everyone) The linked issue suggests a Docker cache cleanup script, which might be helpful. https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27332#n... -> https://docs.gitlab.com/runner/executors/docker.html#clear-t...
-
GitHub Actions could be so much better
If only competitors could do better...
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797
- SLOT77 ; Daftar Situs Judi Slot 777 Online Terbaik & Terpercaya 2023
- Gacor88 : Daftar Slot Gacor88 Terbaru Anti Boncos Gampang Maxwin Disini Bos
- SLOT GACOR88 ; SITUS SLOT GACOR 88 TERBARU DAN TERPERCAYA GAMPANG MENANG 2023
- SLOT4D : SITUS SLOT GACOR 4D TERUPDATE MUDAH MAXWIN NEW MEMBER X250 X500
- Gitlab runner in-depth - communication and CI_JOB_TOKEN
-
Caching of GitLab CI is too slow for rust build.
GitLab MR for the CACHE_COMPRESSION_LEVEL implementation
-
The GMP library's website is under attack by a single GitHub user
And in general just making caching stuff easier. I feel like it is unnecessarily complicated for example to cache apt-get in Gitlab which I assume makes most people not do it.
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/991#not...
werf
-
Is there a CD solution that can be (painlessly) fully automated between stages?
I am looking as well for this kind of tool. I just took a look today by exploring the CNCF landscape this tool : https://werf.io/ , I haven't used it, but it seems to take care of painful stuff like automatic versioning for example. (If someone here tried it, I will be happy to listen to your feedbacks)
-
Phabricator replacement? | Or OpenProject alternative? | issue tracking/code
Werf - um ok
-
Top 200 Kubernetes Tools for DevOps Engineer Like You
HybridK8s Droid - Intelligence foor your favourite Delivery Platform Devtron - Software Delivery Workflow for Kubernetes Skaffold - Easy and Repeatable Kubernetes Development Apollo - Apollo - The logz.io continuous deployment solution over kubernetes Helm Cabin - Web UI that visualizes Helm releases in a Kubernetes cluster flagger - Progressive delivery Kubernetes operator (Canary, A/B Testing and Blue/Green deployments) Kubeform - Kubernetes CRDs for Terraform providers https://kubeform.com Spinnaker - Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence. http://www.spinnaker.io/ werf - GitOps tool to deliver apps to Kubernetes and integrate this process with GitLab and other CI tools Flux - GitOps Kubernetes operator Argo CD - Declarative continuous deployment for Kubernetes Tekton - A cloud native continuous integration and delivery (CI/CD) solution Jenkins X - Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Tekton, Knative, Lighthouse, Skaffold and Helm KubeVela - KubeVela works as an application delivery control plane that is fully decoupled from runtime infrastructure ksonnet - A CLI-supported framework that streamlines writing and deployment of Kubernetes configurations to multiple clusters CircleCI - A cloud-based tool that helps build continuous integration and continuous delivery pipelines to Kubernetes.
-
Deployment Watching Tool
Check out https://werf.io/ tool. It features giterminism which is somewhat similar to gitops, but it does not require pull model. Giterminism aims to improve reproducibility of your build and deploy configuration. werf also features content-based-tagging out of the box, which allows creating immutable images, stored in the container-registry, shared between multiple runners (werf uses distributed locking to prevent overriding image which is already published). Giterminism and content-based-tagging enables easy rollbacks to any git-commit in the history of your project. By design werf could be embedded into any ci/cd system.
-
werf is a CLI tool for implementing CI/CD with Kubernetes; its v1.2 became stable
Rename of dapp to werf was in Jan'19 to be precise (https://github.com/werf/werf/pull/1213).
- Werf
-
11 Open Source Kubernetes Ci Cd Tools To Improve Your Devops
Werf
-
Alternative to helmfile that works well with Github Actions
You can try werf, it has Helm under the hood and there are github actions available for it: https://github.com/werf/actions
-
werf as [yet another] way to build Docker images
As you know, there's plenty of tools that can be used to build your Docker images, besides the docker build itself. werf is an Open Source project with a long history (started in 2016 as a simple wrapper around Docker CLI). Still being a CLI tool, today it is focused not just on the building but also delivering these images to Kubernetes — and this is what makes it really different.
- Podman: A tool for managing OCI containers and pods
What are some alternatives?
woodpecker - Woodpecker is a simple yet powerful CI/CD engine with great extensibility.
argo-cd - Declarative Continuous Deployment for Kubernetes
kaniko - Build Container Images In Kubernetes
flux2 - Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
singularity - Singularity has been renamed to Apptainer as part of us moving the project to the Linux Foundation. This repo has been persisted as a snapshot right before the changes.
terraform-controller - Use K8s to Run Terraform
onedev - Git Server with CI/CD, Kanban, and Packages. Seamless integration. Unparalleled experience.
cockpit-podman - Cockpit UI for podman containers
Fabric - Simple, Pythonic remote execution and deployment.
machine
fleet - Deploy workloads from Git to large fleets of Kubernetes clusters