gha-utils 4.24.0__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- gha_utils/__init__.py +20 -0
- gha_utils/__main__.py +49 -0
- gha_utils/changelog.py +146 -0
- gha_utils/cli.py +452 -0
- gha_utils/mailmap.py +184 -0
- gha_utils/matrix.py +291 -0
- gha_utils/metadata.py +1693 -0
- gha_utils/py.typed +0 -0
- gha_utils/test_plan.py +352 -0
- gha_utils-4.24.0.dist-info/METADATA +375 -0
- gha_utils-4.24.0.dist-info/RECORD +14 -0
- gha_utils-4.24.0.dist-info/WHEEL +5 -0
- gha_utils-4.24.0.dist-info/entry_points.txt +2 -0
- gha_utils-4.24.0.dist-info/top_level.txt +1 -0
|
@@ -0,0 +1,375 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: gha-utils
|
|
3
|
+
Version: 4.24.0
|
|
4
|
+
Summary: ⚙️ CLI helpers for GitHub Actions + reuseable workflows
|
|
5
|
+
Author-email: Kevin Deldycke <kevin@deldycke.com>
|
|
6
|
+
Project-URL: Homepage, https://github.com/kdeldycke/workflows
|
|
7
|
+
Project-URL: Repository, https://github.com/kdeldycke/workflows
|
|
8
|
+
Project-URL: Funding, https://github.com/sponsors/kdeldycke
|
|
9
|
+
Project-URL: Issues, https://github.com/kdeldycke/workflows/issues
|
|
10
|
+
Project-URL: Changelog, https://github.com/kdeldycke/workflows/blob/main/changelog.md
|
|
11
|
+
Keywords: build-automation,changelog-formatter,ci-cd,cli,formatting,github-actions,labels,linting,markdown,mypy,nuitka,packaging,pypi,python,release-automation,sphinx,sponsorship,terminal,typo,workflow-reusable,yaml
|
|
12
|
+
Classifier: Development Status :: 5 - Production/Stable
|
|
13
|
+
Classifier: Environment :: Console
|
|
14
|
+
Classifier: Framework :: Sphinx
|
|
15
|
+
Classifier: Framework :: Pelican
|
|
16
|
+
Classifier: Intended Audience :: Developers
|
|
17
|
+
Classifier: License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)
|
|
18
|
+
Classifier: Operating System :: MacOS :: MacOS X
|
|
19
|
+
Classifier: Operating System :: Microsoft :: Windows
|
|
20
|
+
Classifier: Operating System :: POSIX :: Linux
|
|
21
|
+
Classifier: Operating System :: POSIX :: BSD :: FreeBSD
|
|
22
|
+
Classifier: Operating System :: POSIX :: BSD :: NetBSD
|
|
23
|
+
Classifier: Operating System :: POSIX :: BSD :: OpenBSD
|
|
24
|
+
Classifier: Programming Language :: Python :: 3
|
|
25
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
26
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
27
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
28
|
+
Classifier: Programming Language :: Python :: 3.14
|
|
29
|
+
Classifier: Programming Language :: Python :: Implementation :: CPython
|
|
30
|
+
Classifier: Programming Language :: Unix Shell
|
|
31
|
+
Classifier: Topic :: Documentation :: Sphinx
|
|
32
|
+
Classifier: Topic :: File Formats :: JSON
|
|
33
|
+
Classifier: Topic :: Security
|
|
34
|
+
Classifier: Topic :: Software Development :: Build Tools
|
|
35
|
+
Classifier: Topic :: Software Development :: Compilers
|
|
36
|
+
Classifier: Topic :: Software Development :: Documentation
|
|
37
|
+
Classifier: Topic :: Software Development :: Libraries :: Python Modules
|
|
38
|
+
Classifier: Topic :: Software Development :: Quality Assurance
|
|
39
|
+
Classifier: Topic :: Software Development :: Version Control :: Git
|
|
40
|
+
Classifier: Topic :: System :: Archiving :: Packaging
|
|
41
|
+
Classifier: Topic :: System :: Installation/Setup
|
|
42
|
+
Classifier: Topic :: System :: Shells
|
|
43
|
+
Classifier: Topic :: System :: Software Distribution
|
|
44
|
+
Classifier: Topic :: Terminals
|
|
45
|
+
Classifier: Topic :: Text Processing :: Markup :: HTML
|
|
46
|
+
Classifier: Topic :: Text Processing :: Markup :: Markdown
|
|
47
|
+
Classifier: Topic :: Utilities
|
|
48
|
+
Classifier: Typing :: Typed
|
|
49
|
+
Requires-Python: >=3.11
|
|
50
|
+
Description-Content-Type: text/markdown
|
|
51
|
+
Requires-Dist: boltons>=25.0.0
|
|
52
|
+
Requires-Dist: bump-my-version<1.1.1,>=0.32.2
|
|
53
|
+
Requires-Dist: click-extra>=7.0.0
|
|
54
|
+
Requires-Dist: extra-platforms>=4.0.0
|
|
55
|
+
Requires-Dist: packaging>=25.0
|
|
56
|
+
Requires-Dist: py-walk>=0.3.3
|
|
57
|
+
Requires-Dist: PyDriller>=2.6
|
|
58
|
+
Requires-Dist: pyproject-metadata>=0.9.0
|
|
59
|
+
Requires-Dist: pyyaml>=6.0.3
|
|
60
|
+
Requires-Dist: wcmatch>=10.0
|
|
61
|
+
Provides-Extra: test
|
|
62
|
+
Requires-Dist: coverage[toml]~=7.12.0; extra == "test"
|
|
63
|
+
Requires-Dist: pytest~=9.0.0; extra == "test"
|
|
64
|
+
Requires-Dist: pytest-cases~=3.9.1; extra == "test"
|
|
65
|
+
Requires-Dist: pytest-cov~=7.0.0; extra == "test"
|
|
66
|
+
Requires-Dist: pytest-github-actions-annotate-failures~=0.3.0; extra == "test"
|
|
67
|
+
Requires-Dist: pytest-randomly~=4.0.0; extra == "test"
|
|
68
|
+
Provides-Extra: typing
|
|
69
|
+
Requires-Dist: types-boltons~=25.0.0.20250822; extra == "typing"
|
|
70
|
+
Requires-Dist: types-PyYAML~=6.0.12.9; extra == "typing"
|
|
71
|
+
|
|
72
|
+
# `gha-utils` CLI + reusable workflows
|
|
73
|
+
|
|
74
|
+
[](https://pypi.org/project/gha-utils/)
|
|
75
|
+
[](https://pypi.org/project/gha-utils/)
|
|
76
|
+
[](https://pepy.tech/projects/gha_utils)
|
|
77
|
+
[](https://github.com/kdeldycke/workflows/actions/workflows/tests.yaml?query=branch%3Amain)
|
|
78
|
+
[](https://app.codecov.io/gh/kdeldycke/workflows)
|
|
79
|
+
|
|
80
|
+
Thanks to this project, I am able to **release Python packages multiple times a day with only 2-clicks**.
|
|
81
|
+
|
|
82
|
+
This repository contains a collection of reusable workflows and its companion CLI called `gha-utils` (which stands for *GitHub action workflows utilities*).
|
|
83
|
+
|
|
84
|
+
It is designed for `uv`-based Python projects (and Awesome List projects as a bonus).
|
|
85
|
+
|
|
86
|
+
It takes care of:
|
|
87
|
+
|
|
88
|
+
- Version bumping
|
|
89
|
+
- Formatting autofix for: Python, Markdown, JSON, typos
|
|
90
|
+
- Linting: Python types with `mypy`, YAML, `zsh`, GitHub actions, links, Awesome lists, secrets
|
|
91
|
+
- Compiling of Python binaries for Linux / macOS / Windows on `x86_64` & `arm64`
|
|
92
|
+
- Building of Python packages and upload to PyPi
|
|
93
|
+
- Git version tagging and GitHub release creation
|
|
94
|
+
- Synchronization of: `uv.lock`, `.gitignore`, `.mailmap` and Mermaid dependency graph
|
|
95
|
+
- Auto-locking of inactive closed issues
|
|
96
|
+
- Static image optimization
|
|
97
|
+
- Sphinx documentation building & deployment, and `autodoc` updates
|
|
98
|
+
- Label management, with file-based and content-based rules
|
|
99
|
+
|
|
100
|
+
Nothing is done behind your back. A PR is created every time a change is proposed, so you can inspect it, ala dependabot.
|
|
101
|
+
|
|
102
|
+
## `gha-utils` CLI
|
|
103
|
+
|
|
104
|
+
### Ad-hoc execution
|
|
105
|
+
|
|
106
|
+
Thanks to `uv`, you can install and run `gha-utils` in one command, without polluting your system:
|
|
107
|
+
|
|
108
|
+
```shell-session
|
|
109
|
+
$ uvx gha-utils
|
|
110
|
+
Usage: gha-utils [OPTIONS] COMMAND [ARGS]...
|
|
111
|
+
|
|
112
|
+
Options:
|
|
113
|
+
--time / --no-time Measure and print elapsed execution time. [default:
|
|
114
|
+
no-time]
|
|
115
|
+
--color, --ansi / --no-color, --no-ansi
|
|
116
|
+
Strip out all colors and all ANSI codes from output.
|
|
117
|
+
[default: color]
|
|
118
|
+
-C, --config CONFIG_PATH Location of the configuration file. Supports glob
|
|
119
|
+
pattern of local path and remote URL. [default:
|
|
120
|
+
~/Library/Application Support/gha-
|
|
121
|
+
utils/*.{toml,yaml,yml,json,ini,xml}]
|
|
122
|
+
--show-params Show all CLI parameters, their provenance, defaults
|
|
123
|
+
and value, then exit.
|
|
124
|
+
--verbosity LEVEL Either CRITICAL, ERROR, WARNING, INFO, DEBUG.
|
|
125
|
+
[default: WARNING]
|
|
126
|
+
-v, --verbose Increase the default WARNING verbosity by one level
|
|
127
|
+
for each additional repetition of the option.
|
|
128
|
+
[default: 0]
|
|
129
|
+
--version Show the version and exit.
|
|
130
|
+
-h, --help Show this message and exit.
|
|
131
|
+
|
|
132
|
+
Commands:
|
|
133
|
+
changelog Maintain a Markdown-formatted changelog
|
|
134
|
+
mailmap-sync Update Git's .mailmap file with missing contributors
|
|
135
|
+
metadata Output project metadata
|
|
136
|
+
test-plan Run a test plan from a file against a binary
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
```shell-session
|
|
140
|
+
$ uvx gha-utils --version
|
|
141
|
+
gha-utils, version 4.9.0
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
That's the best way to get started with `gha-utils` and experiment with it.
|
|
145
|
+
|
|
146
|
+
### Executables
|
|
147
|
+
|
|
148
|
+
To ease deployment, standalone executables of `gha-utils`'s latest version are available as direct downloads for several platforms and architectures:
|
|
149
|
+
|
|
150
|
+
| Platform | `x86_64` | `arm64` |
|
|
151
|
+
| ----------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
|
|
152
|
+
| **Linux** | [Download `gha-utils-linux-x64.bin`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-linux-x64.bin) | [Download `gha-utils-linux-arm64.bin`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-linux-arm64.bin) |
|
|
153
|
+
| **macOS** | [Download `gha-utils-macos-x64.bin`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-macos-x64.bin) | [Download `gha-utils-macos-arm64.bin`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-macos-arm64.bin) |
|
|
154
|
+
| **Windows** | [Download `gha-utils-windows-x64.exe`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-windows-x64.exe) | [Download `gha-utils-windows-arm64.exe`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-windows-arm64.exe) |
|
|
155
|
+
|
|
156
|
+
ABI targets:
|
|
157
|
+
|
|
158
|
+
```shell-session
|
|
159
|
+
$ file ./gha-utils-*
|
|
160
|
+
./gha-utils-linux-arm64.bin: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=520bfc6f2bb21f48ad568e46752888236552b26a, for GNU/Linux 3.7.0, stripped
|
|
161
|
+
./gha-utils-linux-x64.bin: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=56ba24bccfa917e6ce9009223e4e83924f616d46, for GNU/Linux 3.2.0, stripped
|
|
162
|
+
./gha-utils-macos-arm64.bin: Mach-O 64-bit executable arm64
|
|
163
|
+
./gha-utils-macos-x64.bin: Mach-O 64-bit executable x86_64
|
|
164
|
+
./gha-utils-windows-arm64.exe: PE32+ executable (console) Aarch64, for MS Windows
|
|
165
|
+
./gha-utils-windows-x64.exe: PE32+ executable (console) x86-64, for MS Windows
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
### Development version
|
|
169
|
+
|
|
170
|
+
To play with the latest development version of `gha-utils`, you can run it directly from the repository:
|
|
171
|
+
|
|
172
|
+
```shell-session
|
|
173
|
+
$ uvx --from git+https://github.com/kdeldycke/workflows -- gha-utils --version
|
|
174
|
+
gha-utils, version 4.18.2
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
## Reusable workflows collection
|
|
178
|
+
|
|
179
|
+
This repository contains workflows to automate most of the boring tasks.
|
|
180
|
+
|
|
181
|
+
These workflows are mostly used for Python projects and their documentation, but not only. They're all [reusable GitHub actions workflows](https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows).
|
|
182
|
+
|
|
183
|
+
Reasons for a centralized workflow repository:
|
|
184
|
+
|
|
185
|
+
- reusability of course: no need to update dozens of repository where 95% of workflows are the same
|
|
186
|
+
- centralize all dependencies pertaining to automation: think of the point-release of an action that triggers dependabot upgrade to all your repositories depending on it
|
|
187
|
+
|
|
188
|
+
### Guidelines
|
|
189
|
+
|
|
190
|
+
I don't want to copy-n-past, keep in sync and maintain another `N`th CI/CD file at the root of my repositories.
|
|
191
|
+
|
|
192
|
+
So my policy is: move every repository-specific config in a `pyproject.toml` file, or hide the gory details in a reused workflow.
|
|
193
|
+
|
|
194
|
+
### `.github/workflows/docs.yaml` jobs
|
|
195
|
+
|
|
196
|
+
- Autofix typos
|
|
197
|
+
|
|
198
|
+
- Optimize images
|
|
199
|
+
|
|
200
|
+
- Keep `.mailmap` up to date
|
|
201
|
+
|
|
202
|
+
- Update dependency graph of Python projects
|
|
203
|
+
|
|
204
|
+
- **Requires**:
|
|
205
|
+
- Python package with a `pyproject.toml` file
|
|
206
|
+
|
|
207
|
+
- Build Sphinx-based documentation and publish it to GitHub Pages
|
|
208
|
+
|
|
209
|
+
- **Requires**:
|
|
210
|
+
- Python package with a `pyproject.toml` file
|
|
211
|
+
- All Sphinx dependencies in a `docs` [extra dependency group](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#dependencies-and-requirements):
|
|
212
|
+
```toml
|
|
213
|
+
[project.optional-dependencies]
|
|
214
|
+
docs = [
|
|
215
|
+
"furo == 2024.1.29",
|
|
216
|
+
"myst-parser ~= 3.0.0",
|
|
217
|
+
"sphinx >= 6",
|
|
218
|
+
...
|
|
219
|
+
]
|
|
220
|
+
```
|
|
221
|
+
- Sphinx configuration file at `docs/conf.py`
|
|
222
|
+
|
|
223
|
+
- Sync awesome projects from `awesome-template` repository
|
|
224
|
+
|
|
225
|
+
### Why all these `requirements/*.txt` files?
|
|
226
|
+
|
|
227
|
+
Let's look for example at the `lint-yaml` job from [`.github/workflows/lint.yaml`](https://github.com/kdeldycke/workflows/blob/72a2e5d5cd6cf4d4c8369a17cee922a43acaa57f/.github/workflows/lint.yaml#L67-L85). Here [we only need to run `yamllint`](https://github.com/kdeldycke/workflows/blob/72a2e5d5cd6cf4d4c8369a17cee922a43acaa57f/.github/workflows/lint.yaml#L85). This CLI is [distributed on PyPi](https://pypi.org/project/yamllint/).
|
|
228
|
+
|
|
229
|
+
So we could have simply run it with this step:
|
|
230
|
+
|
|
231
|
+
```yaml
|
|
232
|
+
- run: |
|
|
233
|
+
uvx -- yamllint
|
|
234
|
+
```
|
|
235
|
+
|
|
236
|
+
Instead, we install it by pointing to the [`requirements/yamllint.txt` file](https://github.com/kdeldycke/workflows/blob/main/requirements/yamllint.txt):
|
|
237
|
+
|
|
238
|
+
```yaml
|
|
239
|
+
- run: |
|
|
240
|
+
uvx --with-requirements https://raw.githubusercontent.com/kdeldycke/workflows/main/requirements/yamllint.txt -- yamllint
|
|
241
|
+
```
|
|
242
|
+
|
|
243
|
+
Why? Because I want the version of `yamllint` to be pinned. By pinning it, I make the workflow stable, predictable and reproducible.
|
|
244
|
+
|
|
245
|
+
So why use a dedicated requirements file? Why don't we simply add the version? Like this:
|
|
246
|
+
|
|
247
|
+
```yaml
|
|
248
|
+
- run: |
|
|
249
|
+
uvx -- yamllint==1.37.1
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
That would indeed pin the version. But it requires the maintainer (me) to keep track of new release and update manually the version string. That's a lot of work. And I'm lazy. So this should be automated.
|
|
253
|
+
|
|
254
|
+
To automate that, the only practical way I found was to rely on dependabot. But dependabot cannot update arbitrary versions in `run:` YAML blocks. It [only supports `requirements.txt` and `pyproject.toml`](https://github.com/dependabot/dependabot-core/blob/c938bbf7cb4da88053d4379dcab297a3eaa8c0a7/python/lib/dependabot/python/file_fetcher.rb#L24-L44) files for Python projects.
|
|
255
|
+
|
|
256
|
+
So to keep track of new versions of dependencies while keeping them stable, we've hard-coded all Python libraries and CLIs in the `requirements/*.txt` files. All with pinned versions.
|
|
257
|
+
|
|
258
|
+
And for the case we need to install all dependencies in one go, we have a [`requirements.txt` file at the root](https://github.com/kdeldycke/workflows/blob/main/requirements.txt) that is referencing all files from the `requirements/` subfolder.
|
|
259
|
+
|
|
260
|
+
> [!NOTE]
|
|
261
|
+
> In the future, we might be able to get rid of this workaround by [relying on Renovate](https://github.com/kdeldycke/workflows/issues/1728).
|
|
262
|
+
|
|
263
|
+
### Permissions and token
|
|
264
|
+
|
|
265
|
+
This repository updates itself via GitHub actions. It particularly updates its own YAML files in `.github/workflows`. That's forbidden by default. So we need extra permissions.
|
|
266
|
+
|
|
267
|
+
Usually, to grant special permissions to some jobs, you use the [`permissions` parameter in workflow](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) files. It looks like this:
|
|
268
|
+
|
|
269
|
+
```yaml
|
|
270
|
+
on: (...)
|
|
271
|
+
|
|
272
|
+
jobs:
|
|
273
|
+
|
|
274
|
+
my-job:
|
|
275
|
+
runs-on: ubuntu-latest
|
|
276
|
+
permissions:
|
|
277
|
+
contents: write
|
|
278
|
+
pull-requests: write
|
|
279
|
+
|
|
280
|
+
steps: (...)
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
But the `contents: write` permission doesn't allow write access to the workflow files in the `.github` subfolder. There is `actions: write`, but it only covers workflow runs, not their YAML source file. Even a `permissions: write-all` doesn't work. So you cannot use the `permissions` parameter to allow a repository's workflow update its own workflow files.
|
|
284
|
+
|
|
285
|
+
You will always end up with this kind or errors:
|
|
286
|
+
|
|
287
|
+
```text
|
|
288
|
+
! [remote rejected] branch_xxx -> branch_xxx (refusing to allow a GitHub App to create or update workflow `.github/workflows/my_workflow.yaml` without `workflows` permission)
|
|
289
|
+
|
|
290
|
+
error: failed to push some refs to 'https://github.com/kdeldycke/my-repo'
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
> [!NOTE]
|
|
294
|
+
> That's also why the Settings > Actions > General > Workflow permissions parameter on your repository has no effect on this issue, even with the `Read and write permissions` set:
|
|
295
|
+
> 
|
|
296
|
+
|
|
297
|
+
To bypass the limitation, we rely on a custom access token. By convention, we call it `WORKFLOW_UPDATE_GITHUB_PAT`. It will be used, [in place of the default `secrets.GITHUB_TOKEN`](https://github.com/search?q=repo%3Akdeldycke%2Fworkflows%20WORKFLOW_UPDATE_GITHUB_PAT&type=code), in steps in which we need to change the workflow YAML files.
|
|
298
|
+
|
|
299
|
+
To create this custom `WORKFLOW_UPDATE_GITHUB_PAT`:
|
|
300
|
+
|
|
301
|
+
- From your GitHub user, go to `Settings` > `Developer Settings` > `Personal Access Tokens` > `Fine-grained tokens`
|
|
302
|
+
- Click on the `Generate new token` button
|
|
303
|
+
- Choose a good token name like `workflow-self-update` to make your intention clear
|
|
304
|
+
- Choose `Only select repositories` and the list the repositories in needs of updating their workflow YAML files
|
|
305
|
+
- In the `Repository permissions` drop-down, sets:
|
|
306
|
+
- `Contents`: `Access: **Read and Write**`
|
|
307
|
+
- `Metadata` (mandatory): `Access: **Read-only**`
|
|
308
|
+
- `Pull Requests`: `Access: **Read and Write**`
|
|
309
|
+
- `Workflows`: `Access: **Read and Write**`
|
|
310
|
+
> [!NOTE]
|
|
311
|
+
> This is the only place where I can have control over the `Workflows` permission, which is not supported by the `permissions:` parameter in YAML files.
|
|
312
|
+
- Now save these parameters and copy the `github_pat_XXXX` secret token
|
|
313
|
+
- Got to your repo > `Settings` > `Security` > `Secrets and variables` > `Actions` > `Secrets` > `Repository secrets` and click `New repository secrets`
|
|
314
|
+
- Name your secret `WORKFLOW_UPDATE_GITHUB_PAT` and copy the `github_pat_XXXX` token in the `Secret` field
|
|
315
|
+
|
|
316
|
+
Now re-run your actions and they should be able to update the workflow files in `.github` folder without the `refusing to allow a GitHub App to create or update workflow` error.
|
|
317
|
+
|
|
318
|
+
### Release management
|
|
319
|
+
|
|
320
|
+
It turns out [Release Engineering is a full-time job, and full of edge-cases](https://web.archive.org/web/20250126113318/https://blog.axo.dev/2023/02/cargo-dist).
|
|
321
|
+
|
|
322
|
+
Things have improved a lot in the Python ecosystem with `uv`. But there are still a lot of manual steps to do to release.
|
|
323
|
+
|
|
324
|
+
So I made up this [`release.yaml` workflow](https://github.com/kdeldycke/workflows/blob/main/.github/workflows/release.yaml), which:
|
|
325
|
+
|
|
326
|
+
1. Extracts project metadata from `pyproject.toml`
|
|
327
|
+
1. Generates a build matrix of all commits / os / arch / CLI entry points
|
|
328
|
+
1. Builds Python wheels with `uv`
|
|
329
|
+
1. Compiles binaries of all CLI with Nuitka
|
|
330
|
+
1. Tag the release commit in Git
|
|
331
|
+
1. Produces attestations of released artefacts
|
|
332
|
+
1. Publish new version to PyPi
|
|
333
|
+
1. Publish a GitHub release
|
|
334
|
+
1. Attach and rename build artifacts to the GitHub release
|
|
335
|
+
|
|
336
|
+
## Changelog
|
|
337
|
+
|
|
338
|
+
A [detailed changelog](changelog.md) is available.
|
|
339
|
+
|
|
340
|
+
## Used in
|
|
341
|
+
|
|
342
|
+
Check these projects to get real-life examples of usage and inspiration:
|
|
343
|
+
|
|
344
|
+
-  [Awesome Falsehood](https://github.com/kdeldycke/awesome-falsehood) - Falsehoods Programmers Believe in.
|
|
345
|
+
-  [Awesome Engineering Team Management](https://github.com/kdeldycke/awesome-engineering-team-management) - How to transition from software development to engineering management.
|
|
346
|
+
-  [Awesome IAM](https://github.com/kdeldycke/awesome-iam) - Identity and Access Management knowledge for cloud platforms.
|
|
347
|
+
-  [Awesome Billing](https://github.com/kdeldycke/awesome-billing) - Billing & Payments knowledge for cloud platforms.
|
|
348
|
+
-  [Meta Package Manager](https://github.com/kdeldycke/meta-package-manager) - A unifying CLI for multiple package managers.
|
|
349
|
+
-  [Mail Deduplicate](https://github.com/kdeldycke/mail-deduplicate) - A CLI to deduplicate similar emails.
|
|
350
|
+
-  [dotfiles](https://github.com/kdeldycke/dotfiles) - macOS dotfiles for Python developers.
|
|
351
|
+
-  [Click Extra](https://github.com/kdeldycke/click-extra) - Extra colorization and configuration loading for Click.
|
|
352
|
+
-  [workflows](https://github.com/kdeldycke/workflows) - Itself. Eat your own dog-food.
|
|
353
|
+
-  [Wiki bot](https://github.com/themagicalmammal/wikibot) - A bot which provides features from Wikipedia like summary, title searches, location API etc.
|
|
354
|
+
-  [Stock Analysis](https://github.com/themagicalmammal/stock-analyser) - Simple to use interfaces for basic technical analysis of stocks.
|
|
355
|
+
-  [GeneticTabler](https://github.com/themagicalmammal/genetictabler) - Time Table Scheduler using Genetic Algorithms.
|
|
356
|
+
-  [Excel Write](https://github.com/themagicalmammal/excel-write) - Optimised way to write in excel files.
|
|
357
|
+
|
|
358
|
+
Feel free to send a PR to add your project in this list if you are relying on these scripts.
|
|
359
|
+
|
|
360
|
+
## Release process
|
|
361
|
+
|
|
362
|
+
All steps of the release process and version management are automated in the
|
|
363
|
+
[`changelog.yaml`](https://github.com/kdeldycke/workflows/blob/main/.github/workflows/changelog.yaml)
|
|
364
|
+
and
|
|
365
|
+
[`release.yaml`](https://github.com/kdeldycke/workflows/blob/main/.github/workflows/release.yaml)
|
|
366
|
+
workflows.
|
|
367
|
+
|
|
368
|
+
All there's left to do is to:
|
|
369
|
+
|
|
370
|
+
- [check the open draft `prepare-release` PR](https://github.com/kdeldycke/workflows/pulls?q=is%3Apr+is%3Aopen+head%3Aprepare-release)
|
|
371
|
+
and its changes,
|
|
372
|
+
- click the `Ready for review` button,
|
|
373
|
+
- click the `Rebase and merge` button,
|
|
374
|
+
- let the workflows tag the release and set back the `main` branch into a
|
|
375
|
+
development state.
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
gha_utils/__init__.py,sha256=YrXVrnWt4EVlLQN2GckAOhdwyc27Ij9Nw3OxJAHJLYg,866
|
|
2
|
+
gha_utils/__main__.py,sha256=Dck9BjpLXmIRS83k0mghAMcYVYiMiFLltQdfRuMSP_Q,1703
|
|
3
|
+
gha_utils/changelog.py,sha256=JR7iQrWjLoIOpVNe6iXQSyEii82_hM_zrYpR7QO_Uxo,5777
|
|
4
|
+
gha_utils/cli.py,sha256=hIinAyFzmgpAk52DDAS4_IZXcbzYxHgTgPYX7dL8Y04,15271
|
|
5
|
+
gha_utils/mailmap.py,sha256=oQt3m0hj-mwg7WxsuJQXWeQTFjlkqTgRNjYsUv7dlYQ,7013
|
|
6
|
+
gha_utils/matrix.py,sha256=K0J-OHHEXibBTRmuCmyvscSjRGPPsGRuwp9rKnlj8KI,12486
|
|
7
|
+
gha_utils/metadata.py,sha256=NZRNiOSMk8dHXZHpmHoRKwLwOTqeXJRmLK9sSKNarCA,61684
|
|
8
|
+
gha_utils/py.typed,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
|
|
9
|
+
gha_utils/test_plan.py,sha256=-Uwe1Y5xCNHuXERzGsZV3aaZvbvITNR1nxVFbIB3c1s,14573
|
|
10
|
+
gha_utils-4.24.0.dist-info/METADATA,sha256=Y7m4WgZHqgYsqExvgDom4v731pD4VCsbjMlDSWwRdgc,21804
|
|
11
|
+
gha_utils-4.24.0.dist-info/WHEEL,sha256=_zCd3N1l69ArxyTb8rzEoP9TpbYXkqRFSNOD5OuxnTs,91
|
|
12
|
+
gha_utils-4.24.0.dist-info/entry_points.txt,sha256=8bJOwQYf9ZqsLhBR6gUCzvwLNI9f8tiiBrJ3AR0EK4o,54
|
|
13
|
+
gha_utils-4.24.0.dist-info/top_level.txt,sha256=C94Blb61YkkyPBwCdM3J_JPDjWH0lnKa5nGZeZ5M6yE,10
|
|
14
|
+
gha_utils-4.24.0.dist-info/RECORD,,
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
gha_utils
|