I have identified two potential improvements for how we perform static analysis
on our code in our CI pipeline:
- The `giraffate/clippy-action` we currently use has not been updated to Node
20, and GitHub has repeatedly indicated that they will phase out actions that
do not support the latest Node versions. Despite my efforts to help with the
update by submitting a pull request upstream, it has been ignored for months
despite its perceived ease of review, raising concerns about the ongoing
maintenance of the action. This situation suggests we should explore
alternative methods for integrating Clippy with GitHub's UI.
- As evidenced by PR 632, thoroughly testing Rust crates for every possible
feature combination is often overlooked due to the tedious nature of the task.
Our current CI setup only checks two feature combinations, which is far from
comprehensive.
To address the first improvement, these changes drop `clippy-action` entirely in
favor of utilizing GitHub's native CodeQL SARIF (Static Analysis Results
Interchange Format) file integration. Since Clippy cannot directly output lints
in SARIF, `clippy-sarif` is used to convert Clippy's JSON output to SARIF.
Additionally, `sarif-fmt` is added to turn SARIF into a human-friendly display
format in the workflow run logs.
For the second improvement, let's use `cargo hack` with the `--feature-powerset`
flag to run Clippy for every possible feature combination. This approach strikes
a good balance between CI runtime and thoroughness, as the number of feature
combinations grows superlinearly with the number of features: running `cargo
nextest` for every powerset element would lead to excessively long CI times.
Fixes#619.
Interlacing still defaults to 0 when `--nx` is not specified and can
still be explicitly set even if it is (e.g. `-i 0 --nx` will still
deinterlace).
This PR adds the modified zeng ("mzeng") palette sorting method, in
addition to the existing luma and battiato methods. Speed is very
similar to the battiato method with slightly better results on average.
Resulting sizes from two different image sets (all indexed or able to be
indexed):
| | master | PR |
|-|-|-|
| Set 1 | 29,647,156 | 29,555,697 |
| Set 2 | 23,732,133 | 23,570,862 |
Additionally, I've added a new "first colour" heuristic for both the
mzeng and battiato methods: We use the most popular colour overall, but
only if it covers at least 15% of the image. This provided 13k savings
on Set 2 vs the edge colour heuristic (which is still used in the luma
sort).
Repology is a free service that monitors the packaging status of
projects in lots of package repositories, and offers a nice API to
generate badges with a summary of what OxiPNG versions are available in
what repositories. Let's introduce that to our README to make it easier
for users to decide whether to use a package manager of their
convenience, and visibilize the work package maintainers do with OxiPNG.
GitHub introduced free macOS ARM runners on January, and my experience
using them in other projects to improve CI times and be able to actually
run tests on Apple Silicon Macs has been positive. Let's use them in
OxiPNG to hopefully speed up CI a bit, and finally be able to run the
test suite on AArch64 macOS.
This PR adds a build script to generate a man page using clap_mangen, as
per this example:
https://github.com/sondr3/clap-man-example/blob/main/build.rs
I'm not sure what to actually do with the man file from here, I guess
it's up to the packaging process to do something with it?
See
https://github.com/shssoichiro/oxipng/issues/69#issuecomment-1963352536
Note I couldn't see a way to include the `DISPLAY` chunk names from the
constant as we did before. They're now just hardcoded into the help and
will require manually updating if the list changes.
Closes#526
---------
Co-authored-by: Alejandro González <me@alegon.dev>
This PR makes 3 changes that together reduce binary size by around 25%:
- Sets lto="fat" in cargo.toml
- Sets panic="abort" in cargo.toml
- Sets location-detail=none in RUSTFLAGS
Closes#571
An unrelated change: I've replaced the zopfli test file with a smaller
one that runs much faster, as well as removing the slow test for
issue-133 which was related to an older alpha optimisation that is no
longer relevant.
There was an incorrect glob `bench/*` that was doing nothing, since the
benchmarks are in `benches/`; when I corrected it to `benches/*`, `cargo
publish --dry-run` failed:
```
error: failed to verify package tarball
Caused by:
failed to parse manifest at `/home/ben/src/forks/oxipng/target/package/oxipng-9.0.0/Cargo.toml`
Caused by:
can't find `zopfli` bench at `benches/zopfli.rs` or `benches/zopfli/main.rs`. Please specify bench.path if you want to use a non-default path.
```
…so I stopped trying to exclude the benchmarks from published crates at
all.
-----
Then, I added `Dockerfile`, `index.html`, and `scripts/` to the list of
paths to exclude from published crates.
Finally, I added some unnecessary “dotfiles” to the list of paths to
exclude from published crates.
-----
Some of this was suggested in a [package review for Fedora
Linux](https://bugzilla.redhat.com/show_bug.cgi?id=2259760).
After the PR:
```
$ cargo package --list
.cargo/config.toml
.cargo_vcs_info.json
CHANGELOG.md
Cargo.lock
Cargo.toml
Cargo.toml.orig
LICENSE
MANUAL.txt
README.md
benches/deflate.rs
[…]
benches/zopfli.rs
src/atomicmin.rs
[…]
src/sanity_checks.rs
$ cargo publish --dry-run
[…]
Compiling oxipng v9.0.0 (/home/ben/src/forks/oxipng/target/package/oxipng-9.0.0)
Finished dev [optimized + debuginfo] target(s) in 15.76s
Packaged 37 files, 255.4KiB (61.6KiB compressed)
Uploading oxipng v9.0.0 (/home/ben/src/forks/oxipng)
warning: aborting upload due to dry run
```
