Petes Linkedin Blog

Modern web applications come with a REST API which returns JSON. The format needs to be parsed, and often feeds into scripts and service daemons polling the API for automation. Starting with a new REST API and its endpoints can often be overwhelming. Documentation may suggest looking into a set of SDKs and libraries for various languages, or instruct you to use curl or wget on the CLI to send a request. Both CLI tools come with a variety of parameters which help to download and print the response string, for example in JSON format. The response string retrieved from curl may get long and confusing. It can require parsing the JSON format and filtering for a smaller subset of results. This helps with viewing the results on the CLI, and minimizes the data to process in scripts. The following example retrieves all projects from GitLab and returns a paginated result set with the first 20 projects: $ curl "https://gitlab.com/api/v4/projects" The GitLab REST API documentat...

At GitLab we believe in an inclusive approach for thriving as team members and contributing as part of the wider community. That’s why we are excited to highlight our GitLab Learn learning platform, which is newly available to the GitLab wider community. Now anyone can learn, and anyone can get certified! To get started visit GitLab Learn and create an account. Free Certification Pathways On GitLab Learn you’ll find learning paths and certifications that we make available to GitLab team members as well as the wider GitLab community. Here are some of the free certification and badge pathways you’re welcome to complete on the site, created by the GitLab Learning & Development Team : GitLab 101 and GitLab 201 certifications Diversity, Inclusion, and Belonging Training certification Remote Work Foundations badge Bias Towards Asynchronous Communication badge GitLab Technical Certification Pathways Over the past 12 months GitLab launched 6 new technical certifications , maki...

As an enthusiastic participant in the open source community, we were intrigued to learn about the Outreachy technology internships program , which focuses on women and underrepresented groups. It's a way GitLab can give back and as a bonus Outreachy's principles intersect with our Diversity, Inclusion and Belonging value . About the Outreachy program Initially, Outreachy began as the open source program for women (OPW) at GNOME . The program was successful and grew quickly. Today, Outreachy has grown into the largest global technology internships program that provides opportunities for women and underrepresented groups to work on open source projects. Currently, Outreachy is independently organized with the help of many volunteers, or sponsored help. For example, Cindy Pallares is a GitLab employee and helps with organizing Outreachy as a site reliability engineer. Outreachy is a paid technology internship program that runs twice a year for three months. During that time, ...

Today we are releasing versions 13.10.3, 13.9.6, and 13.8.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 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 secu rity 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, t he 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 stand...

   This blog post is Unfiltered    GitLab provides a lot of flexibility when it comes to defining and using variables. They are extremely useful for controlling your jobs and pipelines, and they help you avoid hard-coding values in your .gitlab-ci.yml configuration file. Through this post, I aim to weave a larger picture by bringing together all (or most) of the information around defining and handling variables so it is easy to understand the scope and capabilities. To avoid overloading readers with information, the documentation is surfaced contextually depending on the task in focus. In GitLab CI/CD , variables can be used to customize your jobs by defining and storing values that they could make use of. When you use variables, you don't have to hard code values. In GitLab, these variables could be defined by going to Settings » CI/CD » Variables , or by simply defining them in the .gitlab-ci.yml file. Variables are useful for configuring third par...

This is the first in our three-part series on accessibility in software devlopment. For software to be considered open source , it must not discriminate against any people, groups, or fields of endeavor. In other words, open source software must be available and accessible to all users, which includes people living with disabilities. In many ways, the open source community and technologists focused on accessibility are a natural pairing: The more accessible the product, the greater number of users benefit, and input from a diverse group of users is necessary to build a product that is truly accessible. "A distinguishing feature of open source software versus proprietary software is that open source software tends to be used by a diverse community of users with different priorities, needs, use cases," says Greg Myers , support engineer at GitLab. "I personally feel the more diverse and inclusive that community is, the better the end product is." Engineers that dra...

   This blog post is Unfiltered    A while ago, I worked closely with the Growth:Expansion team on improving the experience of inviting users to GitLab. I first went through the existing experience of a user that’s inviting their team to GitLab and found a few opportunities for improvements. The work could have ended there, but I felt uneasy about it in the days after completing it. I felt that there was more to it, so I dug in again. This time, I wanted to explore what the experience was across many users involved in the process, instead of just the inviting user. Multi-user journey map So instead of mapping out a single-user journey map, I mapped out the journey as it was then for all the users involved. I came up with the following: Take a look at the multi-user journey map on Mural . I wanted to see what it was like for non-admin users to invite their team to GitLab or assign some work to them (not all managers and leads are admin users). So a non-admin us...