GitProtect v1.8.0
Last updated
Last updated
NEW FEATURES
We have completely transformed the method of onboarding new users. When logging in for the first time, a user is immediately directed to a new screen presenting all possible resources to secure with GitProtect. By default, a new user can connect a service with GitProtect within the literal 3-step process, however, if the organization requires authorization using login, token, or GitHub App there is still available a previous advanced mode aside.
The upper blue bar, which contains the context menu for the currently visible subpage, has also undergone important changes. Allowing an easy setup of a new backup plan or adding new services to protect. We have also moved the language setting to the User's action and provided an easy way to upgrade or purchase licenses.
To increase the security of user data, encryption is enabled by default for each new backup plan. For this purpose, a default encryption key is generated, which can be viewed only once at the time of its creation.
For each of the supported DevOps tools, GitProtect provides a separate type of backup plan - hence from v.1.8.0 user can choose between GitHub, Bitbucket, GitLab, and Jira backup plans - and then configure them according to the security rules of its organization.
Backup plan with encryption enabled and default encryption key
To increase the security of user data, encryption is enabled by default for each new backup plan. For this purpose, a default encryption key is generated, which can be viewed only once at the time of its creation.
We have launched a mechanism for converting classic GitHub projects to V2 projects. If a backup copy consists of classic projects during a restore process these projects are going to be converted to the V2 type.
Version 1.8.0 brings with it more optimizations within the Jira Granular Restore process. This time we focused on optimizing incremental backups with granular restore enabled.
We have noticed that some of our users only partially configure the throttling mechanism for the git organizations. In their case, the process ended at the stage of adding an additional account or GitHub App. Hence, we decided to include within the configuration process information to edit the backup plan next: To benefit from adding additional accounts enable sharing tasks between many credentials in advanced backup plan settings.
With this release, we provide a solution for a not enough allocation of RAMs issues. When there is not enough RAM to perform a operation, the service will automatically receive an increased amount of resources. In the first phase, the mechanism will operate in manual mode, i.e. the service will automatically send the request, but the resource assignment will take place after user approval. Additionally, we have introduced optimizations that will improve the release of used RAM, and thus reduce its consumption.
GitProtect users can now set the time zone within the backup plan schedule according to all future tasks will be launched. This improvement eliminates the need for manual time zone change during the winter/summer time switch.
GitProtect now supports backup and restore of merge settings in GitHub repositories e.g. commit merge settings, default commit merge messages, squash merge settings, and rebase.
Users can now restore external collaborators added to GitHub repositories. Please note that restoring this particular data has some limitations, as GitHub allows to restore of only 50 external users max.
We have expanded the scope of supported metadata in Bitbucket repositories of selected programming languages, websites, and forking settings.
GitProtect provides a new type of Slack notification - the SLA report is ready to download. We want you to stay up to date, however convenient for you.
The error occurred only when Git organization sync and daily report generation were run simultaneously. From v. 1.8.0 the problem is fixed.
The problem was caused by the incorrect behavior of the GitLab API when downloading pull requests and issues if there were more than 10,000 of them in a given repository. The problem has been fixed, and GitProtect correctly protects repositories with more than 10,000 issues or pull requests.
The problem only occurred with pull requests and corresponding comments if data exceeded 2 GB. Fixed.
The problem occurred only when restoring an issue with a description text longer than 65,536 characters. From version 1.8.0, such descriptions are truncated to the maximum allowed length.
The issue occurred only in a scenario when a GitLab group had an unexpected null value in the “Do not allow users to remove Git tags with git push” rule. Fixed.
During tests, our team found out that for some particular scenarios, GitProtect could not granularly restore data for issues secured within the incremental backup copy, then restored to the empty project and secured again within a new backup plan. The problem was completely resolved.
IMPROVEMENTS
BUGFIXES