# Is it fine to download artifacts from Github for bisecting changes in Julia?
**URL:** https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159
**Category:** Internals & Design
**Tags:** recommendations, github, community, artifacts, bisect
**Created:** [January 23, 2024, 4:03pm UTC](https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159 "2024-01-23T16:03:10Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [January 23, 2024, 4:03pm UTC](https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159/1 "2024-01-23T16:03:10Z")
Regarding bisecting changes in the Julia implementation (usually on the `master` branch), I feel like people usually build each commit locally while bisecting? Is there a good reason for doing that, instead of just downloading the corresponding artifact from Github? Is it about bandwidth costs (not sure which of JuliaLang or Github has to foot that bill)?
In particular, it crossed my mind that it might be good to automate the process, and release such a Julia-bisecting tool, which would automatically both download the artifact and run the reproducer. Does this sounds like an OK idea, or like something in _dangerous territory_?
For completeness, this issue is tangentially related: [@nanosoldier bisect · Issue #177 · JuliaCI/Nanosoldier.jl · GitHub](https://github.com/JuliaCI/Nanosoldier.jl/issues/177)
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [January 23, 2024, 8:56pm UTC](https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159/2 "2024-01-23T20:56:48Z")
> [@nsajko](#):
>
> Is there a good reason for doing that, instead of just downloading the corresponding artifact from Github?
Which one?
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [January 23, 2024, 9:03pm UTC](https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159/3 "2024-01-23T21:03:19Z")
At the Github page for the Git history of `master`, each (or most of them?) commit is associated with some “checks” (build, test, doctest, etc., you know). Going to the page for the checks, one can select one of the “build” entries (for some system/architecture/OS configuration), and then select “Artifacts”.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [January 23, 2024, 9:21pm UTC](https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159/4 "2024-01-23T21:21:49Z")
That’s buildkite, not github, so it wasn’t clear to me what you were referring to. And those artifacts aren’t permanent, I think they’re deleted after 90 days or so, so a general bisection based on that isn’t going to fly, it’d work only on small ranges. I think @gbaraldi has done something like that, but probably based on the builds uploaded to the S3 bucket, not buildkite
---
### Author:  [@maleadt](https://discourse.julialang.org/u/maleadt)
#### Post date: [January 23, 2024, 9:28pm UTC](https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159/5 "2024-01-23T21:28:16Z")
As mentioned in the nanosoldier issue, [GitHub - maleadt/manyjulias](https://github.com/maleadt/manyjulias) was supposed to solve this by using elfshaker to compress Julia builds. Sadly, because of how we generate the sysimg, we don’t get the compression ratios that manyclangs does; each release still requires around 100GB of elfshaker packs. Could probably be improved by changing how we generate the sysimg, though.
---
### Author:  [@Lilith](https://discourse.julialang.org/u/Lilith)
#### Post date: [February 2, 2024, 12:14am UTC](https://discourse.julialang.org/t/is-it-fine-to-download-artifacts-from-github-for-bisecting-changes-in-julia/109159/6 "2024-02-02T00:14:24Z")
> each release still requires around 100GB of elfshaker packs.
100GB/release is quite viable to store. Storing 1.0-1.11 takes 1.1TB. At amazon S3 rates of $.023/GB/month, that’s $304/year. A 2TB hard drive costs $30-100 outright.
I think it would be reasonable to change the retention policy for at least one architecture from 90 days to indefinite so that tools like [GitHub - LilithHafner/Bisect.jl](https://github.com/LilithHafner/Bisect.jl) can provide exactly this feature.