Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

GitLab 10.7 Released With Open Source Web IDE and SAST for Go and C/C++

DZone's Guide to

GitLab 10.7 Released With Open Source Web IDE and SAST for Go and C/C++

See what this release adds, like the ability to redirect HTTP connections to HTTPS for GitLab Pages with a simple checkbox, increasing security.

· DevOps Zone ·
Free Resource

Do you need to strengthen the security of the mobile apps you build? Discover more than 50 secure mobile development coding practices to make your apps more secure.

Contributing features, reviewing changes, and deploying code is a day in the life of a developer. Today we are making these tasks easier and more efficient with an amazing Web IDE, more flexible pipelines, additional security testing, and so much more.

Web IDE Is Now Open Source and Generally Available

At GitLab, we want everyone to be able to contribute, whether you are working on your first commit and getting familiar with git, or an experienced developer reviewing a stack of changes. Setting up a local development environment, or needing to stash changes and switch branches locally, can add friction to the development process. Using the Web IDE you can change multiple files, preview Markdown, review the changes and commit directly all from a browser. You can even open the diff from a merge request and get a side by side view of the changes. The Web IDE is generally available in 10.7 and is now open source, so everyone can benefit.

Deploy Tokens

For any organization working with containers, their registry is a key component in their infrastructure. It serves as a versioned repository, providing an easy and secure way of interacting with your container images. A common use for the registry is to serve images to an orchestrator like Kubernetes. It's important for Kubernetes to have access on an ongoing basis. For example, Kubernetes will pull an image on initial deployment, any time a pod restarts, or when scaling additional pods.

Previously there were two ways to grant access to the registry and repository. One way is the CI job token which provides temporary access for length of the job, after which it expires. Personal Access Tokens provide long-term access but are tied to a specific user. When using the CI Job Token, Kubernetes loses access once the CI job has completed, so ongoing events like pod restarts and scaling fail. Using Personal Access Tokens is also undesirable, because access has to be either shared with a user, or a separate service account must be created which takes up a license.

To address these needs more cleanly we have added Deploy Tokens, providing long-lived read-only authentication. With a Deploy Token, Kubernetes can now get the images it needs, when it needs them, without being associated with a particular user or having unnecessary access rights.

CI/CD flow control based on variables

A company's CI/CD service is the engine of their software engineering process, performing a wide variety of roles from building and testing software, deploying it to production, and frequently more creative tasks as well. With such a varied and open-ended set of uses, it is important for users to be able to run specific jobs only when they need to. GitLab CI/CD already provides a rich set of options for managing flow control, but there were some use cases like a nightly build that were not easy to address. In 10.7 jobs can now be started based on the value of specific variables, enabling new use cases like jobs specific to particular a pipeline schedule or API trigger.

SAST for Go and C/C++ Languages

As part of Complete DevOps, we are providing a great set of security tools out of the box. Static Application Security Testing (SAST) analyzes your source code for known vulnerabilities and outputs the results directly on the merge request for easy review. In order to analyze your code however, SAST needs to have support for your language. For this reason, we have been broadening the scope of SAST, and now support Go and C/C++.

This Month's Most Valuable Person (MVP) Is Rob Watson

This release’s MVP is Rob Watson. Rob added the ability to redirect HTTP connections to HTTPS for GitLab Pages with a simple checkbox, increasing the security of content served.

Thank you, Rob, for your contribution! We’ve sent Rob some GitLab swag as a thank you, including a hoodie, socks, and a handmade tanuki.

Web IDE Is Now Open Source

The new Web IDE makes it faster and easier to contribute small fixes and resolve merge request feedback by eliminating the need to stash changes and switch branches locally.

Using the Web IDE, you can change multiple files, preview Markdown, review the changes and commit directly from the browser. The Web IDE can be opened when browsing the repository, viewing a file, and directly from merge requests so that you can quickly resolve feedback or contribute a change while doing a code review. If you open a merge request in the Web IDE you can also preview the merge request diff before committing, which allows you to review the entire scope of the merge request directly in the Web IDE!

Introduced in GitLab Ultimate 10.4 the Web IDE is now Generally Available (GA). We decided to make Web IDE open-source because we believe building something so complex and personal as an IDE is only possible together. Plus, this lowers the bar for anyone to contribute to their favorite projects.

Read through the documentation on the Web IDE

Deploy Tokens

Projects may need to provide long-lived read-only access to the repository or to the Docker images uploaded to the GitLab Container Registry. Previously this required using Personal Access Tokens (PAT), but these are associated with a specific user account and also share their access.

