Re-release latest release with vendor code
#23
Comments
|
Thanks @skeet70 for this issue. I have given up trying workarounds and will just track this waiting for a fix. |
|
Weird issue, normally cargo builds do a |
|
Very weird since the CI didn't error and the tests ran correctly. Anyway I published a new release which is 911kb and yanked the previous version. Unsure what happened. |
It seems that if a git submodule is not properly initialize on the machine that will publish the crate, cargo won't warn or detect it, as described in this issue rust-lang/cargo#8635. This is hard to detect because the CI is setup to properly `git clone --recursive` and therefore should not detect this issue. To reduce the likelyhood of #23 from happening again in the future, the `testcrate` was added as a dev-dedependecy to the root crate and the tests were moved to the root crate so that if `cargo test` is ran (even without the --workspace flag), the tests won't compile and the error should be detected.
|
Alright so it seems that this issue was caused by a weird interaction between cargo and git submodules that wasn't detected (rust-lang/cargo#8635) combined with the fact that the tests didn't link to the Feel free to close the issue if release |
|
It did solve the issue as I was able to reproduce it. I'll close, if it's still not solved for @andrewdavidmackenzie they can re-open it. |
|
Another fix (that I was working on in my fork but bailing on for now) would be to make a GH action do the release on a tag to the repo, so it'd only run after CI (when tagged) and would include the submodule checkout in its checkout action. As long as that action was used for releases, this problem won't happen again. |
|
That would work but the problem is that you have to give your access token to github to publish which is a security liability. At the end of the day, this is all a byproduct of sub modules being poorly implemented by git. Hardcoding a manual repo clone wouldn't lead to these issues. |
The
0.2.3+4.3.4release is only 10kb (vs 900kb in the past) and builds have started failing because they're missingvendorfiles. I think something went wrong in the recent release process that resulted in thevendorsubmodule not being packaged. It seems like0.2.3+4.3.4should be yanked/deprecated and0.2.4+4.3.4released with all the required files.@jean-airoldie
The text was updated successfully, but these errors were encountered: