release dist-manifest.json describes artifacts that do not exist

[turbocrime]

source.tar.gz and source.tar.gz.sha256 are not uploaded as release artifacts, though they are generated by cargo dist and described in dist-manifest.json

this seems to be the relevant section of the workflow

penumbra/.github/workflows/release.yml

Lines 126 to 145 in b6fe24f

	- id: cargo-dist
	name: Post-build
	# We force bash here just because github makes it really hard to get values up
	# to "real" actions without writing to env-vars, and writing to env-vars has
	# inconsistent syntax between shell and powershell.
	shell: bash
	run: |
	# Parse out what we just built and upload it to the Github Release™
	echo "paths<<EOF" >> "$GITHUB_OUTPUT"
	jq --raw-output ".artifacts[]?.path | select( . != null )" dist-manifest.json >> "$GITHUB_OUTPUT"
	echo "EOF" >> "$GITHUB_OUTPUT"
	cp dist-manifest.json "$BUILD_MANIFEST_NAME"
	- name: "Upload artifacts"
	uses: actions/upload-artifact@v3
	with:
	name: artifacts
	path: |
	${{ steps.cargo-dist.outputs.paths }}
	${{ env.BUILD_MANIFEST_NAME }}

it seems the tar's artifact object in dist-manifest.json doesn't contain an 'assets' field so the tar and its checksum are ignored

[conorsch]

In #4130 (comment), I enabled attaching full source tarballs to the github release objects. We haven't released since that change was made, so I don't have an artifact to point to, but we should be releasing again this week, after which I'll confirm we have info there.

Relatedly (for #4255), I'm testing newer versions of cargo-dist in a private fork, and it looks like the newer versions do properly include the source tarball created by cargo-dist—which is separate from the automatically created github one—and corresponding checksum:

It'll probably be release n+2 that these changes make it to the monorepo, but they're coming. Thanks for the clear report, @turbocrime.