Deploy Tokens, available in GitLab 10.7, solve this need by providing a permanent token that is tied to the specific project. Users can define if they want to enable repository or container registry access, revoke the token, or set an expiration date.

Read through the documentation on Deploy Tokens

Variables Support in "Only" and "Except" Keywords

GitLab CI/CD configuration allows you to define conditions to run a specific job, using the only and except keywords. For example, if you want a deploy job to run only on the master branch.

In GitLab 10.7, we have expanded the syntax to allow variable expressions that can be used to define conditional jobs based on the existence or value of a specific environment variable. For example, you may now define which jobs you want to run just by tuning project variables, or you can restrict a job to be scheduled only when theGITLAB_USER_NAME variable is equal to a specific user.

Read through the documentation on variables support.

SAST for Go and C/C++

Static Application Security Testing is effective only in the event that your project is using a programming language supported by one of the tools integrated into GitLab. That is why we are increasing their number with each release, adding the most commonly used languages.

In GitLab 10.7, projects written in Go and C/C++ can be automatically checked for security vulnerabilities. No need to specify the language, it will be autodetected at runtime for an easy user experience.

Read through the documentation on SAST

Other Improvements in GitLab 10.7

Comments in Epics

With this release, we continue to iterate on our portfolio management feature of Epics. Just like with issues, you can now comment on epics, and even start standalone, threaded discussions in an epic, just like in issues and merge requests. This allows you to have a conversation with your teammates, in an epic directly, at a higher abstraction level, before necessarily drilling down in an issue, or even creating one.

This new feature is also supported in the API.

Email notifications and todos are not yet supported in epics, and we are working on them right now.

Read through the documentation on Epics.

Custom Additional Text for All Emails

Often, organizations need to add a disclaimer or other related text to all email communications, for various operational or compliance requirements.

With this release, we’ve added this exact feature. GitLab admins can now go into email settings and paste in any custom text. That text will then appear at the bottom of all emails sent by GitLab.

Read through the documentation on custom text for emails.

Subgroup Issues in Group Issue Board

Group issue boards are a powerful feature to help you manage issues across multiple projects across a single group, all in one interface. This is helpful for teams where their work might come from multiple different code repositories (and thus GitLab projects).

Prior to this release, the issues in a group issue board only came from immediate child projects of that one group. With this release, all issues in projects in all subgroups of the current group also appear in that one group board. So if your work is structured in a group and project hierarchy with multiple levels reflecting your organization or software product, then this update will extend that hierarchy to the group issue board now, giving you more fine-grained control.

Read through the documentation on Issue Boards.

Assigning and Filtering by Subgroup Labels

Subgrouping is a powerful feature in GitLab, and we want to extend that functionality to how labels are applied in GitLab. With this release, we’ve made it extremely flexible to apply group labels to issues and merge requests at various subgroup levels.

In particular, for a given issue or merge request, you can now apply any group label from that object’s ancestor groups. This flexibility means that you can create a label at a given group level, and all objects in its subgroups will be able to use it.

Since in group issue lists and group merge request lists, you can already see objects belonging to subgroups, we’ve now also made it possible to filter on those lists by group labels that belong to both ancestor and descendant groups of the given group, since all those objects can have those labels now. In other words, GitLab gives you the power and flexibility to filter by any possible label assignable to those objects.

This filtering capability is also possible in group issue boards for both the filter bar and the board config.

Read through the documentation on Labels.

Project Badges

Many projects use badges, such as the GitLab CI/CD and shields.io to reflect the status of build and code quality. Typically these are added to the project README.

Now badges are a first-class citizen and can be displayed prominently below the project description, and can be templated at the group level too.

Read through the documentation on Project Badges.

Protected Branch Unprotect Permissions

Protected branches allow push and merge permissions to be restricted by branch, like preventing pushes directly to master, but any Master can bypass these rules by unprotecting the branch. The new unprotect restriction can be used to limit which users, groups and roles are allowed to unprotect a branch.

Unprotect restrictions can only be set using the API in 10.7, but will be available in the interface in an upcoming release. The admin access level (60) may be removed in a future release, as we are currently evaluating restrictions to the Owner role as an alternative.

Read through the documentation on Branch Protection.

Issue Weight in Issue Board Card

You can now view the weight in an issue board card. Previously, when using an issue board, to see the weight of an issue, you’d have to click on the issue, and see the weight in the sidebar that slides in. With this change, you can now see it in the board card itself. This makes it much more easy to quickly scan a board and see the weights of issues, giving you a rough sense of the work required in a given list of issues, which is helpful in methodologies such as Agile.

Read through the documentation on Issue Boards.

GitLab Plugins

