GitLab kun je vergelijken met het bekendere GitHub, maar bevat een aantal subtiele verschillen. Het is een omgeving voor het beheren van Git-repositories on-premises, en wordt uitgegeven onder de MIT Expat-licentie en ontwikkeld in Ruby on Rails. Het is beschikbaar in twee versies, namelijk de gratis te gebruiken Community Edition en een betaalde Enterprise Edition met meer features gericht op grotere bedrijven. Deze twee smaken worden op deze pagina uiteengezet. Het ontwikkelteam heeft GitLab 8.11 uitgebracht met de volgende aankondiging:
GitLab 8.11 released with Issue Boards and Merge Conflict Resolution
There are so many good things in GitLab 8.11, that I struggle to introduce all this without turning to superlatives. So, without further ado:
With GitLab 8.11 you get a completely new way to manage your issues, you can resolve merge conflicts in the interface, you can restrict pushes to people and groups (in EE), you get an online IDE, you can use slash commands to modify issues and you can create as many issue templates as you want ..and many other new features.
This month's Most Valuable Person (MVP) is Clement Ho for his merge requests and responsiveness on issues. Thanks Clement Ho!
GitLab Issues are very flexible. You can crosslink them, prioritize them, and rank them by popularity. With the Issue Board we've added something new: You can now create workflows, quickly get an idea of the status of your issues and all that in a simple, beautiful Board, not unlike a Kanban or Scrum board.You have a board for every project, which starts with a Backlog with all open issues and a Done list, where issues are automatically closed. By adding new lists you can create workflows. Lists are based on labels, this means that adding an issue to a list will add that label to the issue and removing it from a list, will remove the label. This means all your current issues will automatically appear in new lists you create and that you can quickly see whether a certain issue is in one (or more!) of the lists. To see an example, have a look at the GitLab CE Issue Board for the next release (8.12).
Merge Conflict Resolution
Merge conflicts can be a real pain when you want to get something to merge in a busy project. We believe you shouldn't need any external tools to fix your conflicts, which is why you can now solve simple conflicts straight from GitLab. When you encounter a conflict, you simply click "Resolve these conflicts" to be able to select how you want the conflicts to be resolved. You confirm at the end to make a commit with your fix. We realize that this won't work for all conflicts, but hope that this will make the majority of your conflicts minor bumps in the road to getting your work to production.
Branch Permissions for Users (EE only)
It's now possible to restrict pushing and merging to specific branches to specific users, using Branch Permissions in GitLab Enterprise Edition. This works hand-in-hand with the existing functionality and can easily be combined with our restrictions. This means that you can restrict direct pushes to only Jane and John, but allow all masters or even developers to merge through a merge request to the branch. For each action (push and merge) you can allow any amount of users and permissions, making this a very powerful addition to GitLab EE for organizations.
Resolve Discussions in MRs
Discussions on diffs in merge requests can be hard to keep track of, yet it's important that you actually give each comment attention. To make it easier to find, fix, and resolve those comments and discussions, we've added the ability to do just that: Each comment and discussion on merge request diffs can be resolved. Longer threads can be resolved all at once or just comment-by-comment. We keep track of how many discussions you still need to resolve and added a convenient button to jump to the next unresolved discussion.
Pipelines in GitLab can be complex structures with many sequential and parallel builds. To make it a little easier to see what is going on, you can now view a graph of a single pipeline and its status. Simply click on a pipeline in your merge request or pipelines view to view the graph for the current pipeline.
Issue and MR Templates
To standardize on a certain format for issues and merge requests, you could already create templates in GitLab Enterprise Edition. With GitLab 8.11, we're bringing the ability to create multiple templates (for instance, one for feature proposals, another for bugs) to GitLab.com, GitLab CE, and EE. Templates are Markdown files (.md) that live in the repository in a .gitlab directory and either the .gitlab/issue_templates or .gitlab/merge_request_templates subdirectory. They will appear in a dropdown when creating a new issue or merge request. This should make it easier for everyone to submit good-looking feature requests, bug reports, and merge requests.
Inspired by chat tools, such as IRC, HipChat, Mattermost, and Slack, we've added our own version of slash commands to GitLab. This means you can quickly change labels, milestones, assignees and more by just writing a comment or by having a command when writing your merge request or issue. Use them in comments or even when creating a new issue or merge request.You can have multiple commands in a single comment and do things like changing the title of an issue, adding or removing labels and changing assignees. Here are some ideas on using the new slash commands: In your email while replying to an issue TODO doc link; Try having some in a template; Through the notes API. We can't wait to see how you'll use them.
Koding allows you to run your entire development environment in the cloud, share it with your team, and even use your local editor. This means that you don't have to spend hours setting up your stack on every new machine and every change. With GitLab 8.11, we're introducing the Koding integration with GitLab. This means that you can check out a project or just a merge request in a full-fledged IDE with the press of a button. The Koding integration is not on GitLab.com at present. Enable Koding in Admin > Application settings. Set it up for your project. And now you're able to quickly check out any merge request, branch, and commit in a complete IDE, that even allows you to use your local editor.
Pipelines in MRs
You will now see your Pipelines in merge requests! Click on a pipeline to see its graph and related builds.
Deployment status in Merge Requests
You can now easily set the URL of your environments. Which helps if you deploy automatically after a merge request is merged, as now GitLab will show the state of the deploy in your merge requests. With the URL configured, GitLab will link to the environment, so you can see the result of a merge request with a single click.
Pipelines Web Hooks
To make it easier to integrate the power of GitLab's pipelines, we've added a webhook for pipelines. It'll fire whenever a pipeline is created, is running or is finished. Enable any webhooks by going to the settings dropdown in your project and selecting Webhooks.
Code Highlighting and Collapsing
The editor in GitLab now properly highlights code and allows you to collapse blocks of code.
MR links when pushing
You'll now see a link to quickly create a new merge request and any related merge requests when you push to GitLab.
GitLab can now generate a nice looking coverage badge, so you can easily show off the test coverage of your projects anywhere. If you didn't know GitLab could report coverage yet, set it up in your pipelines settings: pipelines/settings.
Expiration date on Memberships
When giving a user access to a project or when sharing a project with a group, you can now limit that access to a certain date, setting an expiration date. After the date, the user or group will no longer have access to the project. This should make it easier to manage sharing projects with temporary team members.
Move projects between shards (EE only)
With GitLab 8.10 we introduced multiple mount points in GitLab. With GitLab 8.11 you can move projects between shards with a rake command. This is not something for everyday use, but it is convenient if you want to test a new shard or want to move that super-heavily used project over to faster storage.
In this release we've added another batch of significant performance improvements. Merge requests and their diffs are faster! Below some graphs that show the difference for when we deployed GitLab 8.11 RC2 to GitLab.com (the drop is the deploy).
See below for detailed improvements and the merge requests of the implementations.
- Checking if a user can read multiple issues has been improved
- Looking up a user's maximum access level has been improved
- Displaying CI charts now uses fewer SQL queries
- Various improvements have been made to GitLab's Git handling to use fewer Git operations and use faster sorting of version numbers
- Commit authors are cached per Sidekiq transaction to avoid extra lookups
- The number of queries used for displaying merge request diffs has been reduced
- Iterating over diff collections has been improved
- The performance of various methods that only depend on diff statistics has been improved
- Diff rendering performance has been improved by removing redundant checks for text blobs
- Certain method calls that are not needed when rendering diffs have been removed
- Checking if a diff note is active has been improved
- Improve rendering of issue tracker links
- Performance of parsing URLs in Markdown documents has been improved
- Performance of syntax highlighting code blocks in Markdown documents has been improved
- Generating of cache keys for Markdown documents has been improved
- Sorting of Git tags has been improved
- Trigram indexes (PostgreSQL only) for the ci_runners table have been removed
- Commit lookups in DiffHelper have been removed
- 45 redundant database indexes have been removed
- Caching of todo counters has been re-enabled
- Queries to get a list of todos have been improved by limiting the number of projects used in these queries
- SVG images larger than 2MB are no longer displayed, reducing loading times and memory usage
- A memory leak in the Markdown sanitization filter has been solved
- The dropdown used for displaying a list of projects an issue can be moved to uses pagination instead of loading all data at once
- Methods calls for finding Git blobs that were not needed have been removed
- The branches dropdown in the cherry pick and revert dialogues is now loaded asynchronously
- The queries used to mark todos as done have been improved
- gitlab_git has been updated to 10.4.7 to take advantage of various improvements made to this library
- Git access checks in Enterprise Edition have been improved
- An unnecessary index on the geo_nodes table has been removed
- Sidekiq now caches certain objects per transaction. This is enabled by default but can be disabled using an environment variable
- GitLab can now process a request using ruby-prof, storing the profiling data on disk so it can be viewed later on. This requires a token to be specified in a header to work
- GitLab Performance Monitoring can now track custom events such as the number of Git pushes, projects being forked, etc
- Nokogiri has been instrumented
- The overhead of method call instrumentation has been reduced
- The Repository class has been instrumented
- Gitlab::Highlight has been instrumented
- Project.visible_to_user has been instrumented again
We are also releasing GitLab Runner 1.5 today.
GitLab Mattermost 3.3
GitLab 8.11 includes Mattermost 3.3, an open source Slack-alternative whose newest release includes Chinese, Korean and Dutch translation, a Golang bot, flagged posts, @here mentions, plus many more new benefits. This version also includes security updates and upgrade from earlier versions is recommended.
Redis Sentinel Support
GitLab now has experimental support for Redis Sentinel.
This release has more improvements, including security fixes. Please check out the Changelog to see the all named changes.
To upgrade to GitLab 8.11, downtime is required due to migrations. The downtime for GitLab.com (the largest GitLab instance) was about 15 to 30 minutes. It may take less time depending on the amount of data on your instance. Some columns are removed by one migration which may affect users running a version of GitLab that was still using said column. Two other migrations populate newly created tables based on existing data, as such they require downtime to ensure this data isn't modified while the migration is running (and until 8.11 is deployed to the user's cluster). Finally another migration adds two foreign keys, which requires downtime as this is not done in a concurrent manner.
Ruby 2.1 deprecation
With this release of GitLab, we're upgrading to Ruby 2.3. For manual installations, we strongly suggest you update Ruby to 2.3 with this release. Omnibus installations will be automatically on Ruby 2.3. Support for Ruby versions below 2.3 (2.1, 2.2) will stop with GitLab 8.13.
2FA enforced through API and Git over HTTP
Users with 2FA enabled trying to retrieve an API token via the /sessions endpoint or the Resource Owner Password Credentials flow provided by OAuth2, will not be able to login. They will be required to use a Personal Access Token from now on.
(EE Only) Elasticsearch reindexing
We changed the structure of Elasticsearch indexes, making use of parent/child relationships. This has performance advantages, but requires a total rebuild of the ES index. After upgrading to GitLab 8.11, you will need to remove the old indexes and rebuild new indexes.
Note We assume you are upgrading from the latest version. If not, then also consult the upgrade barometers of any intermediate versions you are skipping. If you are upgrading from a GitLab version prior to 8.0 and you have CI enabled, you have to upgrade to GitLab 8.0 first.
Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations file.