Skip to content

Test that libbpf-rs compiles without error in CI #53

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

Jump to bottom
Closed
alexforster opened this issue Jan 10, 2023 · 2 comments · Fixed by #55
Closed

Test that libbpf-rs compiles without error in CI #53

alexforster opened this issue Jan 10, 2023 · 2 comments · Fixed by #55
Assignees
@alexforster
Labels
enhancement New feature or request help-wanted Contributions welcome

Comments

@alexforster
Copy link
Member

Right now, there are no tests beyond ensuring that libbpf_set_print can be called. This ensures that something hasn't gone horribly wrong, but it doesn't do much to prevent API breakage.

In libbpf/libbpf-rs#303, a minor release of libbpf-sys broke libbpf-rs because bindgen's default behavior changed. This would have been prevented if we somehow tested compiling libbpf-rs in CI, but I don't know enough about GitHub CI to implement that.
@alexforster alexforster added enhancement New feature or request help-wanted Contributions welcome labels Jan 10, 2023
@danielocfb
Copy link
Collaborator

I was going to suggest doing just that, but then it struck me as too libbpf-rs centric for me to propose here :-) Glad you suggested this step.

danielocfb pushed a commit to danielocfb/libbpf-sys that referenced this issue Jan 11, 2023
@d-e-s-o
CI: test building libbpf-rs with libbpf-sys
f16da8c 
libbpf-sys aims to adhere to semantic versioning rules and indicate
incompatible changes by bumping major version numbers. However, it is
sometimes hard to identify breaking changes in advance and so breakage
may happen unintentionally. Detecting of such breaking changes also
becomes harder with auto-generated code, and libbpf-sys has a bunch of
that, owing due to it binding to a C library. For example, in libbpf-rs
[0] we have encountered a case where we were relying on a bindgen
generated type exported by libbpf-sys that got removed because bindgen
changed its behavior, which effectively is a semver violation.

To aid with the detection such unintended incompatibilities, this change
adds a CI step that builds the most recent published version of
libbpf-rs with the current libbpf-sys snapshot, to flag accidental
breakage.

[0] libbpf/libbpf-rs#303

Closes: libbpf#53
danielocfb pushed a commit to danielocfb/libbpf-sys that referenced this issue Jan 11, 2023
@d-e-s-o
CI: test building libbpf-rs with libbpf-sys
d171923 
libbpf-sys aims to adhere to semantic versioning rules and indicate
incompatible changes by bumping major version numbers. However, it is
sometimes hard to identify breaking changes in advance and so breakage
may happen unintentionally. Detecting of such breaking changes also
becomes harder with auto-generated code, and libbpf-sys has a bunch of
that, owing due to it binding to a C library. For example, in libbpf-rs
[0] we have encountered a case where we were relying on a bindgen
generated type exported by libbpf-sys that got removed because bindgen
changed its behavior, which effectively is a semver violation.

To aid with the detection such unintended incompatibilities, this change
adds a CI step that builds the most recent published version of
libbpf-rs with the current libbpf-sys snapshot, to flag accidental
breakage.

[0] libbpf/libbpf-rs#303

Closes: libbpf#53
Signed-off-by: Daniel Müller <[email protected]>
This was referenced Jan 11, 2023
Merged
Closed
alexforster pushed a commit that referenced this issue Jan 26, 2023
@d-e-s-o @alexforster
CI: test building libbpf-rs with libbpf-sys
e8afb2b 
libbpf-sys aims to adhere to semantic versioning rules and indicate
incompatible changes by bumping major version numbers. However, it is
sometimes hard to identify breaking changes in advance and so breakage
may happen unintentionally. Detecting of such breaking changes also
becomes harder with auto-generated code, and libbpf-sys has a bunch of
that, owing due to it binding to a C library. For example, in libbpf-rs
[0] we have encountered a case where we were relying on a bindgen
generated type exported by libbpf-sys that got removed because bindgen
changed its behavior, which effectively is a semver violation.

To aid with the detection such unintended incompatibilities, this change
adds a CI step that builds the most recent published version of
libbpf-rs with the current libbpf-sys snapshot, to flag accidental
breakage.

[0] libbpf/libbpf-rs#303

Closes: #53
Signed-off-by: Daniel Müller <[email protected]>
@alexforster
Copy link
Member Author

it struck me as too libbpf-rs centric for me to propose here

Note for others who may come across this issue: I'd be happy to accept tests for other libraries that depend on libbpf-sys.

@alexforster alexforster self-assigned this Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alexforster alexforster

Labels
enhancement New feature or request help-wanted Contributions welcome
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

CI: test building libbpf-rs with libbpf-sys danielocfb/libbpf-sys
2 participants
@alexforster @danielocfb