Petes Linkedin Blog

If you are wondering what area of DevSecOps has tremendous opportunity for impact, look no further than security of your software supply chain . "Software supply chain security practices, embodied as the SLSA or SSDF frameworks, are already seeing modest adoption but are not seeing universal adoption yet. There is still a lot of room for improvement there," said Todd Kuleza, a member of Google Cloud's DevOps Research and Assessment (DORA) team and a senior user experience (UX) researcher at Google Cloud. Kuleza, a co-author of the DORA team's 2022 State of DevOps Report , recently joined GitLab for a webcast to discuss software supply chain security adoption, including: Why teams choose CI/CD and other modern development processes to improve their security posture How automated security checks within integration and deployment help developers own security processes How to establish team security practices to reduce developer burnout Listen to the full webc...

One of the earliest forms of intelligence was to simply answer the question “How many?”. Counting is one of the first things that we learn as a child. As we grow older, we come to see this deceptively simple concept as somewhat childish. Yet, upon the concept of counting, the entire discipline of statistics is founded. In turn, every discipline that benefits from statistics owes a debt of gratitude to the very humble concept of counting. Many of the massive data lakes we keep are essentially vast amounts of counting. Using artificial intelligence to analyze this data, we frequently find insights we were not expecting. So it would seem that counting is somewhat of a fractal concept – it’s deceptively simple, but, when compounded, generates delightful things. So if we have a thing we are trying to be more intelligent about, our first endeavor might be to count it. Let’s see how to apply that to our code stored in GitLab. Why developers count code The following list is from real-world...

Today we are releasing version 15.8.3 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 15.8 release and prior versions. GitLab Community Edition and Enterprise Edition Deprecate backup upload using Openstack Swift and Rackspace APIs Note about Openstack and Rackspace API removal Updating nav and top level Update feature flag status of GitHub gists feature What's New post for 15.8 Add version note to email feature Revert changes on wiki replication/verification legacy code Handle client disconnects better in workhorse Attempt reading schema file instead of a file named #{report_version} Upgrade Alert - Add proper API support 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 “...

Today we are releasing versions 15.8.2, 15.7.7, and 15.6.8 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.com and GitLab Dedicated are already running the patched version. 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 custo...

Our world overwhelms us with information that is more accessible than ever. The increasing rates of content production and consumption are gifts that keep on giving. We can't seem to keep up with the information thrown at us. We're limited by our cognitive limitations and time constraints, and a recent study concluded the result is a shortening of attention spans. Websites are no exception. Users who interact with your website want feedback, and want it fast. Preferably immediately! Website performance has become an important factor in keeping users engaged. But how do you measure how unresponsive a page is before it becomes fully interactive? Many performance metrics exist, but this blog post focuses on Total Blocking Time (TBT). What is Total Blocking Time? TBT measures the total amount of time tasks were blocking your browser's main thread. This metric represents the total amount of time that a user could not interact with your website. It's measured between Fi...

In GitLab 15.7, we stopped expanding file type variables in CI jobs. CI jobs that rely on the old expansion method will generate errors and not work. Here is a look at how this change came about, the difference in job outputs, and what to do next. Background GitLab CI has long-supported file type CI/CD variables. This is a helpful feature for CI jobs, as a file variable is a simple way to pass values to an external system. In cases where there is a concern about environment variable size limits, putting the information in a file and using an environment variable to reference the file is a good option. Before 15.7, variable expansion expanded the contents of the file referenced in a file type variable. Some users found this expansion behavior to be quite valuable. In looking at some metrics on GitLab.com, for example, we saw over 1,000 unique projects that used a file variable inside another variable. However, other users did not find this unintended behavior helpful and implemented...

A typical organization looking to adopt GitLab already uses many other tools. Artifacts such as code, build pipelines, issues, and epics will already exist and be changed daily. A seamless transition of work in progress is, therefore, critically important when importing data. GitLab importers aim to make this process easy and reliable, ensuring data is imported quickly and with maximum care. At GitLab, a dedicated development team, named group:import, creates a seamless experience when importing data into GitLab or from one GitLab instance to another. This team continuously develops and improves the importing experience and keeps our importers up to date with new features and capabilities. Migrate groups by direct transfer Using group migration, you can import groups from one GitLab instance to another instance. The most common use case is to import groups from self-managed GitLab instances to GitLab.com (GitLab SaaS). With the group migration, you can migrate many groups in a singl...