Publishing BERA Tools

BERA Tools is published to PyPI when the main branch is tagged with a new version. Conda and Windows installer publishing are manually dispatched from the tagged main commit.

Versioning

BERA Tools Versioning follows PEP440: major.minor.patch.

Packaging BERA Tools

BERA Tools is packaged for distribution on both PyPI and Anaconda. PyPI publishing is triggered by a version tag push; Anaconda publishing requires an explicit manual run from the tagged main commit.

See the following workflows:

• Conda Packaging and Release: publish_to_anaconda.yml
• PyPI Packaging and Release: publish_to_pypi.yml
• Windows Installer Build and Signing: build-win-installer.yml

See the workflow inventory in the Maintainer Guide.

Re-running a Failed PyPI Publication

If publish_to_pypi.yml fails before PyPI accepts any distribution files, a maintainer with write access can open the original GitHub Actions run and select Re-run jobs -> Re-run failed jobs. GitHub rebuilds and republishes from the same version tag, commit SHA, Git ref, and trusted-publishing identity. Workflow runs can be rerun for up to 30 days.

Before rerunning, confirm that the version has no files on PyPI. If PyPI accepted any files before the failure, do not rerun blindly: distribution filenames are immutable and duplicate uploads fail. Inspect the release and publish a new patch version if the release is incomplete. A rerun also uses the workflow definition from the tagged commit, so a defect in the workflow itself must be fixed before creating a new release tag.

Anaconda Publication

Open Publish to Anaconda and select Run workflow. Leaving Version tag to publish empty runs a non-publishing build and smoke test of the selected branch. The resulting Conda package is attached to the workflow run as an artifact, including when smoke validation fails.

For an Anaconda release:

1. Merge the release changes into main.
2. Optionally dispatch the workflow from main without a version tag for a final dry run.
3. Create and push the new major.minor.patch tag on that exact main commit.
4. Dispatch the workflow from main again and enter the new tag in Version tag to publish.
5. Confirm the build and smoke test pass and the package appears on Anaconda BERA Tools.

Pushing the tag does not trigger Anaconda publishing. Publishing proceeds only when the manually supplied tag is the latest numeric version tag and points exactly to the selected main commit. A valid tag supplied from another branch, a tag that does not match the selected commit, or an older tag automatically becomes a dry run; a malformed or nonexistent tag fails validation. Confirm that the version is absent from Anaconda before publishing because existing package files are never overwritten.

If main advances after a failed publication, fix the release issue and create a new version tag on the updated commit. The workflow will not publish an older tag from a newer main commit.

Windows Installer Signing

Official Windows installers follow the project Code signing policy. Test and release signing use the same SignPath artifact configuration so a manual test validates the artifact that will later be released.

Manual Signing Test

Run a test after changing the installer, its build script, the signing workflow, or the SignPath artifact configuration.

1. Open Build Windows Installer in GitHub Actions.
2. Select Run workflow and choose the branch to test.
3. Wait for the Submit installer to SignPath step to complete using test-signing.
4. Confirm the run contains both beratools-installer-unsigned and beratools-installer-signed artifacts.
5. Confirm Upload signed installer to release was skipped.

The test certificate is self-signed, so Get-AuthenticodeSignature may report UnknownError because its root is not trusted by Windows. The workflow still requires a signer certificate and rejects an unsigned installer. Test-signed installers are for validation only and must not be distributed as releases.

Production Release

1. Merge the release changes into main and ensure all release workflows are ready.
2. Create a major.minor.patch version tag on the current main commit and push the tag. Do not advance main until all release workflows complete.
3. Open Build Windows Installer, select Run workflow, choose main, and enter the version tag in Version tag to release.
4. Confirm the workflow verifies that the supplied tag points exactly to the dispatched main commit, is the latest numeric version tag, and submits with release-signing.
5. Open the signing request from the SignPath email or the URL printed by the workflow.
6. An authorized SignPath approver must approve the request within the workflow's one-hour timeout.
7. Confirm the release signature status is Valid.
8. Confirm the signed installer was attached to the GitHub Release.

The person who creates the tag does not need to be a SignPath approver. With multiple approvers and one required approval, any listed approver can authorize the request. If the request is denied or times out, the workflow does not publish the installer. A rerun does not overwrite an installer asset that is already attached to the release.

Installer Identity

Before tagging a release, update beratools.__version__ to the same major.minor.patch value. The validated release tag becomes APP_VERSION, which supplies that version to packaging/beratools.iss for the installer filename, Installed Apps version, and executable product/file versions. Do not hardcode a separate version in the Inno script. Publisher, company, support, and update metadata remain stable; the Authenticode publisher comes from the signing certificate and therefore appears as SignPath Foundation.

SignPath Configuration

Open Projects -> beratools -> Signing policies in SignPath to review policy settings.

For release-signing, require trusted-build-system verification and origin verification. Set the repository URL to https://github.com/appliedgrg/beratools.git, the allowed branch to main, and the allowed build definition to .github/workflows/build-win-installer.yml.

GitHub reports a tag-triggered workflow's tag name as its origin branch. Do not add version tags or wildcard patterns to the production policy's allowed branches. Release signing is dispatched from main, and the workflow verifies that the supplied tag resolves exactly to that main commit.

Both policies use the default artifact configuration below. Only these artifact rules are shared; certificates, approval requirements, branch restrictions, and origin settings remain policy-specific.

<?xml version="1.0" encoding="utf-8" ?>
<artifact-configuration xmlns="http://signpath.io/artifact-configuration/v1">
  <parameters>
    <parameter name="version" required="true" />
  </parameters>
  <zip-file>
    <pe-file path="beratools-installer-${version}.exe">
      <authenticode-sign />
    </pe-file>
  </zip-file>
</artifact-configuration>

Inno Setup pads text fields in the PE version resource. Do not add product-name, product-version, or file-version restrictions without confirming a supported configuration with SignPath and completing a manual signing test.

The GitHub workflow reads SIGNPATH_API_TOKEN and SIGNPATH_ORGANIZATION_ID from repository Actions secrets. Never expose secret values, organization identifiers, user email addresses, or signing-request URLs in documentation or source control.

For maintainer handoff, add replacement users as SignPath approvers and retain at least one organization administrator or project configurator. With multiple approvers and one required approval, any listed approver can approve. Require MFA, keep the CI builds submitter independent of personal accounts, and verify replacement access before removing a departing maintainer.

After any portal or artifact-configuration change, run the manual signing test. The message No GitHub policy found at .signpath/policies/... is informational when no repository policy file is configured; open the signing request in SignPath for actual processing failures. GitHub connector requests contain attestation authorization data and cannot be promoted with SignPath's resubmit API.

Releases

Anaconda BERA Tools

PyPI BERA Tools