Web ide gitlab что такое
GitLab Web Editor
Sometimes it’s easier to make quick changes directly from the GitLab interface than to clone the project and use the Git command-line tool. In this feature highlight, we look at how you can create a new file, directory, branch, or tag from the file browser. All of these actions are available from a single dropdown menu.
Create a file
From a project’s files page, click the ‘+’ button to the right of the branch selector. Choose New file from the dropdown. 
Enter a filename in the Filename box. Then, add file content in the editor area. Add a descriptive commit message and choose a branch. The branch field defaults to the branch you were viewing in the file browser. If you enter a new branch name, a checkbox displays, allowing you to start a new merge request after you commit the changes.
When you are satisfied with your new file, click Commit Changes at the bottom.
Shortcuts
You can use shortcuts when editing a file through the Web Editor. It uses the same shortcuts as the Web IDE. For details, read the documentation for Command Palette.
Template dropdowns
When starting a new project, there are some common files that the new project might need. GitLab displays a message to help you:
Highlight lines
Web Editor enables you to highlight a single line by adding specially formatted hash information to the URL’s file path segment. For example, the file path segment MY_FILE.js#L3 instructs the Web Editor to highlight line 3.
The Web Editor also enables you to highlight multiple lines using a similar pattern. In this case, the file path segment MY_FILE.js#L3-10 instructs the Web Editor to highlight lines 3 to 10 of the file.
Click Copy Link Address in the context menu.
Upload a file
The ability to create a file is great when the content is text. However, this doesn’t work well for binary data such as images, PDFs, or other binary file types. In this case, you need to upload a file.
From a project’s files page, click the ‘+’ button to the right of the branch selector. Choose Upload file from the dropdown:
After the upload dialog pops up, there are two ways to upload your file. Either drag and drop a file on the popup or use the click to upload link. After you select a file to upload, a file preview displays.
Enter a commit message, choose a branch, and click Upload file when you are ready.
Create a directory
To keep files in the repository organized it is often helpful to create a new directory.
From a project’s files page, click the plus button ( + ) to the right of the branch selector. Choose New directory from the dropdown.
In the new directory dialog, enter a directory name, a commit message, and choose the target branch. Click Create directory to finish.
Create a new branch
There are multiple ways to create a branch from the GitLab web interface.
Create a new branch from an issue
If your development workflow requires an issue for every merge request, you can create a branch directly from the issue to speed the process up. The new branch, and later its merge request, are marked as related to this issue. Once merged, the merge request closes the issue. You can see a Create merge request dropdown below the issue description.
To make this button appear, one possible workaround is to remove your project’s fork relationship. After removal, the fork relationship cannot be restored. This project can no longer be able to receive or send merge requests to the source project, or other forks.
This dropdown contains the options Create merge request and branch and Create branch.
Create a new branch from a project’s dashboard
If you want to make changes to several files before creating a new merge request, you can create a new branch upfront.
From a project’s files page, choose New branch from the dropdown.
To return to the file browser on this new branch, select Create branch.
You can now make changes to any files, as needed. When you’re ready to merge the changes back to your default branch, you can use the widget at the top of the screen. This widget only appears for a period of time after you create the branch or modify files.
Create a new tag
Tags help you mark major milestones such as production releases and release candidates. You can create a tag from a branch or a commit SHA:
From a project’s files page, choose New tag from the dropdown.
Select Create tag. GitLab redirects you to the tag list page.
Commit your changes, and GitLab redirects you to a new merge request form.
If you’d prefer to not use your primary email address for commits created through the web editor, you can choose to use another of your linked email addresses from the User Settings > Edit Profile page.
Web IDE
The Web Integrated Development Environment (IDE) editor makes it faster and easier to contribute changes to your projects by providing an advanced editor with commit staging.
Open the Web IDE
File finder
Command palette
You can see all available commands for manipulating editor content by pressing the F1 key when the editor is in focus. After that, the editor displays a complete list of available commands for manipulating editor content. The editor supports commands for multi-cursor editing, code block folding, commenting, searching and replacing, navigating editor warnings and suggestions, and more.
Some commands have a keyboard shortcut assigned to them. The command palette displays this shortcut next to each command. You can use this shortcut to invoke the command without having to select it in the command palette.
Syntax highlighting
As expected from an IDE, syntax highlighting for many languages in the Web IDE makes your direct editing even easier.
Because the Web IDE is based on the Monaco Editor, you can find a more complete list of supported languages in the Monaco languages repository. Under the hood, Monaco uses the Monarch library for syntax highlighting.
If you are missing Syntax Highlighting support for any language, we prepared a short guide on how to add support for a missing language Syntax Highlighting.
Themes
All the themes GitLab supports for syntax highlighting are applied to the Web IDE’s entire screen. You can pick a theme from your profile preferences.
| Solarized Dark Theme | Dark Theme |
|---|---|
 |  |