Being open source means GitLab can always be improved by anyone, but not all customers want to upstream their changes, or they may want to iterate on them privately first. Up to now, this was only possible by running a fork of GitLab, which is hard to keep up to date.

Plugins allow you to respond to GitLab system hooks with a script stored on the GitLab server, so you can more easily extend GitLab to meet your needs, like automatically configuring custom protected branch rules whenever a new project is created.

Read through the documentation on Plugins.

HTTP(s) Git Protocol Always Available for CI/CD Jobs

With GitLab you can use either SSH or HTTP(s) to access your repositories. Sometimes GitLab administrators prefer to block HTTP(s) access for security reasons. For example, blocking HTTP(s) prevents users from disclosing their credentials due to an insecure client setup. However, blocking HTTP(S) also stopped GitLab Runner from cloning the repository, making CI/CD not work as expected.

Starting with GitLab 10.7, the HTTP(s) protocol will be allowed for clone/fetch requests coming from GitLab Runner, even if the same access is explicitly forbidden for users. This is not susceptible to the same type of insecure client vulnerability because GitLab Runner always uses OTP tokens that cannot be leveraged to perform attacks.

Read through the documentation on visibility and access controls.

Support for JSON Web Token OmniAuth

GitLab uses OmniAuth to allow users to sign into GitLab using popular services like Twitter and Google, as well as standard authentication solutions like OAuth2. In Gitlab 10.7, support for JSON Web Token (JWT) OmniAuth has been added.

JSON Web Token is a compact and self-contained way to securely transmit information and is commonly used for authentication between services.

Read through the documentation on JWT OmniAuth provider.

Automatic Background Verification of Geo Replicas

Automatic background verification of Geo replicas will now occur when Geo is enabled, to make sure that replicas remain consistent with the primary. This is important when using Geo for Disaster Recovery so that you can confidently failover to a secondary, knowing that it is a complete replica of your primary GitLab instance.

GitLab calculates a checksum for each Git repository using heads and tags and verifies that the checksum from the primary matches the checksum on each secondary. Verification will be expanded in upcoming releases to also include uploads and keep-around refs.

Read through the documentation on Geo background verification.

Group Project Creation in Starter

As part of providing additional flexibility around our permission model, this will allow group or server admins to set an option that will give users with Developer role the ability to create projects.

This feature was previously available in GitLab Premium only.

Read through the documentation on Groups.

Project Exports Include LFS Objects

Project exports allow you to move projects between GitLab instances conveniently, including issues, merge requests, labels, wikis, and uploads. Project exports now include LFS objects so that repositories with LFS objects can also be transferred using project exports.

Read through the documentation on project exports.

Dependency Scanning Is Now an Independent Feature

Before this release, security checks on external dependencies and libraries used by your application were done along with SAST. Even if they are related, we think that they should be clearly identified as two separate features.

GitLab 10.7 introduces Dependency Scanning as a first-class citizen in the Security reports, giving you information about vulnerable libraries that should be updated. Results will be available both in the merge request and in the pipeline view.

Read through the documentation on Dependency Scanning.

Runner-Specific Job Timeout

GitLab currently defines at the project level how long a CI/CD job can run. If a job execution exceeds this duration, it is automatically stopped and reported as failed.

GitLab 10.7 adds a new timeout setting on the runner itself, which applies to all jobs it runs. If this value is less than the project-level setting, it will override it. This is particularly helpful for shared runners, in order to prevent potential abuse with a project that has set long timeouts.

Read through the documentation on runner-specific job timeout.

Easily Get Failure Reasons for CI/CD Jobs

When a CI/CD job fails, users normally want to check what happened and commit a fix to make it succeed as expected. Before this release, they had to go into the job details and look at the logs.

To make the debugging easier and faster, GitLab 10.7 introduces the failure reason as part of the status badges, make it accessible on mouseover.

Read through the documentation on failure reasons for CI/CD jobs.

Ubuntu 18.04 Bionic support

Packages are now available for Ubuntu 18.04 Bionic, which is being released on April 26.

Install GitLab on Ubuntu 18.04 Bionic

Improvements to Restoring GitLab Backups

GitLab 10.7 now includes support for restoring to custom nested directories. For example, if your registry was located at /var/mypath/gitlab/registry, the restore will now succeed. Previously the task would try to rename the existing directory to <name>.<timestamp>, but it would not have permission. Now it will create a tmp folder in the backup directory, and move any existing files there prior to restoring the backup.

Read through the documentation on backup and restore.

GitLab Pages Automatic HTTPS Redirect

GitLab Pages can provide static websites via HTTP or HTTPS protocols. HTTPS is normally preferred since it encrypts all the traffic, protecting the content while it is transferred over the net.

In the case that both are available, in GitLab 10.7 users can force their projects to redirect HTTP requests on the related HTTPS url to improve security and guarantee no data is transferred in clear text.

Read through the documentation on GitLab Pages automatic HTTPS redirect.

Automatic Renewal of GitLab Let's Encrypt Certificate

In GitLab 10.5, we made it easy to enable HTTPS for your GitLab instance by integrating with Let’s Encrypt.

With GitLab 10.7, we are making it even easier by no longer requiring it to be explicitly enabled as well as automating the renewal process. All you need to do to enable HTTPS now is set your external_url to start with https://, and that’s it!

Read through the documentation on Let's Encrypt automatic renewal.

Cloud Native GitLab Chart Available for Core (Alpha)

With the introduction of Object Storage support to Core, the alpha cloud-native GitLab chart can now be used without a license. This chart features a more cloud-native architecture, with a container for each component of GitLab and no requirement for shared storage. These changes will result in increased resilience, scalability, and performance of GitLab on Kubernetes.

Read through the documentation on backup and restore.

Improvements to the Environment Metrics Dashboard

Summary statistics are now available on the environment metrics dashboard, displaying the average and maximum values of each series within the timespan. For example, it is now possible to quickly see the average response time for the past eight hours, to understand the experience most users are seeing.

Total Pod CPU and Memory consumption are now also displayed, providing insight into the resource usage of a particular environment in the cluster.

Read through the documentation on monitoring environments.

GitLab Runner 10.7

We’re also releasing GitLab Runner 10.7 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Most interesting changes:

List of all changes can be found in GitLab Runner’s CHANGELOG.

Read through the documentation on GitLab Runner.

Omnibus Improvements

  • GitLab Mattermost 4.8.1 includes several platform improvements, including an iOS endpoint that enables users to upload files larger than 20MB, plus much more.
  • The default ssl_ciphers list for NGINX has been updated, excluding ECDHE-RSA-DES-CBC3-SHA and DES-CBC3-SHA to address Sweet32.
  • redis_exporter has been updated to 0.17.1.

Read through the documentation on Omnibus GitLab.

Performance Improvements

Some of the more noteworthy performance improvements in GitLab 10.7 include:

See all the performance improvements in GitLab 10.7.

Custom Additional Text for All Emails

Often, organizations need to add a disclaimer or other related text to all email communications, for various operational or compliance requirements.

With this release, we’ve added this exact feature. GitLab admins can now go into email settings and paste in any custom text. That text will then appear at the bottom of all emails sent by GitLab.

Read through the documentation on custom text for emails.

Assigning and Filtering by Subgroup Labels

Subgrouping is a powerful feature in GitLab, and we want to extend that functionality to how labels are applied in GitLab. With this release, we’ve made it extremely flexible to apply group labels to issues and merge requests at various subgroup levels.

In particular, for a given issue or merge request, you can now apply any group label from that object’s ancestor groups. This flexibility means that you can create a label at a given group level, and all objects in its subgroups will be able to use it.

Since in group issue lists and group merge request lists, you can already see objects belonging to subgroups, we’ve now also made it possible to filter on those lists by group labels that belong to both ancestor and descendant groups of the given group since all those objects can have those labels now. In other words, GitLab gives you the power and flexibility to filter by any possible label assignable to those objects.

This filtering capability is also possible in group issue boards for both the filter bar and the board config.

Read through the documentation on Labels.

Protected Branch Unprotect Permissions

Protected branches allow push and merge permissions to be restricted by branch, like preventing pushes directly to master, but any Master can bypass these rules by unprotecting the branch. The new unprotect restriction can be used to limit which users, groups, and roles are allowed to unprotect a branch.

Unprotect restrictions can only be set using the API in 10.7 but will be available in the interface in an upcoming release. The admin access level (60) may be removed in a future release, as we are currently evaluating restrictions to the Owner role as an alternative.

Read through the documentation on Branch Protection.

GitLab Plugins

Being open source means GitLab can always be improved by anyone, but not all customers want to upstream their changes, or they may want to iterate on them privately first. Up to now, this was only possible by running a fork of GitLab, which is hard to keep up to date.

Plugins allow you to respond to GitLab system hooks with a script stored on the GitLab server, so you can more easily extend GitLab to meet your needs, like automatically configuring custom protected branch rules whenever a new project is created.

Read through the documentation on Plugins.

Support for JSON Web Token OmniAuth

