Community Repository Tag Protection Rules

[kernelsam]

General

Add tag protection rules to all community repositories to prevent tag deletion or updates from anyone other than an admin. This would effect repositories in the following orgs: Senzing, senzing-garage, senzing-factory

Two options for implementation

1. Tag protection rules, see GitHub Documentation for additional details.

   When you add a tag protection rule, all tags that match the pattern provided will be protected. Only users with admin or maintain permissions, or custom roles with the "edit repository rules" permission in the repository will be able to create protected tags, and only users with admin permissions or custom roles with the "edit repository rules" permission in the repository will be able to delete protected tags.

2. Implemented as a ruleset.

   1. This allows us to restrict only deletion and modifications of existing protected tags, while allowing anyone with write access to create a tag.
   2. 
   3. Above regex based on the suggestions from SemVer.
   4. This would not require the build user to have any elevated permissions as we do not automate tag deletion.

   5. Anyone with read access to a repository can view the active rulesets for the repository. This means a developer can understand why they have hit a rule, or an auditor can check the security constraints for the repository, without requiring admin access to the repository.

Tags to protect

• Semantic version tags: X.Y.Z
• Go Tags: v.X.Y.Z
  • Only required on Go repositories

Documentation

• Tag creation and deletion steps should be documented so all admins are following the same process.
• This should also include instructions for who to reach out to create tags or resolve issues.

Potential Issues

• Barry has reported problems with maven deployments requiring tag recreation.

  • Temporary solution: elevate Barrys permission with a custom role on the respective repositories.
  • Long term solution: resolve issues in maven deployments.

• Validate any breakages to existing tag automation.

  • The automated devops user intentionally does NOT have admin permissions.