build: add github action for publishing crates

[manmartgarc]

Summary

First attempt at automating the publishing of libcst and libcst_derive to the crates.io registry on release and push to the main branch. Closes #967.

Notes

• The --allow-dirty flag was needed during testing since for some reason the files in the workflow are not committed to git and cargo publish complains about this.
• Not sure if we should keep the libcst_derive dependency of libcst as a local path dependency or if it should be changed to point to the crates.io registry.

Test Plan

The repository owner should set up a new secret with the crates.io token, and name it CRATES_IO_TOKEN so that the workflow can use the token when publishing to the registry.

[zsol]

This will publish to the version hardcoded in Cargo.toml, right? One of the nice things in the pypi workflow is that the version is derived from git, so we:

1. Don't have to make sure the version number in the two Cargo.toml files match the git tag and pyproject.toml
2. Can publish intermediate versions to a test registry; this is great for testing the release pipeline itself

Is there anything we can do to have these properties on the rust side?

[zsol]

why --allow-dirty?

[manmartgarc]

I was testing locally with nektos/act and was getting an issue where cargo publish wouldn't allow files that weren't committed, even though the files were actually committed. Not sure if this would be the case on GitHub

[manmartgarc]

This will publish to the version hardcoded in Cargo.toml, right? One of the nice things in the pypi workflow is that the version is derived from git, so we:

1. Don't have to make sure the version number in the two Cargo.toml files match the git tag and pyproject.toml
2. Can publish intermediate versions to a test registry; this is great for testing the release pipeline itself

Is there anything we can do to have these properties on the rust side?

I am assuming we should be able to derive the version from git, will check more on this. Regarding the second question there is a --dry-run flag that can be passed to cargo publish which will do everything up to publishing the crates on a registry.

[manmartgarc]

This will publish to the version hardcoded in Cargo.toml, right? One of the nice things in the pypi workflow is that the version is derived from git, so we:

1. Don't have to make sure the version number in the two Cargo.toml files match the git tag and pyproject.toml
2. Can publish intermediate versions to a test registry; this is great for testing the release pipeline itself

Is there anything we can do to have these properties on the rust side?

It looks like someone is doing this by replacing the version in the Cargo.toml file. Is this something you'd be open to?

[manmartgarc]

f23af55 adds:

• the functionality to do a --dry-run release on push and do the full release on release.
• Hackily replace the versions in the Cargo.toml files by the one in the current git tag using sed.

Not sure if this is good enough, but I wasn't able to find a homegrown way of using the tag in cargo publish. Another thing to note is that libcst is published using the local version of libcst_derive. I am not sure if we should also publish libcst_derive but publishing the latter might be avoided if only libcst should be on the registry.

[codecov-commenter]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (37277e5) 91.04% compared to head (f23af55) 91.04%.
Report is 5 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1012   +/-   ##
=======================================
  Coverage   91.04%   91.04%           
=======================================
  Files         255      255           
  Lines       26366    26366           
=======================================
  Hits        24004    24004           
  Misses       2362     2362           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[manmartgarc]

Huh. Why is there a typing error if no source changes were made?

[zsol]

I don't know, but it appears on all PRs recently. Some dependency must've changed

…

On Sun, 1 Oct 2023, 4:09 pm Manuel Martinez, ***@***.***> wrote: Huh. Why is there a typing error if no source changes were made? — Reply to this email directly, view it on GitHub <#1012 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQJNDDNXQOFDKZB2O4C2TX5GBSPANCNFSM6AAAAAA4MYDZLY> . You are receiving this because you commented.Message ID: ***@***.***>

[zsol]

FTR, I fixed this in #1032

[manmartgarc]

FTR, I fixed this in #1032

I'll be able to merge this into the PR later today 👍

[manmartgarc]

I had made a mess of the branch with a git pull --rebase but it looks like now the git history looks better. Not sure how this change is affecting the actions yet. Could you approve the workflow to see what happens?

[manmartgarc]

Bumping this. Are there any blockers currently?

[manmartgarc]

@zsol checking in on this. I see that the right versions are already on crates.io: https://crates.io/search?q=libcst. Is there anything else to do here?

[manmartgarc]

@zsol should I close this PR? I see v1.0.1 on crates.io, thinking this might be all set up?