orf / cargo-bloat-action

Track rust binary sizes across builds using Github Actions

Hello! 👋

• 😎 I'm Tom
• 🏠 I live in London
• 🐍 I like Python
• 🦀 And rust
• 🌍 check out my blog

cargo-bloat-action's Issues

Error: Request failed with status code 404

I would love to use this action. However I'm failing to use it.
See: https://github.com/ks0n/goOSe/actions/runs/4670196537/jobs/8269632922?pr=132

Invalid JSON token F at position 1

...
##[error]Unexpected token F in JSON at position 1

This happens using d3735a7

Permission problem posting comments

I've setup by workflow pretty much as a copy/paste of the example repo. Everything looks good up until the moment it tries to post a comment:

(CI run log)

Is there some undocumented step I'm missing to set this up to reply to PR requests?

No comment on pull requests

So I added cargo bloat to a project, but cargo bloat doesn't add any comments, even though the tests are passing.

See for yourself: rustracer/rustracer#22

For the details, I'm seeing:

No mentions of a posting step, which we can see in this repo:

Thanks for your help 🙏

Not possible to change working folder

How can the step run in a folder that is not root ?

Usability improvements for non-crate mode

Taken from @therealprof in #147 (comment)

The issues noted here can be seen from: stm32-rs/stm32f4xx-hal#159 (comment)

It doesn't quite yield the expected output though. ;)

This is the human-readable output:

File  .text   Size         Crate Name
0.3%  39.2% 1.2KiB    dwt_blinky dwt_blinky::__cortex_m_rt_main
0.3%  36.9% 1.1KiB           std __udivmoddi4
0.0%   5.2%   158B           std __aeabi_memset4
0.0%   3.9%   116B   cortex_m_rt Reset
0.0%   3.3%   100B stm32f4xx_hal stm32f4xx_hal::dwt::Delay::delay_ticks
0.0%   3.2%    96B           std __aeabi_memset
0.0%   2.4%    72B stm32f4xx_hal stm32f4xx_hal::dwt::StopWatch::lap_time
0.0%   1.6%    48B stm32f4xx_hal core::iter::traits::iterator::Iterator::min_by_key::key::{{closure}}
0.0%   0.7%    22B           std __aeabi_uldivmod
0.0%   0.3%    10B   cortex_m_rt ResetTrampoline
0.0%   0.3%    10B           std core::panicking::panic_fmt
0.0%   0.3%    10B           std core::panicking::panic_bounds_check
0.0%   0.3%    10B           std core::panicking::panic
0.0%   0.3%    10B     [Unknown] main
0.0%   0.2%     6B           std __aeabi_memclr4
0.0%   0.1%     2B   cortex_m_rt HardFault_
0.0%   0.1%     2B    panic_halt rust_begin_unwind
0.0%   0.1%     2B   cortex_m_rt DefaultPreInit
0.0%   0.1%     2B   cortex_m_rt DefaultHandler_
0.0%   0.0%     0B               And 0 smaller methods. Use -n N to show more.
0.9% 100.0% 2.9KiB               .text section size, the file size is 342.6KiB

Few things of note:

• The toolchain is running on stable-x86_64-unknown-linux-gnu but the target is thumbv7em-none-eabihf (I would said the target is more important to know than the host architecture)
• @@ Breakdown per crate @@ should probably be @@ Breakdown per function @@ if the function mode is enabled
• It only lists the first two functions?
• While the total file size might be interesting every now and the really interesting metric here is the code (or .text) size, the complete file size also contains debugging information and other data which may not even end up in memory when running the binary

Sane handling of non-bin and non-lib crates

I understand that this action has the dubious convenience of parsing the manifest and adding all the packages that cargo bloat wouldn't into the list of packages to process. This is an acceptable (if inefficient) method, but it has a few problems.

Normally, cargo bloat ignores the projects that it can't work with. The action fails and stops.

Normally you can manually specify the packages (or binaries) for which we need to test for bloat. In this action I have to specify every workspace in the package (which normally outnumber the libraries). Moreover, the syntax is not explained. I expected a sequence to be an acceptable input.

Solution

1. Don't fail fast on crates that are not supported. Just skip them
2. Don't try to outsmart cargo bloat.
3. Instead of specifying the exclude crates specify included packages.

Not caching previous build

We've been trying to properly integrate this and we're receiving:

Unable to download cargo-bloat == latest from the tool cache: Error: Unexpected HTTP response: 403

Refs: https://github.com/UpdateHub/updatehub/actions/runs/173213014

We're out of ideas what might be causing this issue. Is this a known issue?

Size difference between Ubuntu & MacOS builds?

Hello!

I am seeing in my CI reports that the total size is ~6mb - this is built on Ubuntu. While on my mac I can see the release build cosnuming ~2.2mb. Is such a difference possible? Is it maybe action not building with release?

Thanks,
H.

"Request failed with status code 404" during "Recording" step

I'm seeing what appear to be 404 errors during the "Recording" step of the Cargo bloat action: https://github.com/FrancisRussell/zoog/runs/5788290182?check_suite_focus=true. I'm assuming this is an issue in the cargo bloat action, but the error is pretty vague and I've not touched Github actions in a while.

Use cargo-bloat-action without --crates?

Thanks for creating this action for one of my most beloved tools. Of course I immediately had to try it on one of my embedded crates now that #145 has landed. Unfortunately it seems to rely on the use of the --crates flag which is unfortunate because that one is not useful in this case.

Is there any way this action could accept non---crates output as well?

cf.
https://github.com/stm32-rs/stm32f4xx-hal/pull/159/checks?check_run_id=665421950

Allow to select crate from the workspace

There should be a way to select a crate from workspace with multiple crates. Perhaps it is a duplicate of the #145 issue, but I think that this is a slightly different issue.

Fetching last build fails

I'm having trouble setting up your action. Particularly, the initial bootstrap, since your action fails at trying to fetch the previous step that doesn't exist. Since I don't see any way in which I can set it up to be the first run, I would imagine that this is one of many usability oversights in your action.

I don't actually want you to reply to this issue, I want you to ghost it, so that I can convince our team that we don't need your hacky piece of ... generously put.. software, and convince them to write a different action for our specific uses.

Configure flags passed to `cargo bloat`

Is it possible to configure the feature flags passed to cargo bloat?

Analyze snapshots in runner

Thanks for the nice action!

I have a question about this action.
This seems to use cloud-function to analyze snapshots.

If it's right, do you have plan to analyze them in runner?
I want to keep data, cargo bloat results, in private github.

Cache the results in git-notes

Just want to mention there is something builtin called git-notes. Maybe you can use that 🤔

References:

• Git Dark Magic
• nodejs wrapper
• my experiment to store then graph some benchmark on each PR's commit

This step has been truncated due to its large size.

Thank you for your work, but it seems that this workflow does not work properly on larger projects.

Github Action will prompt This step has been truncated due to its large size.

Is there a way to use just cargo-bloat without cargo-tree or to get some lighter and faster analysis and results?

ref: datafuselabs/databend#2173