Handling repositories also implies handling sensitive information, especially when looking into workflows. Access to private servers to acquire Ansys product licenses, secrets handling and so on. Thus, it is important that the PyAnsys libraries have good protection rules implemented.
In the following sections, different safety measures are presented.
Being an owner/admin of a repository gives you access to the
One accesses the General configuration of the repository by:
The PyAnsys team recommends the following measures in the Pull Requests (PRs) section:
Only allow for
Squash merging: this option forces all commits of a PR to be condensed into a single commit. That way, in case a PR was not successful for some reason, or wants to be reverted, it is easier to just revert that commit.
Default to PR title for squash merge commitscheckbox: this provides a uniform way of naming PRs and merging them to the main branch.
Always suggest updating pull request branchescheckbox: though this can be enforced (as it is explained in upcoming sections), it is recommended to always have your branch updated to the
mainbranch before merging.
Automatically delete head branchescheckbox: this is more intended for cleaning purposes. Once a PR is merged into the
mainbranch, the PR-related branch should be deleted so that only active branches are available in the repository.
Branch protection is critical in terms of avoiding malicious code insertion and access to confidential data. If one accesses:
Code and automation>>
You are presented with the Branch protection menu. On the
rules please click on the
Add rule button.
Branch name pattern box, one should include the name of the branch
to be protected (usually
main, but one could also protect other branches,
gh-pages). Regular expressions (also known as
regex) are also
accepted (for example, if protection on all
release/* branches is wanted).
The PyAnsys team recommends to set the following rules for the
Require a pull request before mergingcheckbox: that way, no one (except for owners/admins) should be able to directly merge to
Require approvalscheckbox: this ensures that all PRs are reviewed and nobody goes riding solo (again, except for owners).
Require review from Code Ownerscheckbox: this is intended for workflow protection as well. That way, it is ensured that no malicious code is merged into the main branch. Code owners should be capable of identifying pieces of code which should not be allowed, though it forces them to review all PRs.
It is recommended to create an Owners/Admins team: this team should contain multiple members, so that if somebody is not available, others can still approve and merge.
Require status checks to pass before mergingcheckbox: this is the sole purpose of CI/CD. Only code which compiles, passes tests, is formatted accordingly etc. should be allowed to merge.
Require branches to be up to date before mergingcheckbox: this is an important concept, since sometimes, somebody may have merged into
maina certain piece of code which clashes with your own developments. By activating this, it is ensured that all code which is merged has been tested and is compatible with the current
Status Checks requiredcheckbox: whenever possible, all workflow stages should be included, but at least:
Documentation Style Check,
Build and Unit testing,
Documentation build, and
Smoke testsshould be activated.
Require conversation resolution before mergingcheckbox: this forces assignees to actually go through all comments. It is just a safety measure so that at least any comment left by reviewers is read (and hopefully applied).
Tags should also be protected, so that only code owners/admins can create them. This can be done by accessing:
Once inside, and following the PyAnsys tagging convention, the following tags should be protected:
Finally, workflows can also be protected.
Once inside, focus should be set on the
Fork pull request workflows from outside collaborators.
In this case, the PyAnsys team suggests the following:
Preferred option for public repositories:
Require approval for all outside collaboratorscheckbox when going public.
Minimum option for public repositories:
Require approval for first-time contributorswhile still internal/private.
Workflows contain sensitive information and it is important to preserve security and control over it. However, these rules are more flexible. For example, if you have a common outside collaborator, which has been contributing for a time doing you may consider adding it as a member/collaborator of the repository so that its PR workflows do not have to be accepted every time he is intending to run it.
Internal and private repositories are only available to organization users and repository members, respectively. Thus, no specific rules for outside collaborators are needed.