Releases: sandialabs/reverse_argparse
v2.0.9
Bug fixes
-
fix: Rework release publishing (
9c718b6
)The PyPI upload failed with:
Checking dist/reverse_argparse-2.0.8-py3-none-any.whl: PASSED
Checking dist/multiple.intoto.jsonl: ERROR InvalidDistribution:
Unknown distribution format:
'multiple.intoto.jsonl'I suppose the provenance can't be included in the
dist
directory for
the PyPI upload, but it needs to be in there for python-semantic-release
publish to GitHub Releases action. This commit reorders things, such
that we publish to GitHub first, and save PyPI for last, and between the
two we remove the provenance from thedist
directory. Hopefully this
works.
v2.0.8
Bug fixes
-
fix: Set sufficient permissions for publish job (
4004ef2
)When running the upload to PyPI action, we ran into:
Error: Trusted publishing exchange failure:
OpenID Connect token retrieval failed: GitHub: missing or
insufficient OIDC token permissions, the
ACTIONS_ID_TOKEN_REQUEST_TOKEN environment variable was unsetThis generally indicates a workflow configuration error, such as
insufficient permissions. Make sure that your workflow has
id-token: write
configured at the job level, e.g.:permissions: id-token: write
v2.0.7
Chores
Code style
-
style: Check flake8-annotations (
9ceb68a
)To ensure type-hinting is present in all possible locations.
Continuous integration
-
ci: Subdivide release job (
60bca10
)This is needed because the SLSA provenance reusable workflow cannot be
used as a step within a job, but must be used as a job on its own. This
commit therefore subdivides therelease
job into arelease
job,
which runspython-semantic-release
to create a new release, if
applicable, and then apublish
job, to publish the release to PyPI and
GitHub Releases, if one was created. We'll then be able to insert the
SLSA provenance job between the two.
Patch
-
patch: Add SLSA provenance to release assets (
e4e6ebc
)See https://slsa.dev/ for motivation.
Creating a patch release to ensure these additions to the automated
release process work.Closes #260.
v2.0.6
v2.0.5
v2.0.4
v2.0.3
Chores
-
chore: Update security notice (
4d51098
)The Best Practices Badge App suggests we should document what users can
expect from our project in terms of security.
Documentation
-
docs: Switch to
project_copyright
(d0a21d5
)Using this alias means we're no longer overshadowing the
copyright
built-in, so we can remove the comment to ignore that Ruff linting rule.
Patch
v2.0.2
v2.0.1
v2.0.0
Chores
-
chore!: Drop support for Python 3.8 (
5c448ec
)- Use the type-hinting provided out of the box in 3.9.
- Remove version guards around
argparse.BooleanOptionalAction
. - Update documentation and CI accordingly.
-
chore: Tweak dependabot again (
1af1398
) -
chore: Tweak dependabot (
c4c9252
)Run weekly instead of daily, and group updates into a single PR for each
packaging ecosystem. -
chore: Update LICENSE/COPYRIGHT info (
aae82e5
)
Continuous integration
-
ci: Change documentation coverage file name (
c487d94
) -
ci: Restrict token permissions (
dfb85fd
)https://github.com/sandialabs/reverse_argparse/security/code-scanning/21
-
ci: Tweak automated suggestions (
3a73bda
) -
ci: Apply security best practices (
27fd558
)Signed-off-by: StepSecurity Bot bot@stepsecurity.io
-
ci: Don't fix Ruff issues (
6fb3b58
)Remove the
--fix
argument from theruff
check in the pre-commit
configuration. We don't want automated commits pushed to PRs, because
we want to encourage contributors to clean up their branches before
merging. Additionally, when pre-commit doesn't automatically fix files,
it shows the user what the issues are, thereby training them to avoid
them in the future.
Documentation
-
docs: Fix highlighting in examples (
149e48c
)I never noticed when we added the license and copyright information to
the top of all the source files that we didn't account for the
lines highlighted in the included examples. This adjusts things such
that (1) we don't include all that header stuff when generating the
docs, and only include the lines of code that are really relevant to
share on the examples page, and (2) the appropriate lines are
highlighted. -
docs: Slight tweaks to contributing guidelines (
6e2ddc9
)