Add .cirrus.yml config for Cirrus-CI continuous integration #15
No reviewers
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi!15
Loading…
Reference in a new issue
No description provided.
Delete branch "cirrus"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Starting with Alpine and FreeBSD 11 and 12 tasks, others to be added.
Result from my fork: https://cirrus-ci.com/build/5686867601653760
See also #6
Even with #6, this does looks like an improvement. @z3ntu or do you suggest to merge the effort, or smth?
Also, in order to actually have this working, someone from libusb organisation has to give access to Cirrus-CI to this repository.
I'd rather use the builds.sr.ht service as it's open-source and could theoretically be self-hosted (and I doubt cirrus ci is open-source).
Since we already have Alpine and FreeBSD covered, I would suggest to close this PR.
@z3ntu do you see value in having Cirrus configuration available? Or in testing multiple versions of FreeBSD as @emaste did?
builds.sr.ht also has support for FreeBSD 11.x and FreeBSD CURRENT if we want that. Our freebsd builds use
freebsd/latestwhich is FreeBSD 12 currently. So if you want that, I can add them.But I think we're good with the current set of CIs (Alpine Linux with musl libc; Arch Linux with glibc, FreeBSD and three variants of Windows (mingw, cygwin & msbuild))
What could be done is to create "release candidate" CI configuration that makes a build for each OS supported on builds.sr.ht (Alpine Linux, Arch Linux, Debian, Fedora, FreeBSD, NixOS, OpenBSD, Ubuntu) and all versions supported there if someone has too much free time on their hands^^
builds.sr.ht sounds like a good approach, although IMO there's not much downside of having a configuration for Cirrus-CI in the tree also, as with .travis.yml / .appveyor.yml; people doing development on their fork may find it convenient.
@youw, @z3ntu, I support merging this if you agree. We don't have to have Cirrus set up for this repo, this could be for contributors convenience.
sounds fare
@ -0,0 +4,4 @@install_script: apk add autoconf automake g++ gcc libusb-dev libtool linux-headers eudev-dev make musl-devscript:- ./bootstrap- ./configure || { cat config.log; exit 1; }Why does this configure statement have the statement behind but not the others?
@ -0,0 +4,4 @@install_script: apk add autoconf automake g++ gcc libusb-dev libtool linux-headers eudev-dev make musl-devscript:- ./bootstrap- ./configure || { cat config.log; exit 1; }Oh, I probably added that while trying to track down some problem building on alpine, and did not run into a problem on the other OSes that required more details. It's probably a good idea for all cases and I'll update the PR.
Here's an Alpine, FreeBSD 11, FreeBSD 12 build: https://cirrus-ci.com/build/4977906178064384
One last note before merge: can we move this file to a
.buildssubfolder?No, Cirrus-CI only looks at the root dir of the repository (as does Travis-CI etc.)
I see, OK, let it be then.