ansys-dynamicreporting-core 0.10.7

Developer installation

To clone and install the pydynamicreporting package in development mode, run this code:

git clone https://github.com/ansys/pydynamicreporting
cd pydynamicreporting
pip install virtualenv
virtualenv venv  # create virtual environment
source venv/bin/activate  # (.\venv\Scripts\activate for Windows shell)
make install-dev  # install pydynamicreporting in editable mode

The preceding code creates an “editable” installation that lets you develop and test PyDynamicReporting at the same time.

To build and create a production-like installation on Windows (not required on other OSes), first install chocolatey. Then:

choco install make  # install make on Windows
make clean  # clean
make build   # build
# this replaces the editable installation done previously. If you don't want to replace,
# switch your virtual environments to test the new install separately.
make install
# you can skip the steps above and just do 'make all'
make smoketest  # test import

Local GitHub Actions

To run GitHub Actions on your local desktop (recommended), install the act package.

choco install act-cli

To run a job, such as the style job from the ci_cd.yml file, use this command, where style is the job name:

act -W '.github/workflows/ci_cd.yml' -j style --bind

Deploy and upload steps must always be ignored. If they are not ignored, before running GitHub Actions locally, add if: ${{ !env.ACT }} to the workflow step and commit this change if required.

Versioning model

• Stable releases: The version is the exact Git tag (for example, v0.10.0 → package version 0.10.0).

• Development builds: Version is computed from the latest tag plus a timestamp, e.g. 0.10.1.devYYYYMMDDHHMMSS.

• No manual editing of pyproject.toml for versions — [tool.hatch.version] drives everything.

What the automation does

• Create Draft Release (on tag push): builds wheels/sdist and opens a draft GitHub Release attaching artifacts.

• Publish Release (when the GitHub Release is published): uploads artifacts to PyPI via Trusted Publisher, then builds & deploys stable docs.

• Failure notifications: posts to Microsoft Teams on workflow failure.

Prerequisites

• Ensure CHANGELOG.md has a section for the release dated today (the helper script validates this).

• Working tree must be clean (no uncommitted changes).

• CI secrets for publishing and docs deploy are configured in GitHub.

Cutting a Stable Release

1. Make sure your CHANGELOG.md entry for the version is dated today (this check runs automatically from make tag).

2. Create and push the release tag:

   make tag

   This runs all safety checks, validates the changelog date, and pushes the Git tag (for example, v0.10.0).

3. Once the tag is pushed: - The Create Draft Release workflow builds the package and opens a draft GitHub Release with artifacts. - After reviewing and finalizing notes, publish the GitHub Release.

4. Publishing the release automatically triggers the Release workflow, which: - Uploads artifacts to PyPI using Trusted Publisher. - Builds and deploys the stable documentation.

Patch releases

• For a patch, update the changelog, ensure the working tree is clean, then run make tag again (which tags the next patch version determined by hatch version from your last tag).

• No separate “release branch” is required; the version is derived from tags.

Local dry-runs (optional)

You can use act to exercise non-publishing parts locally. Steps that publish or deploy are already guarded in workflows (e.g., with if: ${{ !env.ACT }}). Build and validation steps still run:

act -W '.github/workflows/release.yml' -j release --bind

CI workflows (reference)

• .github/workflows/create_draft_release.yml - Triggers on: tag push v*, or manual dispatch. - Builds artifacts and opens a draft GitHub Release attaching dist/*.

• .github/workflows/release.yml - Triggers on: published GitHub Release, or manual dispatch. - Rebuilds/validates, downloads artifacts, publishes to PyPI, builds docs, and deploys stable docs.

CLI helpers

• Print the resolved version (dev or stable):

  make version

• Build locally (sdist + wheel):

  make build
  make check-dist

• Clean:

  make clean

Changelog guards

Releases are blocked if today’s dated entry is missing:

❌ ERROR: CHANGELOG.md is not ready for release.
   Expected line: ## [0.10.0] - YYYY-MM-DD
   Tip: Check if it's still marked as '[Unreleased]' and update it to today's date.

Troubleshooting

• “No Git tag found” during checks: Create a tag via make tag (or git tag vX.Y.Z && git push origin vX.Y.Z).

• Draft already exists: The draft release is unique per tag. Delete or publish the existing one, or bump the tag properly.

• Version mismatch: hatch version determines the version from the last tag; ensure you pushed the intended tag and your clone has all tags (git fetch --tags).