New version of GitLab 8.9
This text is a translation of the release post from the GuitLab blog. Translation prepared by Softmart. We understand that our translation is far from ideal, but we believe that even such translation will be useful to many who do not speak English sufficiently. Ivan Nemytchenko - nem - as far as possible the evangelist GitLab edits the text. If you are ready to offer your assistance in translating articles, we will be only happy. Thank you for understanding!
With GitLab 8.9, it’s more comfortable to work in large, complex projects. File locking, prioritization of tags, flexible settings for the level of involvement in the project, and the ability to prohibit merging of branches (merge) until the build is successful. In GitLab CI, you can now specify environments (production, staging, etc.) and set the expiration date of artifacts. There are CI settings templates, so starting it is now even easier.
Person of the month (MVP) - Rui Santos. He developed the ability to limit the unification of branches before the passage of the build. Thank you Rui!
')
Since version 8.8.0, 1761 commits have been added, 1947 files have been changed. What exactly has changed - see below.
The Git repository allows you to store non-text files (binary, for example), but cannot manage changes to them - you cannot compare file versions, you cannot merge changes from different file versions, etc. If you allow the editing of a file by several team members simultaneously, then it will take a lot of time to manually resolve version conflicts.
To get around this problem, we added the ability to manually lock files in GitLab. File locking does not allow anyone except you to change a specific file or a whole directory. This is also a clear way to announce that you are working on this file.
You are developing a game. A lot of people can be involved in the development of game levels. Lock the level file you are working on from the interface by clicking on “Lock”:
Colleagues will see that you are working on this file. Only you can push commits that change this file.
Is work on the level finished? Remove the lock!
A list of all locked files in the repository can be found in Repository → Locked Files:
The file blocking feature is only available in Enterprise Edition and on GitLab.com. We welcome your additional suggestions for extending this functionality.
In the previous version of GitLab, the notion of deployment environment appeared: test environment, acceptance environment and industrial operation environment. GitLab CI allows you to customize the deployment sequence (chain transitions between environments), within which the tasks of delivering and installing changes are performed.
In the new version 8.9 you can add additional Environments in the project CI configuration file (.gitlab-ci.yml). This will allow you to configure GitLab as closely as possible to the actual project environment and visually monitor the deployment dynamics in these environments.
In large projects with hundreds of requirements and thousands of tasks, it takes a lot of time to prioritize and determine the order of work when prioritizing each defect and each task separately. Try a new function of mass determination of priority with the help of special labels.
A priority label is the same text label, but with an indication of priority, which affects the sorting of objects to which this label is assigned.
For example, the highest priority for GitLab is P1. If you sort the defects by priority, then the top will display the defects with P1, then with P2, etc. Marking the “Security” label with a high priority of P1, defects belonging to this category will automatically receive the highest priority.
To keep abreast of important events for you, we added a new type of notification - user.
In previous versions of GitLab, it was possible to set up the Participant notifications (participating level), ie subscribe to events in the facilities in which you participate or in which you are mentioned.
In the new version 8.9, Gitlab allows you to configure notifications on a different principle - to mark the types of events of interest (new note, new defect, closing defect, new merging request, reassigning a defect, etc.)
Communication with project owners is now available from the project’s home page. If you need access to a project, contact the project owner without leaving GitLab. Requests are displayed in the project members section. The project owner is notified.
The continuous integration support module CI, embedded in GitLab, is managed using the .gitlab-ci.yml file, where the test, build and deployment objects are defined. To simplify the first steps in setting up this file, try using ready-made templates.
To get started with the .gitlab-ci.yml template, create a new file and name it .gitlab-ci.yml. You will see a drop-down list of titles of ready-made templates.
Basic navigation through project elements is carried out using the top bar. Pages that are configured specifically for the current user (defects, groups, activity, etc.) are now transferred to a new side pop-up panel.
GitLab now supports the universal 2-factor authentication standard (u2f). This means that you can use U2F security keys on Yubico, known as YubiKeys, as the 2nd factor when entering GitLab.
Read more about u2f support in our blog and GitLab 2-factor authentication documentation.
If you have multiple instances of GitLab, or you need a backup copy of the repository, then you can now import and export entire projects.
Go to the project settings page to export your project. Importing a project can be done from a new project page.
In the new version you have the opportunity to prohibit the merging of branches (merge) until the build is successful, Thanks Rui Santos.
More information about the other changes can be found in the Changelog. Below are only the most significant.
GitLab 8.9 includes the first release of Rouge since September (!) With support for more than 20 new languages, as well as support for new features of Swift, Ruby, Python and C / C ++, as well as some critical error fixes for Apache, JavaScript, Objective - C and Groovy.
Now you can vote on a separate comment in the defects and requests for the union, as well as respond to a specific person without distorting the course of the conversation, or conduct a quick survey.
Each defect and merge request can now be marked as “Todo” or “Done”.
With the prioritization function, tags play an increasingly important role in GitLab. To work with defects more efficiently, we added the possibility of mass label assignment.
If you use artifacts in GitLab embedded in CI, you may have a large archive of old data. Now you can specify the expiration date of the artifacts by adding the expire_in line to your own. gitlab-ci.yml file. Artifacts will be considered obsolete after a specified period of time.
You can specify the expiration date in different ways:
3 mins 4 sec
2 hrs 20 min
2h20min
6 mos 1 day
47 yrs 6 mos and 4d
3 weeks and 2 days
Note: this feature requires Runner 1.3 released simultaneously with GitLab 8.9
Now you can only have artifacts for failure, success or all events.
The default behavior is the same as before, creating only “success” artifacts.
Note: this feature requires Runner 1.3 released simultaneously with GitLab 8.9
GitLab 8.9 adds support for Manifest V1, spawned by older versions of Docker (until 1.10)
Mattermost 3.1 ships in GitLab 8.9 with multi-command accounts, Japanese translation, Apple Watch, with upgraded notifications, new hotkeys and a channel switcher, new display options, new emoticons, plus a security update and many other improvements.
Updating requires manual operations! Before updating surely read documentation for updating from versions to 8.9
With GitLab 8.9, it’s more comfortable to work in large, complex projects. File locking, prioritization of tags, flexible settings for the level of involvement in the project, and the ability to prohibit merging of branches (merge) until the build is successful. In GitLab CI, you can now specify environments (production, staging, etc.) and set the expiration date of artifacts. There are CI settings templates, so starting it is now even easier.
Person of the month (MVP) - Rui Santos. He developed the ability to limit the unification of branches before the passage of the build. Thank you Rui!
')
Since version 8.8.0, 1761 commits have been added, 1947 files have been changed. What exactly has changed - see below.
File locking (EE option)
The Git repository allows you to store non-text files (binary, for example), but cannot manage changes to them - you cannot compare file versions, you cannot merge changes from different file versions, etc. If you allow the editing of a file by several team members simultaneously, then it will take a lot of time to manually resolve version conflicts.
To get around this problem, we added the ability to manually lock files in GitLab. File locking does not allow anyone except you to change a specific file or a whole directory. This is also a clear way to announce that you are working on this file.
Example: Game assets
You are developing a game. A lot of people can be involved in the development of game levels. Lock the level file you are working on from the interface by clicking on “Lock”:
Colleagues will see that you are working on this file. Only you can push commits that change this file.
Is work on the level finished? Remove the lock!
A list of all locked files in the repository can be found in Repository → Locked Files:
The file blocking feature is only available in Enterprise Edition and on GitLab.com. We welcome your additional suggestions for extending this functionality.
Environments and Deployment in CI
In the previous version of GitLab, the notion of deployment environment appeared: test environment, acceptance environment and industrial operation environment. GitLab CI allows you to customize the deployment sequence (chain transitions between environments), within which the tasks of delivering and installing changes are performed.
In the new version 8.9 you can add additional Environments in the project CI configuration file (.gitlab-ci.yml). This will allow you to configure GitLab as closely as possible to the actual project environment and visually monitor the deployment dynamics in these environments.
Priority tags
In large projects with hundreds of requirements and thousands of tasks, it takes a lot of time to prioritize and determine the order of work when prioritizing each defect and each task separately. Try a new function of mass determination of priority with the help of special labels.
A priority label is the same text label, but with an indication of priority, which affects the sorting of objects to which this label is assigned.
For example, the highest priority for GitLab is P1. If you sort the defects by priority, then the top will display the defects with P1, then with P2, etc. Marking the “Security” label with a high priority of P1, defects belonging to this category will automatically receive the highest priority.
Custom Notification Type
To keep abreast of important events for you, we added a new type of notification - user.
In previous versions of GitLab, it was possible to set up the Participant notifications (participating level), ie subscribe to events in the facilities in which you participate or in which you are mentioned.
In the new version 8.9, Gitlab allows you to configure notifications on a different principle - to mark the types of events of interest (new note, new defect, closing defect, new merging request, reassigning a defect, etc.)
Request access to the project
Communication with project owners is now available from the project’s home page. If you need access to a project, contact the project owner without leaving GitLab. Requests are displayed in the project members section. The project owner is notified.
Gitlab-ci.yml templates
The continuous integration support module CI, embedded in GitLab, is managed using the .gitlab-ci.yml file, where the test, build and deployment objects are defined. To simplify the first steps in setting up this file, try using ready-made templates.
To get started with the .gitlab-ci.yml template, create a new file and name it .gitlab-ci.yml. You will see a drop-down list of titles of ready-made templates.
Changes in user interface navigation
Basic navigation through project elements is carried out using the top bar. Pages that are configured specifically for the current user (defects, groups, activity, etc.) are now transferred to a new side pop-up panel.
Universal 2-factor authentication support
GitLab now supports the universal 2-factor authentication standard (u2f). This means that you can use U2F security keys on Yubico, known as YubiKeys, as the 2nd factor when entering GitLab.
Read more about u2f support in our blog and GitLab 2-factor authentication documentation.
Import / Export Projects
If you have multiple instances of GitLab, or you need a backup copy of the repository, then you can now import and export entire projects.
Go to the project settings page to export your project. Importing a project can be done from a new project page.
Disable merging of branches until successful build
In the new version you have the opportunity to prohibit the merging of branches (merge) until the build is successful, Thanks Rui Santos.
Other changes
More information about the other changes can be found in the Changelog. Below are only the most significant.
Improved syntax highlighting
GitLab 8.9 includes the first release of Rouge since September (!) With support for more than 20 new languages, as well as support for new features of Swift, Ruby, Python and C / C ++, as well as some critical error fixes for Apache, JavaScript, Objective - C and Groovy.
Award Emoji in the comments
Now you can vote on a separate comment in the defects and requests for the union, as well as respond to a specific person without distorting the course of the conversation, or conduct a quick survey.
Manual Add Todos
Each defect and merge request can now be marked as “Todo” or “Done”.
Bulk label assignment
With the prioritization function, tags play an increasingly important role in GitLab. To work with defects more efficiently, we added the possibility of mass label assignment.
Duration of artifacts
If you use artifacts in GitLab embedded in CI, you may have a large archive of old data. Now you can specify the expiration date of the artifacts by adding the expire_in line to your own. gitlab-ci.yml file. Artifacts will be considered obsolete after a specified period of time.
You can specify the expiration date in different ways:
3 mins 4 sec
2 hrs 20 min
2h20min
6 mos 1 day
47 yrs 6 mos and 4d
3 weeks and 2 days
Note: this feature requires Runner 1.3 released simultaneously with GitLab 8.9
Keyword "When" for Artifacts
Now you can only have artifacts for failure, success or all events.
The default behavior is the same as before, creating only “success” artifacts.
Note: this feature requires Runner 1.3 released simultaneously with GitLab 8.9
Support Docker Registry Manifest V1
GitLab 8.9 adds support for Manifest V1, spawned by older versions of Docker (until 1.10)
GitLab Mattermost 3.1
Mattermost 3.1 ships in GitLab 8.9 with multi-command accounts, Japanese translation, Apple Watch, with upgraded notifications, new hotkeys and a channel switcher, new display options, new emoticons, plus a security update and many other improvements.
Updating requires manual operations! Before updating surely read documentation for updating from versions to 8.9
Source: https://habr.com/ru/post/305436/
All Articles