GitProtect v. 1.7.0 Brings GitHub Dependabot And Branch Protection Rules Support
Last Updated on March 7, 2024
The GitProtect version 1.7.0 is on and with it comes a few noticeable changes:
GitProtect supports GitHub Dependabot and Branch Protection Rules
From now on GitProtect’s users can secure Dependabot settings (not-beta marked):
- Dependabot alerts (without rules)
- Dependabot security updates
- Dependabot version updates
and branch protection rules.
This widened coverage requires extra permissions, as we need users authorizing GitProtect to be able to access those metadata.
📌 If you connect GitHub with GitProtect via OAuth App
1. Please make sure that the user whose account you’ve used for GitProtect OAuth App authorization has access to Branch Protection rules and Dependencies metadata. Only users who have Admin permissions in the repository can access those.
2. If you have the correct permissions, you need to reauthorize the connection between GitProtect and GitHub.
3. To complete reauthorization, you need to re-add the GitHub organization in the same manner as you would add it from scratch. You don’t need to remove it from GitProtect beforehand. Act like it’s not there yet.
4. If you’re not sure how to add an organization within GitProtect, follow instructions from our Knowledge Base in the same manner as you’d be adding this organization during the first run.
5. After you’ve done that, reauthorization is complete. You’re good to go!
📌 If you connect GitHub with GitProtect via Personal Access Token (PAT)
1. You need to update the permissions of your Personal Access Token in GitHub. You can find those in Settings > Developer Settings > Personal Access Tokens > Tokens (classic).
2. Once there, grant two new permissions to your Personal Access Token: read:org and read:discussion
3. After you’ve updated your token permissions, you’re good to go!
Adding more permissions is not mandatory overall if you don’t want to protect those metadata. You just need to edit your Backup Plan in GitProtect, and disable the protection of those two metadata – this way you won’t be getting any future Error messages.
New granular restore setup for Jira
From this release, we introduce a new backup configuration option connected to the granular restore. Now users can decide whether a Jira backup copy should be prepared for future granular restore.
Jira Granular Restore extended for attachments
We know from our own experience no least that Jira attachments can be quite easily corrupted. Hence the possibility to granularly restore Jira attachments to preferred requests comes in handy. It’s worth remembering, that users can also restore attachments to the local device as a ZIP package or to the original location/destination.
Restore for GitLab comments in a file format
Due to GitLab limitations, we have not yet been able to restore merge request file comments to their original form. However, since the GitLab 16.4 release the issue has been resolved, and from now on users can restore them without any limitations.
Backup performance improvement – we are setting a new record!
Do you have an extensive GitHub, Bitbucket, or GitLab ecosystem? Like 10k repos or more? or even “just” 1k repositories? Then you will find our recent backup performance improvements very valuable. From version 1.7.0 time for a backup task running was reduced up to a few seconds. No marketing, just hard facts!
Bitbucket restore with even better performance
There is more performance boost in this release. The Bitbucket restore process gained noticeable speedup. Our team managed to reduce the time needed to restore data from a few minutes to a few seconds!
Root account management with more flexibility
In response to our customers’ needs, GitProtect allows users to modify root account settings and change a root administrator. After the operation, the former root administrator account transitions to a system administrator role with default permissions.
