I didn't know this, but storing artifacts for 90 days is free for open source projects on Github.
This action can be used to upload the artifact: https://github.com/actions/upload-artifact Looks like there is a REST API for listing and downloading artifacts: https://developer.github.com/v3/actions/artifacts/ And the Github CLI can probably use those APIs: https://cli.github.com/ So as Brennan says, one way to do it would be to store the artifact and some metadata about it after every run. Then have something that would download metadata, compare, and report. -adam On Thu, Jul 30, 2020 at 1:17 PM Brennan Ashton <bash...@brennanashton.com> wrote: > On Thu, Jul 30, 2020, 1:13 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > > > >>> It is a simple matter to see the cost of a PR if we add bloaty > > >>> (https://github.com/google/bloaty) to ci. > > >>> > > >> Great please file the simple PR to add it. This is not trivial as we > > >> need > > >> to manage the artifacts from previous builds to do the comparison or > > >> double > > >> the build time. We heard you last time, but someone has to do to the > > >> actual > > >> work. > > >> > > > The absolute size of a build by itself is not so useful. You would > > > need the size BEFORE the change (on the same base) for comparison > > > with the size AFTER the change. I assume that bloaty does not have > > > this A to B comparison built in? > > > > I am not a bloaty user so I might not be properly informed. But from > > what I see, it is used to determine the cause of code bloat by analyzing > > the .elf files. I think that would be a second step. A first, more > > trivial step would be to simply detect the size increase, perhaps just > > running 'size nuttx' and comparing to ... what? I imagine we would have > > to keep some artifacts from a previous nightly built to find the A size > > for the A-to-B comparison. If we detect a size increase, then bloaty > > should tell use why. > > > It will do both so might as well just save the output of it. Basically on > the CI job on merge into master we would generate the size/bloaty report > and save these artifacts next to the build (we do this for the source > bundle already) > > Then when the PR runs it would fetch this data from the master build and > pass it to bloaty to run the comparison report for the given build and > report it in the comments or something. > -- Adam Feuer <a...@starcat.io>
