Building a specific release with specific build tools feels like correct
choice for reproducibility in general. It's also practically required
as the hatchling version is embedded in the WHEEL file: this means
updating the build tool modifies the resulting build artifact.
Pin hatchling version. This version should be kept up-to-date: my
working assumption is that Dependabot will handle it.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
It seems --no-deps does not work as it used to (and actually installs
all build dependencies). This is very bad because verify_release also
uses "--no-binary :all:" leading to actually _building_ all build
dependencies from source.
Use "--no-binary tuf" instead: build dependencies will still be
installed (into a working environment) but at least they won't be built
from source.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Mention how to use verify_release with the recently added --sign
option to create signatures for a verified release.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Add option to sign locally built release artifacts with gpg,
if they match the downloaded artifacts from GitHub, PyPI.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Prior to #1946 the verify_release script was successful if both PyPI
and GitHub release artifacts matched the local build.
Now, if the `--skip-pypi` option is provided, the script can also
be successful if only the GitHub release artifacts match the local
build.
This commit splits the final success message in two separate
success messages, one for PyPI and one for GitHub.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Since #1971 ci and cd workflows run independently of each other,
each of them also calling the test workflow.
This patch updates RELEASE.md to match the new setup.
It also fixes a (twice) broken link.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Prior to this change, ci triggered cd, depending on the event that
triggered ci. Due to the vague information about that event
available to cd, the workflow pipeline was a bit brittle.
This change disassociates ci and cd workflows to allow for an
independent configuration of trigger events.
The test jobs, which used to be defined in ci, are now in a
separate workflow file _test.yml that can be included in both ci
and cd workflows.
**Changes in ci**
- Only defines trigger events and permissions, the "meat" of ci is
defined in the called _test.yml now.
- No longer triggers on tag pushes, this was only needed for cd.
**Changes in cd**
- Now triggers directly on tag pushes instead of (cd)-workflow_run.
- Calls _test.yml, and require successful run before build/release.
(`needs: test` replaces `if: ...`)
- Changes variable names about pushed tag that triggered the event.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Explicitly include `examples` dir in sdist.
The same would be achieved, by removing explicit includes, which
currently would also add these files/dirs:
```
/gitattributes
/github
/mypy_cache
/readthedocs.yaml
/verify_release
```
Maybe we should instead of defining includes, explicitly exclude
(some of) these files? The advantage of a blacklist approach is
that it becomes less likely to forget including files that should
be in included.
See hatch docs for:
- what files should be in sdist
https://ofek.dev/hatch/latest/plugins/builder/#source-distribution
- what files get into sdist by default:
https://ofek.dev/hatch/latest/plugins/builder/#default-file-selection_1
- how to configure what files get into sdist:
https://ofek.dev/hatch/latest/config/build/#file-selectionFixes#1901
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Inside test_metadata_eq_.py we test the __eq__ implementations of all
classes. In order to do this, we change the attribute of the object and
then compare them to the unchanged version of those objects.
Usually, we do it in the following steps:
1. create an initial version "a"
2. create a copy of "a" called "b"
3. iterate all attributes inside "b" and change them to a given value
4. check that "a" and "b" are different
We do however forget to restore the object `b` to its initial state
which means we don't check the `__eq__` correctly as we stop on the
first, the found difference which could be of an older attribute changed
in one of the past iterations.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Fixes#1938
Description of the changes being introduced by the pull request:
Annotating as Mapping seems wrong as further changes to the content might
be added in the code base. Hence, annotation changed to Dict.
Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>
Make a new (local) git clone to build from. This ensures uncommitted
files do not affect the build.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
