Create release packages using GitHub Actions #122
Comments
|
It might be simpler to remove the extended attributes from any files in the working directory as part of the release process, e.g.: |
|
That is just yet another step to mess up. An automated procedure is preferred and this is a sufficient pain point for to make it happen. |
|
I've been thinking of a similar strategy too. The libgeos team have a release.yml workflow as inspiration. And now their md5sum from (e.g) geos-3.12.1.tar.bz2 at https://github.com/libgeos/geos/releases/tag/3.12.1 is identical to the one at https://download.osgeo.org/geos/ which is neat. This idea applies to PROJ too. |
|
I implemented automated release artifact generation (and signing!) using GitHub Actions in libgeotiff recently. This could be adapted to PROJ/PROJ-data without much trouble. |
Generating the zip and tar.gz files for the PROJ-data releases have proven to be unreliable on the Mac that I am currently using when preparing new releases. Both releases in the 9.4 series have been affected and included unwanted ._-files. To prevent this in the future a new workflow based on GitHub Actions will be investigated.
Ideally, a pushed git tag will trigger creation of the release packages and store them as artifacts attached to given workflow run. This would mean that when a tag such as
1.18.0RC1is pushed a workflow will be triggered that createsPROJ-data-1.18RC1.tar.gzandPROJ-data-1.18RC1.zipand stores them as downloadable artifacts. Upload to download.osgeo.org will be a manual process as previously.The text was updated successfully, but these errors were encountered: