[tonytonycoder11]

The attestation and the record on the Packages panel in the release workflow looked up each archive through the latest version that pub.dev lists for a package. That field can still name the previous version for minutes after an upload. On 1.0.0 it did for two of the four packages when the record job read it, so the job tried to record the 0.2.0 archives of flutwire_http and flutwire_cloud_functions. Both jobs now look the archive up by the version of the tag, and wait up to ten minutes for pub.dev to serve it. The attestation could have gone wrong the same way. It did not on 1.0.0: the four archives verify, each against refs/tags/v1.0.0.

Checked locally by extracting the two steps from the workflow file and running them as they are written. The attestation step for the tag v1.0.0 writes the four digests that the published archives have. The record step for v1.0.0 finds each archive by its version and the record that was added by hand, and for v0.1.0, which has no records, finds the archive of that version and reaches the write, which was blocked for the test, so nothing was recorded. The workflow only runs on a tag, so GitHub cannot run it before the next release.

What this does not change: the record step still gets a 404 from the metadata endpoint with the token of the workflow, which has no write permission there. The records of the next release need to be added by hand, or with a personal access token in the ARTIFACT_METADATA_TOKEN secret, which the step already prefers.

Targets 1.1.0, as an Internal entry in the changelog.

[trueup-by-nacode-studios]

This pull request adds no capability the code did not already have.

_{2 files read · 946 ms · against d6d270d · engine 1.4.1}