Workflow race condition

[jpm-canonical]

There could be a race condition where latest/edge got updated after this workflow published, and before it can promote - making it promote a different snap revision than the one we tested.

1. Can we publish the same artifact to latest/beta?
2. Can we get the revision number from the publish step, and use that in the promote?

Originally posted by @jpm-canonical in #81 (comment)

[jpm-canonical]

Approach 1 fails. See workflow logs.

Publishing snap "matter-pi-gpio-commander_2.0+chip-5bff3a5a_arm64.snap"...
Installing Snapcraft...
/usr/bin/sudo snap install --classic snapcraft
snapcraft 8.3.2 from Canonical** installed
/snap/bin/snapcraft upload matter-pi-gpio-commander_2.0+chip-5bff3a5a_arm64.snap --release latest/beta/test
Uploading... (--->)
Uploading... (<---)
Status: processing
Status: error while processing
Issues while processing snap:
- binary_sha3_384: Error checking upload uniqueness.
Full execution log: '/home/runner/.local/state/snapcraft/log/snapcraft-20240828-111452.881[9](https://github.com/canonical/matter-pi-gpio-commander/actions/runs/10595393598/job/29361633789#step:3:10)83.log'
Error: The process '/snap/bin/snapcraft' failed with exit code 1

[farshidtz]

We could publish the snap to edge using command line (instead of the GH action), capture the revision number from the standard output, then pass it to the job for releasing that same revision to beta.