Repository navigation
Refactor new code for GitHub releases #189
Description
Activity
- changed the title
[-]Refactor github/__main__.py to conform with the style of the rest of the project[/-][+]Refactor new code imported from GL workflow scripts to conform with the style of the rest of the project[/+]on Oct 21, 2025 Here's the complete list of changes requested originally:
- Please replace low-level code with code provided by apt* Python packages.
- While we are working with GitHub API for this executable I would recommend to leave it separate to any "generic" GitHub tooling we might need. Therefore the executable should be called something like gl-github-release and call a gardenlinux/github/release_main.py entrypoint.
- Please be aware of best-practices for Python imports. First the standard library (alphabetically sorted), afterwards third-party libraries and then relative ones. Furthermore the code now resists in the python-gardenlinux-lib repository, so all gardenlinux.* imports should be relative ones.
- This file (
github/__main__.py) needs refactoring. There are too many generic / helper functions doing various things needed for later release content creation. - Does it make sense to add this code (GitHub release creation) in a generic way to e.g. GardenLinuxRepo?
- Context managers should be used only as long for locking a file as it's needed. Class initialization and return may stay outside.
- This looks like another hardcoded file name (
.github_release_id). Please consider moving it to a constant or something that can be configured. - This code should be replaced by a third-party Python package providing support to talk to the GitHub API. If needed it may be encapsulated by one or more classes added to gardenlinux.github.
- I'm still not sure if flavors.yaml should be "checked" out here (
gardenlinux.github).
- changed the title
[-]Refactor new code imported from GL workflow scripts to conform with the style of the rest of the project[/-][+]Refactor new code for GitHub releases[/+]on Apr 29, 2026 Additional task:
Release page generation fails with errorgithub.GithubException.GithubException: Validation Failed: 422 {"message": "Validation Failed", "errors": [{"resource": "Release", "code": "custom", "field": "body", "message": "body is too long (maximum is 125000 characters)"}], "documentation_url": "https://docs.github.com/rest/releases/releases#create-a-release", "status": "422"}.There has been the idea to access a release asset called e.g.
cloud_images.mdorpackages.mdto remove specific sections from the release notes for GitHub limiting reasons (see #318, #319).With supported GitHub API this would mean to:
- Create an release with preliminary notes
- Upload assets to the release
- Iterate through the assets API endpoint to find a specific asset
- Access the JSON payload to get the correct download path
Alternatively you may just assume something like
releases/<tag>/download/<asset name>will be supported regardless of changes implemented by GitHub in the future. Even then HTTP headerresponse-content-disposition: attachmentis set meaning browsers try to download the file regardless of the content. This is officially documented here (To link directly to a download of your latest release asset that was manually uploaded, the suffix is '/releases/latest/download/asset-name.zip'.).There is no supported way to link assets to be viewed within the browser.
What would you like to be added:
Why is this needed:
Suggestions from @NotTheEvilOne:
do not use
s3_artifacts._bucketproperty, usebucket(without underscore) instead 189 refactor new code imported from gl workflow scripts #232add support for semantic versioning Semver support #219
use commit_id parameter for CName constructor 189 refactor new code imported from gl workflow scripts #232