search

rgbkrk / libvirt-go

[DEPRECATED] Go bindings for libvirt
https://github.com/libvirt/libvirt-go
MIT License
166 stars 50 forks source link

ci: replace drone.io tests by Travis CI #97

Closed vincentbernat closed 8 years ago

vincentbernat commented 8 years ago

Not to be merged yet, not tested!

vincentbernat commented 8 years ago

Hum, #83 introduced use of virDomainInterface* which are only available from libvirt 1.2.14. What should we do about this? Give up about 1.2.12 compatibility or revert the commit since it is quite recent and tagged yet?

This PR shouldn't matter in the decision of course, I'll go another way if needed.

cc @dmacvicar @rgbkrk

dmacvicar commented 8 years ago

You can't let an Ubuntu version dominate all aspects of software development :-)

In terraform-provider-libvirt we had to build our own, given that TravisCI only supports ancient Ubuntu.

https://github.com/dmacvicar/terraform-provider-libvirt/blob/master/.travis.yml

dmacvicar commented 8 years ago

(btw, compatibility was originally broken here https://github.com/rgbkrk/libvirt-go/pull/79 and discussed here https://github.com/rgbkrk/libvirt-go/issues/50)

vincentbernat commented 8 years ago

Oh, great! I didn't find an appropriate PPA. I'll update the .travis.yaml to do like you did. I'll also update the README with the minimal version of libvirt supported.

rgbkrk commented 8 years ago

If we broke backwards compatibility with the API we should likely revert the commits.

vincentbernat commented 8 years ago

We broke compatibility with libvirt 1.2.12. I wouldn't say that backward compatibility is broken. Code that was working with a previous version will still work if libvirt is recent enough. I don't have an opinion on this matter (personally, I am using a more recent version of libvirt)

vincentbernat commented 8 years ago

What would be possible would be to use tags to build or not build features requiring a more recent version of libvirt. For example, let's suppose we stick with libvirt 1.2.12, people can enable more features with the tag "future". We would put those features in distinct files with

// +build future

And people would need to use -tags future. Or maybe -tags libvirt.future to avoid collision. Or we could use -tags libvirt.1.2.14 which would enable all features compatible with libvirt 1.2.14:

// +build libvirt.1.2.13 libvirt.1.2.14

I think this proposition is the most extensive one (hoping we can use a dot).

feiskyer commented 8 years ago

+1 for moving to travis.

vincentbernat commented 8 years ago

Ok, so libvirt is now compiled from source. Tests are done for Go 1.5 and Go 1.6. libvirt 1.2.2 and 1.2.14 are tested. And I have added a commit to make the conditional compilation like I described above.

A project needing features from libvirt 1.2.14 should build with -tags libvirt.1.2.14. Only a few tags are valid (currently one) to not have too long // +build lines. But let's suppose we want to add feature virDomanRename from libvirt 1.2.19, we would add the tag libvirt.1.2.19 and a user wanting this feature would build with -tags libvirt.1.2.19, we would add a domain_1.2.19.go file with// +build libvirt.1.2.19 and the domain_1.2.14.go file would get // +build libvirt.1.2.14 libvirt.1.2.19.

We can of course only keep the first commit and I can do a PR for the second one.

vincentbernat commented 8 years ago

And integration tests are not run. Maybe at a later point.

rgbkrk commented 8 years ago

Thank you so much for this legwork @vincentbernat