search

snapcrafters / ci

Repository for shared CI tools and actions
https://github.com/snapcrafters/.github/wiki
MIT License
3 stars 7 forks source link

feat(release-to-candidate): Support projects that doesn't specify the `version` property #46

Open brlin-tw opened 3 months ago

brlin-tw commented 3 months ago

It is possible that the Snapcraft project doesn't specify the version property in the snapcraft.yaml, instead of setting the snap version string via the craftctl set version=_version_ mechanism. In this case, the parse-snapcraft-yaml job will set the version variable to null, making the release-to-candidate job unable to detect the built snap due to a filename mismatch:

Created snap package tesseract_5.4.1+pkg-481c_amd64.snap
b0c0e58155889237f0b06b0fde00022b99079102e00be507be13ecd891ab44c13637957525631012869dafb04aeefc7794526af071f76523fbedfb26e581e01d  tesseract_5.4.1+pkg-481c_amd64.snap
Revoking proxy token...
RUN: /usr/share/launchpad-buildd/bin/in-target scan-for-processes --backend=lxd --series=jammy --arch=amd64 SNAPBUILD-2576220
Scanning for processes to kill in build SNAPBUILD-2576220
Could not find tesseract_null_amd64.snap
Error: Process completed with exit code 1.

This patch enhances the release-to-candidate job so that the built snap will still be matched via filename matching.

Although projects that don't specify the version property aren't really compliant with the Snapcrafters policy, supporting this use case allows external projects to reuse the snapcrafters/ci/release-to-candidate GitHub Action job without the need to fork the project.

jnsgruk commented 3 months ago

Failing on projects that don't specify a version is more of a design choice than an oversight.

Ideally we'd like projects to be pulling versioned releases from tags, and having the version set makes it easier for us to automatically bump versions and trigger rebuilds.

brlin-tw commented 3 months ago

@jnsgruk

Ideally we'd like projects to be pulling versioned releases from tags, and having the version set makes it easier for us to automatically bump versions and trigger rebuilds.

Yeah this is rather a change for non-Snapcrafters projects(e.g. tesserarct-snap) with a different upstream version select strategy(e.g. selective-checkout) to work without implementing their own release-to-{candidate,beta,edge} GH action jobs.

I'm currently working with the Tesseract OCR upstream to re-enable their snap distribution and would like to reuse the Snapcrafters automation when possible.

brlin-tw commented 3 months ago

The Create tag step also depends on the version output from the snapcraft-yaml job so more changes need to be done in order for this to work.