GitLab uses OmniAuth to allow users to sign into GitLab using popular services like Twitter and Google, as well as standard authentication solutions like OAuth2. In Gitlab 10.7, support for JSON Web Token (JWT) OmniAuth has been added.

JSON Web Token is a compact and self-contained way to securely transmit information and is commonly used for authentication between services.

Read through the documentation on JWT OmniAuth provider.

Group Project Creation in Starter

As part of providing additional flexibility around our permission model, this will allow group or server admins to set an option that will give users with Developer role the ability to create projects.

This feature was previously available in GitLab Premium only.

Read through the documentation on Groups.

Dependency Scanning Is Now an Independent Feature

Before this release, security checks on external dependencies and libraries used by your application were done along with SAST. Even if they are related, we think that they should be clearly identified as two separate features.

GitLab 10.7 introduces Dependency Scanning as a first-class citizen in the Security reports, giving you information about vulnerable libraries that should be updated. Results will be available both in the merge request and in the pipeline view.

Read through the documentation on Dependency Scanning.

Easily Get Failure Reasons for CI/CD Jobs

When a CI/CD job fails, users normally want to check what happened and commit a fix to make it succeed as expected. Before this release, they had to go into the job details and look at the logs.

To make the debugging easier and faster, GitLab 10.7 introduces the failure reason as part of the status badges, make it accessible on mouseover.

Read through the documentation on failure reasons for CI/CD jobs.

Improvements to Restoring GitLab Backups

GitLab 10.7 now includes support for restoring to custom nested directories. For example, if your registry was located at /var/mypath/gitlab/registry, the restore will now succeed. Previously the task would try to rename the existing directory to <name>.<timestamp>, but it would not have permission. Now it will create a tmp folder in the backup directory, and move any existing files there prior to restoring the backup.

Read through the documentation on backup and restore.

Automatic Renewal of GitLab Let's Encrypt Certificate

In GitLab 10.5, we made it easy to enable HTTPS for your GitLab instance by integrating with Let’s Encrypt.

With GitLab 10.7, we are making it even easier by no longer requiring it to be explicitly enabled as well as automating the renewal process. All you need to do to enable HTTPS now is set your external_url to start with https://, and that’s it!

Read through the documentation on Let's Encrypt automatic renewal.

Improvements to the Environment Metrics Dashboard

Summary statistics are now available on the environment metrics dashboard, displaying the average and maximum values of each series within the timespan. For example, it is now possible to quickly see the average response time for the past eight hours, to understand the experience most users are seeing.

Total Pod CPU and Memory consumption are now also displayed, providing insight into the resource usage of a particular environment in the cluster.

Read through the documentation on monitoring environments.

Omnibus Improvements

  • GitLab Mattermost 4.8.1 includes several platform improvements, including an iOS endpoint that enables users to upload files larger than 20MB, plus much more.
  • The default ssl_ciphers list for NGINX has been updated, excluding ECDHE-RSA-DES-CBC3-SHA and DES-CBC3-SHA to address Sweet32.
  • redis_exporter has been updated to 0.17.1.

Read through the documentation on Omnibus GitLab.

Deprecations

Mattermost Configuration Changes

With the release of GitLab 11.0, the number of Mattermost configuration options supported within gitlab.rb will be reduced. We will continue to support the core configuration settings necessary to run Mattermost, and set up the integration with GitLab. Going forward, other configuration settings should be set directly within the Mattermost console, or passed as environment variables.

Presently with two applications attempting to write to the same config file, changes can be lost.

Due: GitLab 11.0.

Debian 7 Wheezy Support

GitLab 11.0 will be the last release with support for Debian 7 Wheezy.

Debian Wheezy will be end-of-lifed by the Debian project at the end of May.

Due: GitLab 11.0.

Upgrade Barometer

To upgrade to GitLab 10.7 from the latest 10.6 version, no downtime is required. To upgrade without downtime, please consult the documentation on downtimeless upgrades.

Note: There is an issue in 10.7.0 which causes Omnibus GitLab restores to fail if the backup includes container registry images. It will fixed in 10.7.1, and there is an interim workaround available.

For this release, we have migrations and post-deploy migrations.

GitLab.com migrations took approximately 3 minutes and post-deploy migrations amounted to a total of around 18 minutes. Background migrations, on the other hand, are sidekiq jobs that will run synchronously, for this release these migrations took around 4 days to complete, no side effects were expected nor present. One of the migrations targets older pipeline builds and newer executed pipelines are not affected.

GitLab Geo users, please consult the documentation on upgrading Geo.

Check out tips for blazing the way from agile to DevSecOps with security built into your mobile app toolchain.

Topics:
devops ,gitlab ,ide ,ci/cd ,version control

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}