cargo-quickinstall
cargo-quickinstall copied to clipboard
alsuren
build packages for arm linux (for use on raspberry pi)
- [ ] try buliding inside an arm docker image, with qemu registered as the binfmt executor or whatever you call it https://github.community/t/testing-against-multiple-architectures/17111
It might be possible to use the infrastructure from the cross project, to build for multiple architectures.
My home automation server is a raspberry pi, so I have a vested interested in getting this working.
I had a go at doing this with cross, but no luck. https://github.com/alsuren/cargo-quickinstall/runs/5345278298?check_suite_focus=true
Thanks for the pointer. It looks like the standard tier is 6000 minutes/month (4 days) or something, which would be enough to get started with prototyping. The open source tier is about 10x this, and could be applied for once we had a PoC, to give us round the clock builds for a single architecture.
https://circleci.com/open-source/
I've not really used circleci before. It feels reasonable to hand over a copy of the GitHub Releases deploy key to circleci. We would need to find a way to make sure that the builder (which is building potentially untrusted code) does not have access to this secret (it just creates a tarball in a known location, that is then uploaded by a separately sandboxed process).
Instead of creating a commit to trigger a workflow, both CircleCI and GitHub Actions support making an api call and passing parameters so this could be used to trigger it. This would be simpler than having to generate different yaml and a commit each time something is built.
The commit-per-build was a decision that I made quite early on. Initially it seemed a bit questionable, but let me move quickly so I stuck with it. As time went on, I started hanging a bunch more things on top of it.
a) GitHub Releases requires a tag to attach release assets to, and having a commit per build gives me a convenient thing to tag. In theory, I could hang all of the tags off of a single commit though. This might be fine. I've not tried. Probably with doing an experiment in another repo to make sure git/GitHub don't shit the bed when you do this. I'd rather not get into the habit of deleting tags in this repo. b) I use "a commit without a tag" as a sign of a broken build (when calculating the list of broken packages that I should stop trying to build for a bit). This is easy to do in bash, without making calls to the GitHub Actions API.
I really need to draw a diagram of all of this nonsense. In the short term, I think we could get away with making a trigger-circleci/* branch namespace or something, without too much pain.
At some point, I should probably rewrite my cronjob logic in rust or something. That might make me more likely to reach for the GitHub Actions API when it makes sense. It would probably make the whole thing more maintainable as well.
Is this a thing that you would be interested in helping with?
FYI, Cirrus CI also has support for arm containers (using AWS's Graviton2 instances): https://cirrus-ci.org/guide/linux/
They don't have any minute limits, only concurrency limits: https://cirrus-ci.org/faq/#are-there-any-limits
@jack1142 Thanks for the hint. I would definitely accept patches that add support for free-tier non-github runners.
If anyone decides to have a stab at this but doesn't manage to get anywhere, please reply to this issue, saying what you got stuck on first. I recognise that my mess of bash scripts is really difficult to contribute to at the moment, and would like to do better. I have ideas of what I can do to make it better, but it would also be good to have some external feedback.
If anyone has experience with cirrus-ci, and wants to pair on this with me (evenings/weekends Europe/London time), please reply to this issue, and we can set something up.
I had a go at doing this with cross, but no luck. https://github.com/alsuren/cargo-quickinstall/runs/5345278298?check_suite_focus=true
Maybe you can try cargo-zigbuild?
I haven't tried it myself but according to is README, it supports aarch64-unknown-linux-gnu, so naturally it should also support armv7-unknown-linux-gnu and musl targets.
There's also a docker image for it on docker hub, looks like it is not hard to use it on github action.
well, not fixed :(
Can you elaborate on the problem please? I have already enabled armv7 and aarch64 linux gnu and musl targets.
i havent seen any builds for that arch go out for a while.
It needs to be triggered by people running cargo-binstall or cargo-quickinstall on their arm machine.
Also, many builds failed due to missing openssl and these crates just don't support vendor-openssl feature, thus we would have to add them to excludes file.
@Milo123459 Checkout release semantic-release-cargo 2.1.55, it has armv7/aarch64 linux gnu/musl and was published 2d ago.