Highlight lines
WebIDE is built with the Web Editor. This enables WebIDE to share the same core features for highlighting and linking to particular lines in the edited files described for the Web Editor.
Schema based validation
The Web IDE provides validation support for certain JSON and YAML files using schemas based on the JSON Schema Store.
Predefined schemas
The Web IDE has validation for certain files built in. This feature is only supported for the *.gitlab-ci.yml files.
Custom schemas
Configure the Web IDE
Commit changes
After making your changes, click the Commit button on the bottom-left to review the list of changed files.
After you have finalized your changes, you can add a commit message, commit the changes and directly create a merge request. In case you don’t have write access to the selected branch, you see a warning, but can still create a new branch and start a merge request.
To discard a change in a particular file, click the Discard changes button on that file in the changes tab. To discard all the changes, click the trash icon on the top-right corner of the changes sidebar.
Reviewing changes
Before you commit your changes, you can compare them with the previous commit by switching to the review mode or selecting the file from the list of changes.
An additional review mode is available when you open a merge request, which shows you a preview of the merge request diff if you commit your changes.
View CI job logs
You can use the Web IDE to quickly fix failing tests by opening the branch or merge request in the Web IDE and opening the logs of the failed job. You can access the status of all jobs for the most recent pipeline and job traces for the current commit by clicking the Pipelines button in the top right.
The pipeline status is also shown at all times in the status bar in the bottom left.
Switching merge requests
To switch between your authored and assigned merge requests, click the dropdown in the top of the sidebar to open a list of merge requests. You must commit or discard all your changes before switching to a different merge request.
Switching branches
To switch between branches of the current project repository, click the dropdown in the top of the sidebar to open a list of branches. You must commit or discard all your changes before switching to a different branch.
Markdown editing
When editing, you can upload local images by pasting them directly in the Markdown file. The image is uploaded to the same directory and is named image.png by default. If another file already exists with the same name, a numeric suffix is automatically added to the filename.
Live Preview
You can use the Web IDE to preview JavaScript projects right in the browser. This feature uses CodeSandbox to compile and bundle the JavaScript used to preview the web application.
Additionally, for public projects an Open in CodeSandbox button is available to transfer the contents of the project into a public CodeSandbox project to quickly share your project with others.
Enable Live Preview
With Live Preview enabled, you can preview projects with a package.json file and a main entry point inside the Web IDE.
In GitLab 12.9 and later, third-party assets and libraries required for Live Preview are hosted at https://sandbox-prod.gitlab-static.net when it is enabled. However, some libraries are still served from other third-party services, which may or may not be desirable in your environment.
An example package.json :
Interactive Web Terminals for the Web IDE
Interactive Web Terminals give the project Maintainers user access to a terminal to interact with the runner directly from GitLab, including through the Web IDE.
Runner configuration
If you have the terminal open and the job has finished with its tasks, the terminal blocks the job from finishing for the duration configured in [session_server].session_timeout until you close the terminal window.
Web IDE configuration file
In the code below there is an example of this configuration file:
After the terminal has started, the console is displayed and we could access the project repository files.
When you use the image keyword, a container with the specified image is created. If you specify an image, it has no effect. This is the case when you use the shell executor.
Important. The terminal job is branch dependent. This means that the configuration file used to trigger and configure the terminal is the one in the selected branch of the Web IDE.
If there is no configuration file in a branch, an error message is shown.
Running interactive terminals in the Web IDE
If Interactive Terminals are available for the current user, the Terminal button is visible in the right sidebar of the Web IDE. Click this button to open or close the terminal tab.
If active, clicking the Start Web Terminal button loads the terminal view and start connecting to the runner’s terminal. At any time, the Terminal tab can be closed and reopened and the state of the terminal is not affected.
When the terminal is started and is successfully connected to the runner, then the runner’s shell prompt appears in the terminal. From here, you can enter commands executed in the runner’s environment. This is similar to running commands in a local terminal or through SSH.
While the terminal is running, it can be stopped by clicking Stop Terminal. This disconnects the terminal and stops the runner’s terminal job. From here, click Restart Terminal to start a new terminal session.
File syncing to web terminal
File changes in the Web IDE can be synced to a running web terminal. This enables users to test their code changes in a preconfigured terminal environment.
After you have configured the web terminal for file syncing, then when the web terminal is started, a Terminal status is visible in the status bar.
Limitations
The Web IDE has a few limitations:
Interactive Terminals is in a beta phase and continues to be improved in upcoming releases. In the meantime, the user is limited to having only one active terminal at a time.
LFS files can be rendered and displayed but they cannot be updated and committed using the Web IDE. If an LFS file is modified and pushed to the repository, the LFS pointer in the repository is overwritten with the modified LFS file content.
Вышел GitLab 10.7: Web IDE в открытом доступе и отчеты SAST для Go и C/C++
Добавление новой функциональности, ревью изменений и развертывание кода — все это стандартные рабочие процессы, с которыми ежедневно сталкиваются разработчики. С выходом данного релиза мы упрощаем их выполнение с помощью нашего Web IDE, более гибких конвейеров, дополнительного тестирования безопасности и многого другого.
Web IDE теперь в общем доступе и с открытым исходным кодом
Мы в GitLab хотим, чтобы каждый участник мог вносить свой вклад в рабочий процесс независимо от того, является ли он начинающим пользователем, который только знакомится с git и работает над своим первым коммитом, или опытным разработчиком, проводящим ревью целого набора изменений. Локальное выполнение таких задач, как настройка среды разработки или переключение между ветками, может усложнить процесс разработки. При помощи нашего Web IDE вы можете вносить изменения в файлы, делать коммиты, проводить ревью изменений и предпросмотр Markdown напрямую из браузера. Вы даже можете открыть дифф мерж-реквеста с наглядным отображением изменений side by side. Web IDE выходит в общий доступ с версии 10.7, также мы открываем доступ к ее исходному коду.
Токены развертывания
Для любой организации, работающей с контейнерами, их регистр является ключевым компонентом инфраструктуры: это версионный репозиторий, который предоставляет легкий и безопасный доступ к образам контейнеров. Обычное применение регистра — предоставлять образы (images) оркестровщику, например Kubernetes(https://kubernetes.io/). Важно, чтобы у этой системы всегда был доступ к регистру, поскольку тот же Kubernetes пуллит образы контейнеров при первичном развертывании, при каждом перезапуске пода и при добавлении дополнительных подов в процессе масштабирования.
Ранее существовало только два способа получения доступа к регистру и репозиторию. Одним из них является токен работы CI, который предоставляет временный доступ на время выполнения работы, а другим — токен личного доступа, который предоставляет конкретному пользователю доступ на неограниченное время. При использовании токена работы CI Kubernetes теряет доступ по завершению работы, так что такой вариант не подходит для повторяющихся событий, таких как перезапуски подов и масштабирование. У использования токенов личного доступа тоже есть минусы: либо доступ должен быть привязан к конкретному пользователю, либо требуется создание дополнительного аккаунта, на что требуется лицензия.
Для решения этой проблемы мы создали токены развертывания, предоставляющие продолжительное разрешение на чтение. При помощи токена развертывания Kubernetes может получать все необходимые образы по мере необходимости, без привязки к конкретному пользователю и без получения ненужных прав доступа.
Управление потоком выполнения CI/CD на основе переменных
Сервис CI/CD является одним из основных движущих элементов процесса разработки ПО. Он выполняет множество задач: от базовых, вроде сборки, тестирования и развертывания, до более творческих. Учитывая диапазон выполняемых задач, пользователям важно иметь возможность запуска определенных работ только по определенному требованию. GitLab CI/CD уже предоставляет большой набор настроек для управления потоком выполнения, однако существовали некоторые сценарии, такие как ночные сборки, настроить которые было не так просто.
В GitLab 10.7 мы добавили возможность запускать работы на основе значений определенных переменных. Это позволит выполнять новые сценарии, такие как запуск работ, относящихся к определенному расписанию или триггеру API.
SAST для языков Go и C/C++
Частью проекта Complete DevOps является предоставление первоклассных инструментов безопасности. Система статического тестирования безопасности приложений (SAST) проводит анализ вашего исходного кода на наличие уязвимостей и выводит результат напрямую в окно мерж-реквеста. Однако для того, чтобы провести этот анализ, SAST требуется поддержка языка программирования, на котором вы пишете. По этой причине мы добавляем поддержку Go и C/C++ для SAST.
(MVP) этого месяца — Rob Watson
Rob добавил чекбокс, позволяющий перенаправлять соединения HTTP на HTTPS для GitLab Pages, что повышает безопасность контента.
Спасибо, Rob! В знак благодарности мы отправили ему фирменные кофту, носки и тануки ручной работы с символикой GitLab.
Открыт исходный код Web IDE (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Новый Web IDE упрощает и ускоряет добавление небольших фиксов и работу с фидбэком по мерж-реквестам, поскольку убирает необходимость локального хранения изменений и переключения веток.
При помощи Web IDE вы можете вносить изменения в файлы, проводить предпросмотр Markdown, делать ревью изменений и проводить коммиты напрямую из браузера. Web IDE доступен в окнах просмотра репозиториев и отдельных файлов, а также в окне мерж-реквеста — все это позволяет быстро реагировать на фидбэк или вносить небольшие изменения прямо в процессе ревью кода. При открытии мерж-реквеста в Web IDE вы также можете просмотреть его дифф перед коммитом, что позволяет увидеть общую картину изменений мерж-реквеста прямо в IDE.
Изначально Web IDE был добавлен в GitLab Ultimate 10.4, а с данного релиза он выходит в общий доступ. Мы приняли решение сделать его исходный код открытым, поскольку мы верим в то, что только совместная работа позволяет создавать такую сложную и субъективную функциональность, как IDE. К тому же, это позволит большему количеству пользователей участвовать в работе над своими любимыми проектами.
Токены развертывания (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Бывают ситуации, в которых необходимо на продолжительное время предоставить доступ на чтение к репозиториям или образам Docker, загруженным в регистр контейнеров GitLab. Ранее для этого нужно было использовать токены личного доступа (Personal Access Tokens — PAT), однако такие токены привязаны к конкретному пользователю и его правам доступа.
Токены развертывания, добавленные в GitLab 10.7, решают эту проблему путем предоставления постоянного токена, привязанного к конкретному проекту. Пользователи могут включать доступ к репозиторию или регистру контейнеров, отбирать этот токен и устанавливать для него срок истечения.
Поддержка переменных для ключевых слов ‘only’ и ‘except’ (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab CI/CD позволяет устанавливать условия для запуска определенной работы при помощи ключевых слов ‘only’ и ‘except’. Например, вы можете разрешить запуск работы развертывания только в ветке ‘master’.
В GitLab 10.7 мы расширили синтаксические возможности таких условий, что позволяет использовать выражения с переменными, в которых выполнение работы зависит от наличия определенной переменной окружения или ее значения. Например, вы можете указывать, какие работы должны запускаться, при помощи изменения значений переменных проекта. Или же вы можете ограничить запуск определенной работы только теми случаями, когда значение переменной GITLAB_USER_NAME совпадает с именем определенного пользователя.
SAST для Go и C/C++ (ULTIMATE, GOLD)
Система статического тестирования безопасности приложений (SAST) работает только в том случае, когда в проекте используется язык программирования, поддерживаемый одним из инструментов GitLab. Поэтому в каждом релизе мы добавляем поддержку новых языков.
В GitLab 10.7 мы добавили поддержку Go и C/C++, так что теперь вы можете использовать автоматическую проверку уязвимостей для проектов, написанных на этих языках. Для подключения этой функциональности не требуется никаких дополнительных действий — язык определяется в рантайме автоматически.
Другие улучшения GitLab 10.7
Комментарии в эпиках (ULTIMATE, GOLD)
В данном релизе мы продолжаем работу по внедрению в эпики функциональности управления портфолио. Теперь вы можете добавлять комментарии к эпикам и даже создавать отдельные треды обсуждений эпиков, такие же, как для задач и мерж-реквестов. Благодаря этому стало возможным проводить обсуждения в самом эпике, на более высоком уровне абстракции, а не использовать для этого существующие задачи или, что еще хуже, создавать новые.
Эта функциональность также поддерживается API.
Эпики пока что не поддерживают todo и оповещения по почте, но мы работаем над этим.
Массовое добавление текста во все почтовые сообщения (PREMIUM, ULTIMATE, SILVER, GOLD)
Нередки случаи, когда организациям по различным причинам (от юридических до технических) требуется добавить дисклеймер или какой-либо другой текст во все их почтовые коммуникации.
В данном релизе мы добавили такую возможность: теперь администраторы GitLab могут ввести произвольный текст в настройках почты. Этот текст будет добавлен в конец всех писем, отправленных GitLab.
Задачи подгрупп в групповых досках задач (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Групповые доски задач предоставляют единый интерфейс управления задачами сразу нескольких проектов одной группы. Такой подход полезен для команд, в которых работа происходит в различных репозиториях (а значит и в различных проектах GitLab).
В предыдущих версиях GitLab, на групповую доску добавлялись задачи только непосредственно дочерних проектов этой группы (только один уровень). Начиная с данного релиза, на групповую доску добавляются задачи всех проектов всех подгрупп этой группы. Так что если вы используете сложную многоуровневую иерархию подгрупп, эта иерархия будет поддерживаться и групповыми досками задач.
Фильтрация и добавление меток для подгрупп (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Работа с подгруппами является важной фичей GitLab, и мы хотим применить похожий подход к использованию меток. Начиная с данного релиза мы расширили возможности добавления меток к задачам и мерж-реквестам на различных уровнях подгрупп.
В частности, стало возможным добавление групповых меток определенной группы любым ее дочерним задачам и мерж-реквестам. Это значит, метка, созданная на определенном уровне групп, будет доступна для всех подгрупп уровнем ниже.
Поскольку объекты, принадлежащие к подгруппам, отображаются в списках задач и мерж-реквестов, мы добавили фильтрацию этих списков по групповым меткам, принадлежащим как к дочерним, так и материнским группам (потому что все они теперь могут обладать такими метками). Другими словами, у вас есть возможность фильтрации по всем возможным меткам объекта, независимо от его расположения в иерархии.
Такой подход к фильтрации также доступен в групповых досках задач, как в окне фильтра, так и в настройках доски.
Значки проектов (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Многие проекты, например, GitLab CI/CD и shields.io используют значки (badges) для отображения статуса сборки и качества кода. Как правило, значки добавляются в README проекта.
Теперь можно подключить отображение значков под описанием проекта, а также их отображение для всех проектов группы.
Разрешения на снятие защиты с веток (PREMIUM, ULTIMATE, SILVER, GOLD)
На данный момент такие ограничения можно устанавливать только через API; мы добавим поддержку интерфейса в следующем релизе. Также есть вероятность, что в последующих версиях мы уберем уровень доступа Admin ( 60 ) и добавим ограничения для уровня Owner в качестве альтернативы.
Вес задач на карточках досок задач (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Ранее, при работе с доской задач, для просмотра веса определенной задачи нужно было нажать на ее карточку — ее вес отображался в боковом окне. Теперь он отображается на самой карточке. Благодаря этому нововведению, вы можете одним взглядом оценить вес всех задач на доске и количество работы, необходимой для их выполнения. Это особенно полезно для методологий вроде Agile.
Плагины GitLab (CORE, STARTER, PREMIUM, ULTIMATE)
Поскольку GitLab — проект с открытым исходным кодом, его может дополнять каждый. Но не все пользователи хотят сразу выносить свои изменения в общий доступ, они могут хотеть сначала лично попробовать, что получилось. До сих пор это можно было делать только за счет запуска отдельного форка GitLab, который довольно тяжело поддерживать в актуальном состоянии.
Плагины позволяют вам отвечать на системные хуки GitLab с помощью скрипта, который хранится на сервере GitLab — вы сможете легко расширять GitLab под ваши нужды. Например, автоматически настраивать собственные правила защищенной ветки, когда создаете новый проект.
Протокол Git HTTP(s) всегда доступен для работ CI/CD (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В GitLab для доступа к репозиториям вы можете использовать или SSH, или HTTP(s). Иногда администраторы GitLab предпочитают блокировать доступ по HTTP(s) из соображений безопасности. К примеру, блокировка HTTP(s) не позволит пользователям раскрыть их данные входа при работе через небезопасные настройки клиента. Однако, блокировка HTTP(s) также мешает GitLab Runner клонировать репозиторий, из-за чего CI/CD работает не так, как ожидается.
Начиная с GitLab 10.7 у clone/fetch реквестов от GitLab Runner будет доступ к протоколу HTTP(s), даже если такой доступ запрещен пользователям. С точки зрения безопасности это не одно и то же, поскольку GitLab Runner всегда использует токены OTP, которые не могут быть использованы для выполнения атак.
Поддержка JSON Web Token OmniAuth (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab использует OmniAuth для того, чтобы пользователи могли войти в GitLab с помощью популярных сервисов, например, Twitter или Google, а также с помощью стандартных средств идентификации типа OAuth2. В Gitlab 10.7 в OmniAuth добавлена поддержка JSON Web Token (JWT).
JSON Web Token — это компактный автономный способ защищенной передачи информации, часто использующийся для идентификации между разными сервисами.
Автоматическая фоновая проверка копий Geo (PREMIUM, ULTIMATE)
Автоматическая фоновая проверка копий теперь происходит во время работы Geo, чтобы удостовериться, что копия консистентна с исходником. Это важно при использовании Geo для аварийного восстановления: теперь при сбоях вы можете уверенно переходить на резервную копию — она такая же, как и основной инстанс GitLab.
С помощью heads и tags GitLab вычисляет контрольную сумму для каждого репозитория Git и проверяет, что контрольная сумма исходного инстанса совпадает с аналогичной для резервной копии. Проверка будет расширена в следующих релизах и будет также включать загрузки и keep-around ссылки.
Создание проектов в группах для Starter (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Наша модель прав доступа стала более гибкой: теперь администратор может включить в настройках опцию, которая позволит пользователям с уровнем доступа Developer создавать проекты.
Раньше эта функциональность была доступна только пользователям плана GitLab Premium.
Экспорт проектов включает объекты LFS (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Экспорт проектов позволяет вам с удобством перемещать проекты (вместе с задачами, мерж-реквестами, метками, вики-страницами и загрузками) между инстансами GitLab. Теперь в экспорт проектов входят и объекты LFS: вы сможете перемещать репозитории с LFS объектами с помощью обычного экспорта проектов.
Сканирование зависимостей стало независимой функциональностью (ULTIMATE, GOLD)
До этого релиза проверки безопасности внешних зависимостей и библиотек, используемых вашим приложением, происходили вместе с SAST. Даже с учетом того, что это тесно связанные друг с другом вещи, мы решили, что их нужно разделить на две независимых функциональности.
GitLab 10.7 представляет сканирование зависимостей в качестве отдельной выделенной части в отчетах безопасности, которая предоставляет информацию об уязвимых библиотеках, которые стоит обновить. Результаты будут доступны как в мерж-реквестах, так и в обзоре конвейера.
Специальные таймауты работ для runner (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В данный момент GitLab определяет сроки выполнения работ CI/CD на уровне проекта. Если работа выполняется дольше, она автоматически остановится с отчетом об ошибке.
В GitLab 10.7 появилась новая настройка таймаута на runner, применяющаяся ко всем работам, которые он запускает. Это особенно полезно для общих runner в целях предотвращения потенциальных злоупотреблений, когда проект устанавливает длинные таймауты.
Легче узнать причину падения работы CI/CD (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когда работа CI/CD падает, пользователи обычно хотят узнать, что случилось и сделать коммит исправления, после которого работа выполнится так, как ожидалось. До этого релиза для этого нужно было идти в детали работы и смотреть логи.
Чтобы сделать отладку проще и быстрее, GitLab 10.7 представляет новую возможность: причина падения указывается как часть статуса, который можно посмотреть целиком по наведению курсора.
Поддержка Ubuntu 18.04 Bionic (CORE, STARTER, PREMIUM, ULTIMATE)
26 апреля вышла новая версия Ubuntu — Ubuntu 18.04 Bionic. GitLab теперь доступен и для нее.
Улучшения восстановления бэкапов GitLab (CORE, STARTER, PREMIUM, ULTIMATE)
Автоматический редирект на HTTPS в GitLab Pages (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab Pages может предоставлять статические вебсайты через протоколы HTTP или HTTPS. HTTPS обычно предпочтительнее, так как шифрует весь трафик, защищая содержимое, пока оно передается по сети.
В случае, когда доступны оба варианта, в GitLab 10.7 пользователи могут настроить проекты так, чтобы HTTP запросы автоматически перенаправлялись на соответствующие URL с протоколом HTTPS. Это повысит безопасность и гарантирует, что данные не будут передаваться простым текстом.
Автоматическое обновление сертификата GitLab Let’s Encrypt (CORE, STARTER, PREMIUM, ULTIMATE)
В GitLab 10.5 мы упростили подключение HTTPS для инстансов GitLab с помощью интеграции с Let’s Encrypt.
С GitLab 10.7 мы делаем этот процесс еще проще. Мы автоматизировали процесс обновления и убрали необходимость держать Let’s Encrypt постоянно включенным. Все, что вам нужно сделать, чтобы подключить HTTPS — начать ваш external_url с https:// — и всё!
Облачный чарт GitLab доступен для Core (альфа) (CORE, STARTER, PREMIUM, ULTIMATE)
С введением поддержки хранилища объектов в плане Core, альфа-версия облачного нативного чарта GitLab теперь доступна без лицензии. Этот чарт представляет более облачную собственную архитектуру с контейнером для каждого компонента GitLab и не требует общего хранилища. Эти изменения повлияют на повышение гибкости, масштабируемости и производительности GitLab на Kubernetes.
Улучшения в доске метрик окружения (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
На доске метрик окружения появилась сводная статистика. Она отображает средние и максимальные значения каждой серии за определенный промежуток времени. Например, теперь можно быстро узнать среднее время ответа за последние 8 часов, чтобы понять, с чем обычно сталкиваются пользователи.
Также теперь отображается общее потребление процессора и памяти пода, что обеспечивает понимание того, как используются ресурсы конкретного окружения в кластере.
GitLab Runner 10.7 (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
С этим релизом также вышла новая версия GitLab Runner — 10.7. GitLab Runner — это проект с открытым исходным кодом, который используется для запуска и отсылки результатов ваших работ CI/CD обратно в GitLab.
Самые важные изменения:
Полный список изменений вы найдете в CHANGELOG GitLab Runner.
Улучшения Omnibus (CORE, STARTER, PREMIUM, ULTIMATE)
Улучшения производительности (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Среди всех улучшений производительности GitLab 10.7 отдельно хотим отметить:
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 10.7 released with open source Web IDE and SAST for Go and C/C++.
Над переводом с английского работали rishavant и sgnl_05.