Cargo dist #2528
Cargo dist #2528
Conversation
jackkleeman
force-pushed
the
cargo-dist
branch
30 times, most recently
from
6a4b888 to
d47feb8
Compare
jackkleeman
force-pushed
the
cargo-dist
branch
6 times, most recently
from
4e66c8f to
0e0575d
Compare
jackkleeman
force-pushed
the
cargo-dist
branch
from
0e0575d to
6023101
Compare
jackkleeman
force-pushed
the
cargo-dist
branch
from
228f4bd to
a0f5c13
Compare
There was a problem hiding this comment.
Thanks for changing our release infrastructure to use cargo dist @jackkleeman. Not an expert in dist but from what I can tell, it looks good to me. Would be great if we could try it out before release time to make sure that things are actually working (if there is kind of "dry-run" possible).
| @@ -16,6 +19,9 @@ jobs: | |||
| runs-on: ubuntu-latest | |||
| strategy: | |||
| matrix: | |||
| app_name: | |||
| - restate-cli | |||
| - restate-server | |||
There was a problem hiding this comment.
Should we also include restatectl?
There was a problem hiding this comment.
lets address this separately if we want to
| on: | ||
| pull_request: |
There was a problem hiding this comment.
Why is it important to run this workflow on pull requests? Running a release workflow on a pull request is on first sight a bit confusing to me.
There was a problem hiding this comment.
Ah ok, I guess we do it because we want to catch breaking changes to dist in a PR, right? If yes, then maybe let's document this somewhere.
There was a problem hiding this comment.
this is what dist suggests, and given that we will now run ci as part of the 'plan' stage, which is also what runs on prs, this seems sensible to me. i dont feel strongly about it, but it does mean we have effectively one ci workflow, and release is just about it 'going further' than the pr workflow.
There was a problem hiding this comment.
actually, i think i will change this around a bit
There was a problem hiding this comment.
ive moved ci to the 'host' stage, so we should still run it deliberately on pr instead of relying on the plan running on PR. but i think its still good for plan to run on each pr, so we know release.yml is still valid, as they suggest.
jackkleeman
force-pushed
the
cargo-dist
branch
from
a0f5c13 to
27a6e74
Compare
jackkleeman
force-pushed
the
cargo-dist
branch
from
8b5f7e2 to
a9441e1
Compare
|
Anything blocking this from being merged? or should I go ahead and merge it? |
Changes:
restate-{cli,server}.target.tar.xzinstead ofrestate.target.tar.gz. The tool doesn't support unifying packages together, we would have to make a new cargo package that contains both binary targets, which I'm not really that sure how to do. We could also just manually merge the two tars if people want thisThe following steps are a bit tricky to test, and we may need to debug on next release: