Good morning <@U5FCZAAUU> and team :blobwave:! I'...
# maintainers
y
Good morning @uglyog and team blobwave! I've got a couple of PR's in pact-protobuf-plugin, and there are a couple of people waiting for an FFI release. Ready for a little brain dump of some of the things I think need playing out to get a release out with some of the outstanding changes. (so you might want a coffee before you read this 👇 😅 coffee2 ) The pact-protobuf-plugin musl PR's will close the loop on all the alpine stuff, so we will need to do a little release train • plugin releases ◦ pact-protobuf-plugin ◦ pact-csv-plugin ◦ update indexes to reference new plugins ◦ pact-plugin-cli ◦ pact-plugin-driver (is this needed or do they pickup the new index straight from the repo) • pact ffi ◦ ideally this will contain references to the new plugins, so they can pick up musl supported plugins with the auto-download functionality (via pact-plugin-driver) • pact-stub-server (can go independently) ◦ this should in theory ◦ publish new musl variants ◦ publish multi arch images to dockerhub and ghcr If you are happy with someone else getting involved in the mix, I can kick off the release train during the day, otherwise feel free to let me know if there is anything I've missed out and if you would rather do it yourself. I noticed that your groovy release scripts are used to kick off the release workflows by genning the changelog, sorting release numbers and pushing tags. There is an option to publish to Cargo as well, and I obviously don't have creds for those locally. Would you want to look at automating the release kick off (so it can be done via a workflow dispatch), and automate the publishing of the crates? rockon
r
No need to release pact-plugin-driver.
For pact ffi release, as there was a breaking change to pact_models, we have to release all the other libs first as ffi depends on everything. I've done most of then, just pact_consumer and pact_verifier need a release.
The reason for the Groovy scripts, is that they prompt each step, and are re-runnable by design. If a middle step fails, you can then fix it and re-run the release from there. With a a workflow dispatch, you have to fix failures by undoing was done up to the failure, fix the issue, and then run everything from the start again. With lots of waiting on CI builds. CI's are the worst things to use for releases.
I think it is good for someone else to do the release. We have had a few people over the years who can do it, but they have all gone on to better things. The only creds you need are push rights to GitHub and deploy permissions to crates.io.
Unfortunately, you do need the deploy permissions set for every crate, which is a bit of a pain.
m
I’m pretty sure I still have the access to do a release, should you decide to cross the street one fateful day
r
You sure do
y
Awesomesauce! I've currently got lost in the BSD matrix. I've been enjoying trying new aarch64 distros with my m1 mac, then got frustrated that cross couldn't build for some of the targets that Rust could support. I went on a mission to expand the gcc compiler collection on MacOS to cover more esoteric linux architectures, for both gnu and musl flavours. the gnu flavours are only relevant really for me now for Ruby, and also OCD completeness. Modified a tool called Macpine which is basically like lima, (linux machines on mac) to run more qemu images so i have the full suites of BSD's and a windows VM because Wine is slow although pretty useful. https://github.com/YOU54F/macpine/tree/bsd I really liked Orbstacks feature of basically wrapping up
docker run -v $PWD:/app <image> /bin/sh -c 'cd /app && <whatever>
so you can semi-transparently run linux binaries on a mac machine (similar to Rosetta or binfmt for linux peeps) It does it with nfs shares, but its not open source and that smokes pole. It also doesn't support BSD's and not being open source is no bueno. So I basically rebuilt that functionality in MacPine with Qemu. Ultimate goal for me is to be able to build/test all targets on my local machine, pretty transparently from my macos command line. Coupling it with a fork of https://github.com/nektos/act which allows you to run act as a self hosted runner https://github.com/ChristopherHX/github-act-runner means I can effectively run GH actions on my VM's and get coverage on all the machines without having to rely on CI systems that are underpowered, or don't cover the hardware I want to test. (might as well put the machines I have at home to some use) More than happy to adventure into the land of the rust releases, have built out a fair bit of it on my forks, to consume in downstream projects, so I can be fairly confident before it comes into the foundation. But computers do what computers do head splode