Fix publish to upload wizened artifact

[jeffcharles]

I think the change in https://github.com/Shopify/javy/pull/205/files#diff-18497b72a2306fc2560475e2548cfe1b96b6206c395380437ba1fafefd66e126 introduced the problem. Currently testing in my personal fork to check that this fixes the issue before merging and cutting another release.

[jeffcharles]

My test publishing worked so this should fix the problem

[saulecabrera]

As a follow up: I wonder if we should either set some env vars in this workflow that hold the values of all the different files that are used or at least document what goes where. There's a lot of cognitive overhead here and I'm worried that this will continue to happen.

[jeffcharles]

Agreed on there's excessively high cognitive overhead.

Could you elaborate on how using env vars would reduce that? Is the idea that we would use an optional env vars when invoking make core to set the names of the two final Wasm files and then we would reference those same env vars further down when uploading the Wasm files to the artifacts, and then again later when invoking cargo build?

My thinking is that it we may benefit from having a parallel workflow that's similar to the publish pipeline that runs during CI so if that breaks, the author and the reviewers realize that the actual publish workflow would need to be updated as well. We'd only need a job to compile the core Wasm modules on Linux with a similar artifact upload and then a job to download the two artifacts and ensure a cargo build (possibly could even get away with a faster cargo check) succeeds. I would argue that a failing PR check would signal the author of the PR to think about the potential impact of their change on the publish workflow.