Repository protection#

Handling repositories implies handling sensitive information, especially when configuring workflows to access private servers. Because workflows acquire Ansys product licenses and handle secrets, it is important to implement good protection rules.

In the following sections, different safety measures are presented.

General configuration#

Being an owner or an administrator of a repository gives you access to the Settings menu. To access the general configuration settings for the repository, select Settings > General.

The PyAnsys core team recommends choosing these settings in the Pull Requests section:

Select Allow squash merging to force all commits of a pull request (PR) to be condensed into a single commit. This way, if a PR is not successful, it can be reverted easily.
Select Default to pull request title for squash merge commits to provide a uniform way of naming PRs and merging them to the main branch.
Select Always suggest updating pull request branches to update your branch to the main branch before merging. (This can be enforced as explained later.)
Select Automatically delete head branches for cleanup purposes. Once a PR is merged into the main branch, the PR-related branch is deleted so that the repository contains only active branches.

Branch protection#

Branch protection is critical in terms of avoiding malicious code insertion and access to confidential data. To access the branch protection rulesets for the repository, select Settings > Code and automation > Branches.

Next to Branch protection rules, click Add rule.

Under Branch name pattern, type the name of the branch that you want to protect (usually main, but you can also protect other branches, such as gh-pages). Regular expressions (also known as regex) are accepted. For example, you might want to protect all release/ branches.

The PyAnsys core team recommends setting these rules for the main branch:

Select Require a pull request before merging so that only owners or administrators are able to directly merge to the main branch.
Select Require approvals to ensure that all PRs are reviewed. (PRs created by owners or administrators do not require approval.)
Select Require review from Code Owners so that code owners are forced to review all PRs to prevent malicious code from being merged into the main branch. Code owners should be able to identify pieces of code that are not allowed. To ensure a code owner is always available to approve and merge PRs, creating an Owners/Admins team with multiple members is recommended.
Select Require status checks to pass before merging so that only code that compiles, passes tests, and is formatted correctly can be merged. This is the sole purpose of CI/CD.
Select Require branches to be up to date before merging to ensure that all code has been tested and is compatible with the main branch before it can be merged. This is an important concept because someone may have merged code into the main branch that clashes with your code.
Select Require status checks to pass before merging so that the PR cannot be merged until all workflow checks are successful. The minimal checks to implement are for code style, documentation style, build and unit testing, documentation building, and smoke tests.
Select Require conversation resolution before merging to force reviewers to go through and resolve all comments. This ensures that all comments are read and possibly applied.

Tag protection#

Protect tags so that only code owners and administrators can create them. To access the tag protection settings for the repository, select Settings > Code and automation > Tags.

Following the PyAnsys tagging convention, protect the v* tag.

Workflow protection#

Protect workflows in the settings for actions. The focus here is on forks, which let you make changes to a project without affecting the original repository. To access the actions settings for the repository, select Settings > Actions > General.

Under Fork pull request workflows from outside collaborators, the preferred option is Require approval for all outside collaborators for repositories that are to be released publicly. The minimum option is Require approval for first-time contributors.

Because workflows contain sensitive information, it is important to preserve security and control. The rules for workflows are more flexible. For example, if you have common outside collaborators who has been contributing for some time, you may want to add them as members of the repository so that their PR workflows do not have to be accepted every time that they intend to run them.

Internal and private repositories are only available to organization users and repository members, respectively. Thus, no specific rules for outside collaborators are needed.