Petes Linkedin Blog

Today we are releasing versions 14.2.2, 14.1.4, and 14.0.9 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important security fixes, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately. GitLab releases patches for vulnerabilities in dedicated security releases. There are two types of security releases: a monthly, scheduled security release, released a week after the feature release (which deploys on the 22nd of each month), and ad-hoc security releases for critical vulnerabilities. For more information, you can visit our security FAQ . You can see all of our regular and security release blog posts here . In addition, the issues detailing each vulnerability are made public on our issue tracker 30 days after the release in which they were patched. We are dedicated to ensuring all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standard...

If there is one thing that recent cyberattacks at companies such as SolarWinds, Codecov, and Kaseya have taught us, it's that software build pipelines are being targeted for attacks more than ever before. Hackers are no longer just attacking the bits and bytes of source code that go into our products, but also the development, testing, and build infrastructure tools that used to build these products. Even if you believe your company that is at low risk of an attack, it's also important to think about your customers. Businesses with high profile customers – like government agencies or large, multinational corporations that use your products – might have attackers target them by hacking your company, or more specifically, the software you provide them. The incidents at Solarwinds, Codecov, and Kaseya show that traditional approaches to security are often failing to prevent attacks. Instead of targeting the software that these companies used, attackers targeted software develope...

Alpine Linux distribution is the base OS used by many Linux container images. It provides a handy packaging mechanism, new versions of software, and a quick and predictable release cycle – all while being distributed using a minimal image size. It's used by many very popular container images, for example docker:dind , widely used in GitLab CI/CD workloads handling container images building and management in the jobs. On June 15, 2021, Alpine Linux released version 3.14. As documented in the release notes , changes in the musl library require an updated version of runc or updated version of Docker for the Alpine 3.14-based images to work properly. Software products across the computer industry have started migrating their Alpine Linux-based container images to 3.14 since it includes significant updates for various network and security-oriented use cases. In cases where the GitLab Runner environment uses a Docker version older than 20.10.6 to handle new container images based ...

Today we are releasing version 14.0.8 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in the 14.0 release and prior versions. GitLab Community Edition and Enterprise Edition Revert backfill on ci_build_trace_sections Resolve "operator does not exist: integer[] || bigint in app/models/namespace/traversal_hierarchy.rb" Fix Sidekiq workers delete each other's metrics Geo 2.0 Regression - Add ability to remove primary Backport fix for flaky spec to 14.0 Important notes on upgrading This version includes a post deploy migration. For multi-node deployments, it should not require any downtime . Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for updates . Updating To update, check out our update page . GitLab s...

GitLab CI/CD technology has historically divided a pipeline into stages based on the typical development workflow. Now that GitLab 14.2 has launched , users can speed up cycle times by using the needs command to write a complete CI/CD pipeline with every job in the single stage. In fact, you can omit stages completely and have a "stageless" pipeline that executes entirely based on the needs dependencies. Understanding stages In GitLab CI/CD, you use stages to group jobs based on the development workflow and control the order of execution for CI/CD jobs. Pipelines execute each stage in order, where all jobs in a single stage run in parallel. After a stage completes, the pipeline moves on to execute the next stage and runs those jobs, and the process continues like this until the pipeline completes or a job fails. If a job fails, the jobs in later stages don't start at all. History of stages in GitLab CI/CD When we first designed GitLab CI/CD, we knew that in a con...

Today we are releasing version 14.2.1 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 14.2 release and prior versions. GitLab Community Edition and Enterprise Edition Adding upgrade messaging for PK migrations Don't override vulnerability feedback UUID anymore Reorder vulnerability check criteria Fix "getAction is undefined" bug Drop un-used db/ci_migrate symlink Fix migration NameError in rails env helper Bump Container Registry to v3.9.0-gitlab Important notes on upgrading This version does not include any new migrations, and for multi-node deployments, should not require any downtime . Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for updates . Updating To update, check out our ...

World-class CI/CD comes as a part of the GitLab DevOps Platform to help streamline how development teams build, test, and deploy their apps. GitLab Runner is the execution engine that "does the work," enabling you, as a developer, to run fast, scalable CI/CD pipelines on your on-premises infrastructure or the cloud. Historically, Apple developers on GitLab SaaS had to set up runners on their own macOS systems to execute CI/CD workflows, introducing additional cost and operational overhead. As organizations and teams develop more apps for the Apple ecosystem, the need to create and deploy quickly becomes more important. Introducing GitLab Build Cloud for macOS Beta Today, you can say goodbye to that Mac mini under your desk! We are pleased to announce the GitLab Build Cloud for macOS Beta, which provides an on-demand platform for building Apple products and is integrated with GitLab SaaS CI/CD. To ensure the best possible service to our open source community and customers,...

Today, we are excited to announce the release of GitLab 14.2 with introduction of the Build Cloud for macOS beta , Markdown preview , expanded Gitpod integration , new DevOps adoption metrics , and much more! These are just a few highlights of the 50+ improvements in this release. Read on to check out all of the great updates below. To preview what's coming in next month’s release, check out our Upcoming Releases page , which includes our 14.3 release kickoff video. Join us for an upcoming event This month's Most Valuable Person ( MVP ) is Cornelius Ludmann Cornelius added support for opening code changes directly in Gitpod when viewing a merge request. In fact, this release blog post was created and edited with Gitpod! Cornelius initially helped add an option to open a project in Gitpod to the repository overview page in GitLab 13.5 . That capability has now expanded so that you can launch Gitpod directly from the merge request page to speed up your reviews and red...