Technical review

[klmcadams]

Pull Request Template

Description

Technical Review Checklist

Project metadata information

• The project name follows naming conventions.
• The project version follows Semantic versioning.
• The project author is ANSYS, Inc.
• The project maintainer is ANSYS, Inc.
• Contact and support information is provided in the project.
• The AUTHORS file is present and compliant with legal requirements.
• The LICENSE file is present and compliant with legal requirements.
• The CONTRIBUTING.md file is present.
• The CONTRIBUTORS.md file is present and contains the project lead and main contributors.

PyAnsys style guidelines

• The project layout follows the Packaging style guidelines.
• The source code docstring examples have been tested.
• Testing guarantees at least 80% code coverage.
• The project adheres to the Documentation style guidelines.
• The documentation examples are presented as a gallery - Decided not to do this
• The documentation receives the documentation team’s approval. @PipKat reviewed the docs here: Overall doc edit for public release #278
• The package builds properly.
• The project uses CI/CD, including all the Required workflows.
• The CI/CD pipeline generates project Artifacts.

Repository protection

• The repository adheres to the General configuration.
• Branch protection is enabled.
  • Create owners/admins group for approvals - should contain more than one person. We have to do this once it moves to the ansys repo
• Tag protection is enabled.
  • Add tag protection once we change release from github token to the pyansys-ci-bot
• Workflow protection is enabled.
  • Have to add protections for outside collaborators once the repo is public. This is currently unavailable as a private repo

[RobPasMue]

• Apart from adding sphinx-autoapi, you will also need to configure the conf.py accordingly. Just in case you missed it @klmcadams

[FedericoNegri]

@klmcadams @RobPasMue HPS dev is open again so we could consider merging this PR so that I can adjust consumers accordingly.

I know we aren't 100% done yet with the technical review but since this PR is getting large I would be in favor of merging and then following up on outstanding items. What do you think?

[RobPasMue]

Yep I agree - @klmcadams finish up anything (easy) you might be missing before merging and then merge. Remaining points can be handled afterwards

[klmcadams]

@FedericoNegri @RobPasMue Can you look over the files (especially the workflow's release sections), and approve it & merge it if it looks good to you? The nightly build works for this branch, and the changes to the files with autogenerated code are from the pre-commit hooks in the repo. I made the main python version 3.10 since the workflow settings require testing for 3.10 in order to merge the PR

[RobPasMue]

LGTM, great work @klmcadams

[FedericoNegri]

Let's merge! many thanks