The format check script currently outputs "true" if there were files that need
reformatting and "false" if not, which is useful for gradle but less so for
other applications (notably commit hooks). Terminate with an exit code of 1
if the format check fails.
TESTED: Tried this from both a pre-commit hook and from the gradle build.
* Fix problems with the format tasks
The format check is using python2, and if "python" doesn't exist on the path
(or isn't python 2, or there is any other error in the python code or in the
shell script...) the format check just succeeds.
This change:
- Refactors out the gradle code that finds a python3 executable and use it
to get the python executable to be used for the format check.
- Upgrades google-java-format-diff.py to python3 and removes #! line.
- Fixes shell script to ensure that failures are propagated.
- Suppresses error output when checking for python commands.
Tested:
- verified that python errors cause the build to fail
- verified that introducing a bad format diff causes check to fail
- verified that javaIncrementalFormatDryRun shows the diffs that would be
introduced.
- verified that javaIncrementalFormatApply reformats a file.
- verified that well formatted code passes the format check.
- verified that an invalid or missing PYTHON env var causes
google-java-format-git-diff.sh to fail with the appropriate error.
* Fix presubmit issues
Omit the format presubmit when not in a git repo and remove unused "string"
import.
* Pass --java-binary to _all_ formatter invocations
When implementing a flag to pass in the java binary to
google-java-format-diff.py, I missed the location in showNoncompliantFiles
which gets run before a check.
This change also refactors the core logic of the script so that
google-java-format-diff.py is only called from one place and (in all but one
case) only one time.
Tested:
Ran check format and show, with and without diffs present in the tree.
* Allow java-format to use java from the PATH
When invoking java from the google-java-format-git-diff.sh script, if there is
no JAVA_HOME environment variable, attempt to instead run the java binary that
is on the PATH.
This also adds a few checks to verify that a java binary is available in one
of those locations and that the version discovered is Java 11 (which we know
to be compatible with the google-java-format jar).
Tested:
- unset JAVA_HOME, verified that we get the version on the PATH
- Set JAVA_HOME to an invalid directory, verified that we get an error.
- Changed the "which" command to lookup an nonexistent binary, unset JAVA_HOME
and verified that we get a "java not found" error.
- Changed the path to point to an old version of java, verified that we get a
"bad java version" error.
- Verified that the script still runs normally.
* Don't use --fork-point to determine merge base
It turns out that the --fork-point option is subtle and error-prone. Its
intent is not to show the nearest common base commit, but rather the commit
on a branch that the HEAD (in this case) was originally forked off of,
_whether it is currently part of the history of the specified branch or not_
(this can happen if the branch is rewritten). The option also relies on the
presence of the fork point in the reflog for the branch, which can be
discarded in the course of a "git gc".
It is fairly easy to construct a case where the use of --fork-point causes an
error and outputs nothing. In fact, I discovered the problem as a result of
this occuring spontaneously on one of my own branches (likely related to a
rebase). Since the fork-point is empty, we end up diffing against the index
instead of the common commit.
This may have been a factor in some of the unrelated reformatting that we've
seen in past PRs.
Change this to a simple "merge-base origin/master HEAD", which outputs the
commit id of the most recent common base revision.
This change also quotes the forkPoint variable, which likely would have
resulted in an error in this case instead of silently producing the wrong
output.
* Print out env variables in java format
Print out JAVA_HOME and PATH variable in the google-java-format-diff.py script
immediately prior to running the underlying java program that does the actual
format checking.
* Use the java binary from JAVA_HOME for java-format
Use "$JAVA_HOME/bin/java" for invoking the java format check instead of
whatever version of java happens to be on the path.
* Removed unused import
* Enable Java 11 features
As of this commit Java 11 must be used to build. The generated bytecode
is still at Java 8 due to App Engine task queue limit.
Also fixed a bug where the included google-java-format jar file is not
used, requiring the user to install it separately.
See: https://cloud.google.com/appengine/docs/standard/java/taskqueue/push
* Upgrade to Truth 1.0
Refactored fail(...) to assertWithMessage().fail().
Upgraded com.google.monitoring-client family of dependencies to 1.0.6
Also fixed bad use of io.StringIO (on binary buffer) recently introduced to
google-java-format-diff.py.
* Only apply Google Java format to changed lines
* Only apply Google Java format to changed lines
* Only apply Google Java format to changed regions
Diffs are relative to origin/master.
Three tasks are added:
- javaIncrementalFormatCheck is added to the build workflow, and
will abort build if format violations are found.
- javaIncrementalFormatApply needs to be manually invoked to correct
format violations, the same behavior as spotlessApply.
- javaIncrementalFormatDryRun shows the changes that would happen if
javaIncrementalFormatApply is invoked.
These tasks work from the root directory and process the buildSrc directory
too.
The Spotless Java config is removed.
* Only apply Google Java format to changed regions
Diffs are relative to origin/master.
Three tasks are added:
- javaIncrementalFormatCheck is added to the build workflow, and
will abort build if format violations are found.
- javaIncrementalFormatApply needs to be manually invoked to correct
format violations, the same behavior as spotlessApply.
- javaIncrementalFormatDryRun shows the changes that would happen if
javaIncrementalFormatApply is invoked.
These tasks work from the root directory and process the buildSrc directory
too.
The Spotless Java config is removed.
* Only apply Google Java format to changed regions
Diffs are relative to origin/master.
Three tasks are added:
- javaIncrementalFormatCheck is added to the build workflow, and
will abort build if format violations are found.
- javaIncrementalFormatApply needs to be manually invoked to correct
format violations, the same behavior as spotlessApply.
- javaIncrementalFormatDryRun shows the changes that would happen if
javaIncrementalFormatApply is invoked.
These tasks work from the root directory and process the buildSrc directory
too.
The Spotless Java config is removed.
* Only apply Google Java format to changed regions
Diffs are relative to origin/master.
Three tasks are added:
- javaIncrementalFormatCheck is added to the build workflow, and
will abort build if format violations are found.
- javaIncrementalFormatApply needs to be manually invoked to correct
format violations, the same behavior as spotlessApply.
- javaIncrementalFormatDryRun shows the changes that would happen if
javaIncrementalFormatApply is invoked.
These tasks work from the root directory and process the buildSrc directory
too.
The Spotless Java config is removed.
