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

[brlin-tw]

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]

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]

@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]

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.

[jnsgruk]

I'm going to close this - per my early comment, requiring a version in the snapcraft.yaml is a deliberate choice that increases the chance of build reproducibility.

While it would be good to expand to support any possible use-cases, doing so also increases complexity that we'll need to maintain.

These workflows are permissively licensed, so if anyone wanted to use them with slight modifications to not require a version, they can do so by forking and making those changes.