search

xobs / wishbone-utils

Utilities for working with a Wishbone bridge
9 stars 5 forks source link

cirrus: alternative CI to consider for FreeBSD #14

Closed kevans91 closed 4 years ago

kevans91 commented 4 years ago

This one builds on a native FreeBSD GCE image, but I understand if you'd rather not have yet-another-CI-environment. You can sign up on https://cirrus-ci.com/ for the GitHub integration, if the permissions seem agreeable enough -- I don't recall anything too nasty in there.

xobs commented 4 years ago

Does this generate build artifacts like we get with travis?

kevans91 commented 4 years ago

Does this generate build artifacts like we get with travis?

As far as I can tell it supports collecting arbitrary artifacts from within the working directory -- they describe it a bit under "Artifacts Instructions" on https://cirrus-ci.org/guide/writing-tasks/

xobs commented 4 years ago

The actual build process is in ci/before_deploy.sh:

    test -f Cargo.lock || cargo generate-lockfile

    # TODO Update this to build the artifacts that matter to you
    cross rustc --bin wishbone-tool --target $TARGET --release -- -C lto

    # TODO Update this to package the right artifacts
    cp target/$TARGET/release/wishbone-tool$EXTENSION $stage/

    cd $stage
    tar czf $src/$CRATE_NAME-$TRAVIS_TAG-$TARGET.tar.gz *
    cd $src

    rm -rf $stage

For freebsd, $EXTENSION is naturally "". I think the compilation command could be kept to the same cargo build --release, but I'd like the output file to have the same wishbone-tool-$TAG-$TARGET format.

What would be the best distribution format? How hard is it to make a FreeBSD package? Or would the bare .tar.gz be acceptable?

kevans91 commented 4 years ago

I'm working on whipping up the cirrus spec based on that- thanks!

FreeBSD packages are a little more annoying to build, but if we just structure it kinda right by putting wishbone-tool in the right spot (${PREFIX}/bin) and distribute a .tgz that'll generally be sufficient. We'll end up creating a wishbone-tool port that generates a package effectively the exact same but with some other METADATA, so that would be the best path for someone to test out a build artifact as they can just (cd /; tar -xvf wishbone-tool-${TAG}-freebsd-amd64.tar.gz)

kevans91 commented 4 years ago

Updated version that generates a .tar.gz somewhat resembling a FreeBSD package. Right now it spits out artifacts that look like: wishbone-tool-e789d4d1393ee0669a94d399719ae5b40e59cebb-freebsd-amd64.tar.gz

I couldn't tell from their documentation if there's a more appropriate env var to use for the build ID. They have separate hash vars (used above) and tag name vars, but intuitively I'd think you're wanting something more like "tag name or hash if untagged" and it's not clear that such a var exists.

xobs commented 4 years ago

It should only deploy if the tag is set. Otherwise it should just build.

By the way, it looks like the cross command as used in the build system here has freebsd disabled (https://github.com/rust-embedded/cross/blob/master/docker/disabled/Dockerfile.x86_64-unknown-freebsd), which is probably the source of most of these issues. Using a different CI is the correct approach.

xobs commented 4 years ago

Due to https://github.com/xobs/wishbone-utils/issues/11 we've moved the repository over to litex-hub/wishbone-utils. I'll see what it takes to get "Cirrus CI" enabled there so that we can move forward.

Another option is to run freebsd under qemu, which seems to be the standard way to do it when using Travis. That might also work better, since the litex-hub account has a Travis-CI Pro account that builds faster.