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. However, 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 nine metrics provided by Kubecost and the Prometheus query features of GitLab.
GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI/CD 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/CD jobs to run only on self-managed 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, it was not possible to configure a trigger job to wait on a manual action. This made it challenging to configure either downstream or child pipeline triggers to wait for a user to click on them before running.
In this release, we’ve added the ability to add
when: manual to trigger jobs. Use this keyword to make trigger jobs wait until you click on the play button. This gives you more control of your downstream and child pipelines, and they will only run when you want them to.
Engineers have complicated development environments that can take time to set up 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.
Try this today with the GitLab project which is already setup to work with Gitpod.
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 GitLab 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 allows you to attach binary assets making it easier for you to package and release your software with GitLab.
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.
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.
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-ruleset.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.