For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com. Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level. Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience.
In Gitlab 13.5, we are so excited to bring you group wikis! With 680 upvotes this was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation. We’ve worked tirelessly over the past year to make it happen and now we can’t wait to get it in your hands and hear your feedback.
Group-level wikis open up tons of possibilities to keep your information at a higher level and accessible to a broader set of people. A few examples of what you can put in your group wikis include team-specific information, coding style guides, and designs for your brand or your company.
We know a lot of folks have been looking forward to this feature and shared their input pre-release. We hope all of you will continue to weigh in now that group wikis are available and we’ve opened up a dedicated issue for your feedback.
Last month we introduced the GitLab Kubernetes Agent for self-managed GitLab instances installed with Helm. This release adds support for the official Linux package. In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster. You can learn more about how the Kubernetes Agent works now and check out our vision to see what’s in store.
Many users created their own scripts to better understand their cluster costs, but now you can see an overview of your cluster costs and resource usage in the GitLab user interface. Our integration builds on Kubecost’s
cost-model and gives you flexible insights into various levels of your clusters. Use the provided cost template to see your monthly node costs and the costs of your GitLab Managed Apps, or build more elaborate custom dashboards with the 9 metrics provided by Kubecost and the Prometheus query features of GitLab.
Asking a colleague to review your code should be a routine part of contributing code, but it’s often needlessly complex. A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? comment? chat message? Without a formal process, reviews can be inconsistent and hard to keep track of. One option is to assign a reviewer to a merge request, but when both authors and reviewers appear in the same assignee field it makes it hard for other team members to know who’s doing what.
GitLab 13.5 introduces merge request “reviewers,” which allow authors to request a review from someone. The new “reviewers” field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request. This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.
Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center. You can follow along in the merge request reviewer assignment epic for more details.
GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI pipeline jobs. These runners, visible in the GitLab.com UI as “shared runners,” are enabled by default and can be disabled for each project. However, some organizations require their CI jobs to run only on self-hosted runners, and so disabling the use of instance level shared runners on each project resulted in unnecessary administrative overhead. Now, administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis.
Previously, you were unable to configure a trigger job to wait for a manual action with
when: manual. In this release, we’ve added this capability to give you full control on when to run a downstream pipeline.
Engineers have complicated development environments that can take time to setup and make testing changes or exploring new projects challenging. Often getting started with a project involves following documentation, installing dependencies, and hoping there are no conflicts with other services running. This process can be time consuming, error prone, and may not replicate the configuration accurately to test and contribute to a project. With Gitpod integrated into GitLab, you can easily launch your Gitpod Workspace directly from the GitLab interface. When editing a project on GitLab a new dropdown option exists to open that project in GitPod:
Gitpod allows you to define your project’s configuration in code so you can launch a prebuilt development environment with one click. These environments are configured through a
.gitpod.yml file inside of the project and include options for docker configuration, start tasks, editor extensions and more. This flexible configuration, which is part of the project’s code, allows developers to get started working on a project quickly.
Engineers often use Snippets to share examples of code, reusable components, logs, and other items. These valuable pieces of information often require additional context and may require more than one file. Sharing a link to multiple files or multiple Snippets makes it challenging for users to piece this context together and understand the scope of what is being presented.
In GitLab 13.0 we laid a foundation for Snippets by giving them version control support based on a Git repository. Version control and the history it provides are an important piece of context when looking at code and understanding its purpose, but it may not be everything. GitLab now supports multiple files inside of a single Snippet, so you can create Snippets composed of multiple parts. It broadens its use to endless possibilities. For example:
- A snippet that includes a script and its output.
- A snippet that includes HTML, CSS, and JS code, from which the result can be easily previewed.
- A snippet with a
docker-compose.ymlfile and its associated
gulpfile.jsfile coupled with a
package.jsonfile, which together are used to bootstrap the project and manage its dependencies.
Providing all of these files in a single Snippet gives more options for the types of content that can be shared and the context that is provided when looking at them. We’re excited to see the types of content you will create and share using Snippets with Multiple Files!
GitLab supports a wide variety of languages in our Package Registry offering. However, you may want to store other binary types in GitLab that are not yet supported. In 13.5, you now have the ability to add raw package feeds (like you could do in Nexus) to a Generic Package Registry. Looking forward, this feature helps create the foundation for Release Assets and will ultimately make it easier for you to package and release your software with GitLab.
When you use the
percent rollout strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy. We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.
In GitLab 11.4, we introduced Feature Flags. In GitLab 12.2, we introduced percent rollout and user ID Feature Flag strategies. In GitLab 13.1, we introduced Feature Flag user lists and support for multiple Feature Flag strategies per environment.
Earlier this year, we committed to moving 18 features to our open source Core product and took the first step in delivering on this promise by making Feature Flags available in Starter in the last release. Now, we’ve officially finished moving Feature Flags to our Core offering. We’re excited about making these features available to more of the GitLab community and seeing the positive impact it’ll have on your development workflow.
To help you deploy to AWS Elastic Cloud Compute (EC2) more efficiently, we created a template that shows you how to get started. This template allows you to provision your own infrastructure by first leveraging the AWS CloudFormation API. You then push your previously built artifact to an AWS S3 bucket and deploy the content to an AWS EC2 instance.
Users can include the template in their configuration, specify a few variables, and their application will be deployed and ready to go in no time.
If you aren’t currently using GitLab for your releases because you can’t attach binaries to releases, your workflow just got a lot simpler. You now have the ability to attach binaries to a release tag from the
gitlab.ci-yml. This extends support of Release Assets to include binaries, rather than just asset links or source code. This makes it even easier for your development teams to adopt GitLab and use it to automate your release process.
GitLab Static Application Security Testing (SAST) and Secret Detection now support customizing detection rules. This allows GitLab users to change the vulnerability detection defaults to tailor results to their organization’s preferences. SAST custom rulesets allow you to exclude rules and modify the behavior of existing rules. Secret Detection now supports disabling existing rules and adding new regex patterns that allow the detection of any type of custom secret.
Custom rulesets can be defined by adding a new file to the
.gitlab folder named
secret-detection-rulesets.toml containing customizations written in the correct notation. You can learn more about this file format and see examples in our documentation for SAST custom rulesets and Secret Detection custom rulesets. We intend to provide additional support for importing custom rulesets in
.gitlab-ci.yml files in the future.
GitLab SAST now supports mobile applications including iOS apps written in Objective-C and Swift as well as Android apps written in Java and Kotlin powered by the Mobile Security Framework (MobSF). Initially this analyzer supports source code analysis but we intend to expand support for binary scanning of
.apk files in the near future. This feature was a generous contribution by the H-E-B Digital team. You can read more about integrating with GitLab Secure and view our Secure scanning integration documentation.