CI: add job to automate crate version bumping PR #8365
Conversation
|
As per my last discussion with Christian, the project's current preference is to manually update these crate versions whenever needed. @cdecker, could you please elaborate your reason for posterity? Or if you would like to reconsider, I can proceed with reviewing the PR. |
|
Keep in mind that this will only automatically create a PR to bump versions, not push to master directly. |
|
Thanks @daywalker90 for this PR, I have not been consistent publishing the crates, sorry for that, and automation is the way to address is, so thanks for taking the initiative. While working with the python bindings we discovered that there is an implicit coupling between pyln and CLN versions, which was ultimately detrimental, since plugins and apps could inadvertently end up being incompatible, because they were pinning a specific client library version. With the introdiuction of the crates we rethought things a bit, also because the tighter typing made some things we got away in python no longer possible. So we decided we'd decouple the crate versions from the CLN version, and maintain an explicit compatibility tracking, through the version annotations, for when fields and methods were introduced and removed. While we haven't yet drawn up the compatibility matrix, you'll notice that the So the rust crates, and likely the pyln packages eventually too, should be released often, have their own versioning scheme, that does not imply a one-to-one mapping between client library and node version. I think your PR is perfect, I would just change the trigger: a rust crate |
|
I'm not sure i understand: do you intend to tag a version like "cln-rpc-v0.5.0" and then let the CI job change that version to what it thinks is correct? That seems weird if it then releases v0.4.2 instead. |
daywalker90
force-pushed
the
crate-automation
branch
from
377c1a3 to
bbf9f08
Compare
|
For now i changed the ci job to allow for fine-grained selection of the specific crate and version part you want to bump via the |
|
Ok, maybe we're going too fancy with the tag trigger. I guess workflow dispatches allows us to specify some parameters? So we could make this a manually triggered only thing, and we specify the version number we expect this to become, then |
|
Sorry for bringing this up this late, but I just stumbled over https://axodotdev.github.io/cargo-dist/book/introduction.html and I wonder if there could be some parts of the workflow yaml that could be subsumed by it. |
daywalker90
force-pushed
the
crate-automation
branch
from
bbf9f08 to
2e328ef
Compare
|
Ok i overall simplified the action and removed the tag trigger and simplified the workflow trigger by using
This seems more for github releases i think (i could use this for my plugins). |
I want these to go out faster after a CLN release so here's a github action that will automatically create a PR (like daywalker90#20) to bump crate versions very similar to the python action. It works for rc, major and minor releases. Merging that PR will trigger the other action to publish them.
Please check that the Workflow permissions under "Settings->Actions->General" are "Read and Write Permissions" aswell as "Allow GitHub Actions to create and approve pull requests".
For this i had to centralize the version management of the affected crates.