Open jrwren opened 3 years ago
I don't really know how to add this as a GitHub Action, but here is my workaround for now:
You can use the following snippet to compile the exporter with musl for x86_64.
The binary will be in $(pwd)/target/x86_64-unknown-linux-musl/release/prometheus_wireguard_exporter
.
git clone https://github.com/MindFlavor/prometheus_wireguard_exporter.git
cd prometheus_wireguard_exporter
docker run --rm -it -v "$(pwd)":/home/rust/src ekidd/rust-musl-builder cargo build --release
The Docker build now cross build for all available architectures, maybe we can use it and send the built binaries (statically linked with musl bundled) to the Github API.
Now the problem comes with OSX since all musl cross building tooling is for linux and not darwin, I'm not sure it would work.
Anyway, I think it's best to just use a Github Action for it (duplicating the CI work, but oh well), ~https://github.com/marketplace/actions/rust-release-binary looks promising.~ (only supports x86_64 ugh)
Also note you could (trigger warning: sort of ugly) for Linux, as long as you have Docker, do:
docker pull mindflavor/prometheus_wireguard_exporter && \
containerid="$(docker create mindflavor/prometheus_wireguard_exporter)" && \
docker cp "$containerid:/usr/local/bin/prometheus_wireguard_exporter" /usr/local/bin/prometheus_wireguard_exporter && \
docker rm "$containerid"
And have the static binary on your host 😉 I'll dig on how to upload them to Github releases using a similar approach, at least we will have Linux binaries. OSX will have to wait though.
EDIT: That should do together with those ugly docker commands running in the CI. I'll do it sometime soon.
Is this ticket still alive? The PR could be merged without conflicts...
Hi @upstream-dmahlberg, I'll leave to @qdm12 to decide what to do on that PR. He's much more competent than me on the subject!
@MindFlavor @qdm12 Any updates on this?
Merged, sorry guys for the long delay. I'll try to dig into it in the coming weeks, to improve the CI pipeline.
EDIT: It's merged thanks @micxer so we should have binaries on tags.
This is awesome, thanks for the work on this! Any chance to get a new tag/release to publish initial binaries? :)
@micxer it doesn't look like it's building binaries on the latest tag, any clue why? I'm afk for the coming days so I can't really investigate.
is there any update. would be awesome if this is working, i want to add it to this https://github.com/voxpupuli/puppet-prometheus/ puppet module
I would appreciate binary builds as well. Is there anything I can do to help?
I'm not very experienced in Rust but I can help with setting up the pipelines for github actions. In theory it shouldn't be that hard to build the binaries, extract them and publish with github release. I don't know how compilation for rust on mac works but that might be trickier if it requires darwin build agents (if cross-compilation doesn't work).
You can just use GitHub Actions macOS runners for Mac. I have a project that builds my own rust project for Windows, Mac, and Linux on all x86 and arm architectures, which basically just consists of installing the correct target with rustup and then running cargo build --release
. It builds parallel too, because I use a matrix to select the os and target.
See the release
job: https://github.com/BBaoVanC/bobashare/blob/master/.github/workflows/deploy.yml
I managed to build those executables from the current source through github actions. Especially the FreeBSD version.
~dunno how log artifacts will be saved but you can download them here at the bottom:~ ~https://github.com/Kariton/prometheus_wireguard_exporter/actions/runs/6517589948~
I just realised that artifacts are not public. I uploaded them manually. https://github.com/Kariton/prometheus_wireguard_exporter/releases/tag/v3.6.6
Is there any hope that this will finally arrive?
I don't know how to set this up or if it can be automated with actions, but if someone can point me to docs and it is acceptable I'd love to send a PR to implement this.
I don't know rust and cargo and so I extracted a binary from the docker image. It works well, but it is less than ideal.