Skip to content

Add SemVer compatibility checks to CI #3560

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 7, 2025
Merged

Add SemVer compatibility checks to CI #3560

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 57 additions & 0 deletions .github/workflows/semver.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
name: SemVer checks
on:
push:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we filter it to just when the backport X tag is applied?

Copy link
Contributor Author

@tnull tnull Jan 29, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you don't mean here but on: pull_request below? At least not generally, otherwise the PRs towards (eg. #3567) the release branches would also need that label, which doesn't make sense in our "needs to be backported" semantics.

We could potentially see whether it's possible to only apply it on PRs towards main that have the label but I don't really see the argument for the complication as running it on every PR shouldn't be that costly to begin with. But, if we really want to do it, I'd prefer to first land this PR and assert everything is robustly working as intended before introducing further complications, see below.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you don't mean here but on: pull_request below?

I meant by running via something like this:

on:
  pull_request_target:
    types: [opened, labeled]
...
  if: startsWith('backport', github.event.label.name)

otherwise the PRs towards (eg. #3567) the release branches would also need that label, which doesn't make sense in our "needs to be backported" semantics.

We can check for either condition, we can write code in if statements on the jobs :)

We could potentially see whether it's possible to only apply it on PRs towards main that have the label but I don't really see the argument for the complication as running it on every PR shouldn't be that costly to begin with.

Just annoying cause it'll always be failing, but if we filter on the label then it should only fail when its actually something worth investigating.

But, if we really want to do it, I'd prefer to first land this PR and assert everything is robustly working as intended before introducing further complications, see below.

Sure, that's fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just annoying cause it'll always be failing, but if we filter on the label then it should only fail when its actually something worth investigating.

Why would it always be failing? It doesn't fail in either case, if the changes aren't breaking compared to the baseline. On main (where we bumped to 0.2.0+git) it picks 0.1 as the baseline, and in the feature branch the latest patch release.

branches-ignore:
- master
pull_request:
branches-ignore:
- master

jobs:
semver-checks:
runs-on: ubuntu-latest
steps:
- name: Checkout source code
uses: actions/checkout@v4
- name: Install Rust stable toolchain
run: |
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --profile=minimal --default-toolchain stable
rustup override set stable
- name: Check SemVer with default features
uses: obi1kenobi/cargo-semver-checks-action@v2
with:
feature-group: default-features
- name: Check SemVer *without* default features
uses: obi1kenobi/cargo-semver-checks-action@v2
with:
feature-group: only-explicit-features
- name: Check lightning-background-processor SemVer
uses: obi1kenobi/cargo-semver-checks-action@v2
with:
package: lightning-background-processor
feature-group: only-explicit-features
features: futures
- name: Check lightning-block-sync SemVer
uses: obi1kenobi/cargo-semver-checks-action@v2
with:
package: lightning-block-sync
feature-group: only-explicit-features
features: rpc-client,rest-client
- name: Check lightning-transaction-sync electrum SemVer
uses: obi1kenobi/cargo-semver-checks-action@v2
with:
manifest-path: lightning-transaction-sync/Cargo.toml
feature-group: only-explicit-features
features: electrum
- name: Check lightning-transaction-sync esplora-blocking SemVer
uses: obi1kenobi/cargo-semver-checks-action@v2
with:
manifest-path: lightning-transaction-sync/Cargo.toml
feature-group: only-explicit-features
features: esplora-blocking
- name: Check lightning-transaction-sync esplora-async SemVer
uses: obi1kenobi/cargo-semver-checks-action@v2
with:
manifest-path: lightning-transaction-sync/Cargo.toml
feature-group: only-explicit-features
features: esplora-async
Loading