rustfmt currently has a runtime dependency on the sysroot. So when we
build a standalone rustfmt binary we need to set `LD_LIBRARY_PATH` so
each rustfmt binary knows where to find it's dependencies.
When running our Diff-Check job to test PRs for breaking changes it's
often the case that both the master rustfmt binary and the feature
branch binary have the same runtime dependencies so we only need to
set `LD_LIBRARY_PATH` once.
However, when running the diff-check job against a subtree sync PR that
assumption doesn't hold. The subtree sync PR bumps the required
toolchain used to build rustfmt and therefore the binary that gets built
for the subtree sync PR has a different runtime dependency than the
master rustfmt binary.
Now we set `LD_LIBRARY_PATH` twice to account for this potential
difference.
These changes mostly improve logging out the cargo version and version
of the two rustfmt binaries that are compiled. Some other minor logging
changes were made as well to add some whitespace to improve visual
clarity when looking at the logs in the GitHub Actions console.
There was an issue with the script when passing optional rustfmt configs
without specifying a commit hash. Because these optional values are
passed via positional arguments the configs ($4) would be used in place
of the commit hash ($3). Now that we set a default value for the
optional commit hash we avoid this problem.
The `set -e` option is used to immediately exit if any command exits
with a non zero exit status. This will help us catch errors in the
script, for example, needing the `LD_LIBRARY_PATH` to be set.
There were some upstream changes made a while back that requires this to
be set when building rustfmt from source like we do in the
`check_diff.sh` script.
See issue 5675 for more details.
This new action is intended to help us maintainers determine when feature
branches cause breaking formatting changes by running rustfmt (master)
and the feature branch on various rust repositories.
Over time I expect the list of checked projects to increase.
With this action in place we can more easily test that a new feature or
bug fix doesn't introduce breaking changes. Although this action needs to
be manually triggered right now, we might consider adding it to our CI
runs in the future.
