flip-link
flip-link copied to clipboard
knurling-rs
GHA support
Is there a way to use flip-link in a Github Action, without building it from source every time?
See https://github.com/Neotron-Compute/Neotron-BMC/runs/3152027601?check_suite_focus=true as an example.
Is there a way to use flip-link in a Github Action, without building it from source every time?
You mean providing build artifacts in this repo so that third party CI can "binary install" those? I know trust (Travis CI template) provided that functionality but I don't know if actions-rs provides similar functionality.
cc https://github.com/actions-rs/meta/issues/21 and also https://github.com/actions-rs/install
The trust template was ported to GHA and extended here: https://github.com/XAMPPRocky/mean-bean-ci-template
We could potentially use that to release binaries, but waiting for actions-rs to gain this functionality might be better, given that flip-link already builds very quickly.
For some value of quickly. It takes 58 seconds against my actual code build of 43 second.
Reading https://github.com/rust-embedded/embedonomicon/pull/72, perhaps it would suffice to offer an example of how to enable caching so that flip-link builds are bypassed that way instead.
I think providing build artifacts for releases is quite possible. I would limit it to a few major targets for the beginning and then wait for action-rs for a more holistic solution.
What do you think @thejpster?
Sure. I only need whatever GHA runs - x64 Linux I assume .
Yes. My thought was to just support the GHA targets for their linux, windows and macos machines. Thereby we cover the CI usecase, which should be enough for now.
The last flip-link release which you're using in CI has this dependency tree (and builds, without crate downloads, in 5.5s on my machine):
flip-link v0.1.4 (/home/jonas/dev/flip-link)
├── anyhow v1.0.40
├── env_logger v0.8.3
│ ├── atty v0.2.14
│ │ └── libc v0.2.94
│ ├── humantime v2.1.0
│ ├── log v0.4.14
│ │ └── cfg-if v1.0.0
│ ├── regex v1.5.4
│ │ ├── aho-corasick v0.7.18
│ │ │ └── memchr v2.4.0
│ │ ├── memchr v2.4.0
│ │ └── regex-syntax v0.6.25
│ └── termcolor v1.1.2
├── log v0.4.14 (*)
├── object v0.24.0
└── tempfile v3.2.0
├── cfg-if v1.0.0
├── libc v0.2.94
├── rand v0.8.3
│ ├── libc v0.2.94
│ ├── rand_chacha v0.3.0
│ │ ├── ppv-lite86 v0.2.10
│ │ └── rand_core v0.6.2
│ │ └── getrandom v0.2.3
│ │ ├── cfg-if v1.0.0
│ │ └── libc v0.2.94
│ └── rand_core v0.6.2 (*)
└── remove_dir_all v0.5.3
Current main branch only has this (and builds in 3 seconds on my machine):
flip-link v0.1.4 (/home/jonas/dev/flip-link)
├── anyhow v1.0.40
├── env_logger v0.8.3
│ └── log v0.4.14
│ └── cfg-if v1.0.0
├── log v0.4.14 (*)
├── object v0.25.2
│ └── memchr v2.4.0
└── tempfile v3.2.0
├── cfg-if v1.0.0
├── libc v0.2.94
├── rand v0.8.3
│ ├── libc v0.2.94
│ ├── rand_chacha v0.3.0
│ │ ├── ppv-lite86 v0.2.10
│ │ └── rand_core v0.6.2
│ │ └── getrandom v0.2.3
│ │ ├── cfg-if v1.0.0
│ │ └── libc v0.2.94
│ └── rand_core v0.6.2 (*)
└── remove_dir_all v0.5.3
With https://github.com/knurling-rs/flip-link/pull/51, the dependencies are further reduced (and it now builds in 2.5s):
flip-link v0.1.4 (/home/jonas/dev/flip-link)
├── anyhow v1.0.40
├── env_logger v0.8.3
│ └── log v0.4.14
│ └── cfg-if v1.0.0
├── getrandom v0.2.3
│ ├── cfg-if v1.0.0
│ └── libc v0.2.94
├── log v0.4.14 (*)
└── object v0.25.2
└── memchr v2.4.0
How long does it take in GHA?
From trying it only one time the main branch currently takes 32 seconds (see).
How long does it take in GHA?
5 seconds from scratch including crate download time: https://github.com/knurling-rs/flip-link/runs/4811186841?check_suite_focus=true#step:4:33
when build without optimizations: cargo install --debug
in any case, I looked into doing GitHub releases from GitHub Actions and, well, it doesn't look there's a canonical way to go about it. there are several options
- the now unmaintained GitHub action from GitHub itself
- 4 maintained actions listed from that unmaintained action
- Rust-Analyzer has its own action based on wasmtime's
so I too would prefer to wait until actions-rs provides something that works out of the box, preferably something that builds tarballs with some standardized name and that interops with actions-rs/install
perhaps it would suffice to offer an example of how to enable caching so that flip-link builds are bypassed that way instead.
PR #74 has an example of how to cache Cargo's registry and the target directory. I don't think that would help with cargo install-ed things though because the build artifacts for those crates are not placed in target but built in a separate directory (temporary directory maybe?)
if you want to cache the .cargo/bin directory, where cargo-install-ed things are stored, I think you would need to hash a file that contains the names and versions of the tools you install and use that as the cache key. also you would only get a speedups on a full cache hit because the "target directory" of cargo install would not be cached, only the final program binary would -- unless you use cargo install --target-dir I guess (haven't used that before).
For what it's worth I have been happily using https://github.com/softprops/action-gh-release for one of my projects.
But I can live with a five second install. Thank you all for working on this!
Just to come back to this, installing flip-link in GHA is taking 45 seconds, even with cargo install --debug flip-link. I can see in your latest CI run it's taking 37 seconds (and you have stuff cached whereas I don't).
@thejpster said:
Just to come back to this, installing flip-link in GHA is taking 45 seconds, even with
cargo install --debug flip-link. I can see in your latest CI run it's taking 37 seconds (and you have stuff cached whereas I don't).
I will investigate why the compile time regressed and work on releasing pre-build binaries.
You can now download binaries from the releases page, e.g. https://github.com/knurling-rs/flip-link/releases/tag/v0.1.8