Our existing uber jar task overwrote duplicate files when merging JARs,
and this would break the application using Java SPI service(Beam library
is one of them) so we changed to use ShadowJar plugin as it provides a
convenient way to merge META-INF/services/* files when generating the
uber jar.
TESTED=Deployed spec11 pipeline successfully with the new nomulus.jar;
also randomly checked a few nomulus commands to make sure they are still
working.
Original change by cpovirk@cpovirk:rosie251284456-0055_Rosie:31511:citc on 2019/06/04 09:48:27.
Update to Truth 0.45, and address deprecations.
Renames may include:
- containsAllOf => containsAtLeast
- containsAllIn => containsAtLeastElementsIn
- isSameAs => isSameInstanceAs
- isOrdered => isInOrder
- isStrictlyOrdered => isInStrictOrder
The other major change is to change custom subjects to extend raw Subject instead of supplying type parameters. The type parameters are being removed from Subject. This CL will temporarily produce rawtypes warnings, which will go away when I remove the type parameters (as soon as this batch of CLs is submitted).
Some CLs in this batch also migrate calls away from actualAsString(). Its literal replacement is `"<" + actual + ">"` (unless an object overrides actualCustomStringRepresentation()), but usually I've made a larger change, such as switching from an old-style "Not true that..." failure message to one generated with the Fact API. In that case, the new code usually contains a direct reference to this.actual (a field that I occasionally had to create). Another larger change I sometimes made is to switch from a manual check-and-fail approach to instead use check(...). And sometimes I just remove a withMessage() call that's no longer necessary now that the code uses check(...), or I introduce a check(...) call. (An assertion made with check(...) automatically includes the actual value from the original subject, so there's no need to set it again with withMessage().)
Finally, there's one CL in this batch in which I migrate a Correspondence subclass to instead use Correspondence.from.
END_PUBLIC
If this is too many changes at once, let me know, and I can split it up and/or explain further. In the past, I've erred on the side of sending separate CLs for each change, which has required some owners to manually reapply each one, so now I'm trying this way.
Thanks again for your patience. There is an outside chance that this will be the last CL I send you before Truth 1.0 -- but certainly no promises :)
More information:
Renames:
[]
[]
[]
Removing type parameters: []
Migration from old fail*(...) methods to new ones and to check(...): []
Changes that replace assert*(...) with introduce check(...): []
Correspondence subclass to Correspondence.from: []
Tested:
TAP --sample ran all affected tests and none failed
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=251921007
This makes it easy to experiment with new dependency versions or new plugins
without having to update the lock files, by adding "-PdisableDependencyLocking=true" to any gradle command.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=249463575
This fixes linter errors when running gradle commands. However the investigation into the linter error revealed potential problematic behaviors with dependency resolution in Gradle. See the attached bug for details.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=249256283
I was testing this to see what the error was and I can't find one, so I assume it must have just been fixed at some point
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=248551972
This CL made the following changes to achieve the purpose:
1. Modified HttpProxy.java to generate a file containing Maven
coordinates for all requested JAR files. This is to replace
Gradle task "generateMavenCoordinateForDependency" which served
for the same purpose before. The reason is during the course
of the build, Gradle may request some POM file of a artifact
for some reason but it doesn't actually need the JAR file.
However, task "generateMavenCoordinateForDependency" cannot
identify this use case so it added more JARs to the dependency
which are not necessary and are not consistent with what we
get from HttpProxy.java. Going forward, we will use HttpProxy.java
as the single source to provide dependency.
2. Updated update_deps_metadata.py to retrieve *-sources.jar for each
dependency for obvious reason.
3. Improved update_dependency.sh by removing 1 unnecessary build.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=247607871
Make root build.gradle easier to read:
- Moved appengine war-assembly into separate script
- Moved java static analysis configs to separate script,
for easier sharing with buildSrc folder.
Update Gradle config in the buildSrc folder:
- Applied static analysis, and cleaned up a few style and
dependency lint errors.
- Added dependency locks
- Set up Google java format enforcement (Spotless)
since this is new code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=246858172
Also upgraded Guava to 27.1-jre and truth java8 extension to v0.44.
Also removed lockfiles no longer in use in Gradle 5.4.
Follow up change will update bazel dependencies.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=246515393
The pipeline is broken into two. The first one is to be triggered when the public repo is tagged. It then tags the private repo, builds and upload the builder and base images, and push a new commit to the release (merged repo). This pipeline also does text manipulation on several files in the release repo to ensure that the images uploaded in this pipeline is always used to reproducibly build the release repo at the same commit.
The second pipeline is then triggered by commit into the release repo, which builds, signs and uploads the proxy image.
Also updated the dependency lock files to use the latest plugins dependencies, which are uploaded to the GCS repo.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=244666211
The java compiler in the builder with new base image defaults to ASCII encoding.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=242726695
Also modified the deployment pipeline to upload artifacts for crash.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=242032822
Previously we had a few customized Gradle build task to manage
the Docker container for provisioning browser and ChromeDriverService
used by WebDriver tests. This CL changed to use a java library
from testcontainers.org to achieve the same purpose. The main
benefit of it is that we can expect to run the WebDriver tests
from IDE going forward.
Also, this CL refactored the structure of WebDriver related classes
to have JUnit rule to manage the lifecycle of WebDriver instance,
this is also compatible with the API from testcontainers library.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=241539861
Collect the set of dependencies using the gradle proxy and push to GCS using
gcs_sync.
TESTED: Verified that the script works against both unupdated and up-to-date
dependency sets, verified that the proxy server is destroyed after completion.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=241529357
*** Reason for rollback ***
The inconsistent class loading is breaking the tests
*** Original change description ***
Validate provided email addresses when creating a Registrar
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=241014945
In [] a change would have been made to your project that is incompatible with
your open source integration. To make sure the open source variant of your
project remains working, we have eagerly updated your open source copy to use
Mockito 2. This CL integrates that change into [].
Please read []and
understand the consequences of this change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=238445356
Updated the plugin to receive the "protocol"-like tag in the destination, so that you can choose whether to upload to GCS or just save it locally.
Possibly we might expand this in the future, but for now the goal was to allow saving our "internal" builds locally until we find a secure way to store AND BROWSE them remotely.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=238055136
This CL upgraded google/errorprone plug-in to 2.3.3 and resolved
some warnings detected from the plug-in.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=238047862
The main thrust of this is to create a common POJO that contains email content in a simple way, then have one class that converts that to an email and sends it. Any class that uses email should only have to deal with creating that POJO.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237883643
We changed to use Docker to provision Chrome browser and
ChromeDriverService, and the used Kokoro VM comes with
the docker CLI so we can enable the webdriver tests again
in kokoro build.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237874165
This change actually enabled the screenshot comparison in the
visual regression tests. We used Docker to provision Chrome
and ChromeDriver to eliminate the discrepancy of environment
between local development and Travis CI.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237811918
Use javax.servlet:servlet-api:2.5 and exclude all other implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237505707
Mockito in third_party is updated to 1.10. We do not need to backport this rule anymore.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237496086
This is mostly for build reports that use xml or other non-browsable
format. Most notable - the JUnit xml test results.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=236118885
We currently deploy metadata files for vulnerability scanning
to a GoB repo. The Vomit team has requested that we provide
the .pom and .jar files for each dependency in the GoB repo
for their new manifest approach of scanning.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=235029408
This uploads all the report files to GCS, and also creates a cover page that
summarises all the task states.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=234601015
There's no reason not to always create the source mapping but we shouldn't
distribute it in production.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233984970
The correct way to override the plugins repo is through the pluginManagement
section in the gradle settings file. Also make use of the gradle.properties
file to initialize repositoryUrl and also publishUrl so we don't have to mess
around with finding and assigning them in the main gradle file.
The lock files are also updated.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233810854
*** Reason for rollback ***
Breaks the build.
*** Original change description ***
Fix overrides of plugin repository
The correct way to override the plugins repo is through the pluginManagement
section in the gradle settings file. Also make use of the gradle.properties
file to initialize repositoryUrl and also publishUrl so we don't have to mess
around with finding and assigning them in the main gradle file.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233801411
The correct way to override the plugins repo is through the pluginManagement
section in the gradle settings file. Also make use of the gradle.properties
file to initialize repositoryUrl and also publishUrl so we don't have to mess
around with finding and assigning them in the main gradle file.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233778270
This change does a few things:
1. Partially externalized WebDriver tests by using ChromeDriver
as an implementation of WebDriver API in the external build.
2. Refactored WebDriverRule.java to decouple the creation and
using of WebDriver related stuff so we can have different
implementations in internal and external builds.
3. Refactored the usage of some internal libraries to have a
central place to store all of them to make it easier to
remove them in the external build.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233661757
The goal of this CL is to set up the build environment to allow plugins to work.
We have a trivial plugin that doesn't do anything (yet) - it just sets itself as the finalizer of all Reporting tasks.
Eventually, this plugin will upload all reports to GCS, and even create a "cover page" linking to each one of them.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233617499
This makes sure that the WAR files created by running "gradle stage" can be deployed by appcfg (tested the pubapi service on alpha). We need to copy all the static html files regardless of the service because the error.html handler is registered for sandbox and production environments across services. Without those files the gradle app engine plugin refuses to create the WAR files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233608424
It looks like I must have somehow duplicated the absolute path when I copied
these, this puts them in the right place (I think...)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233412326
This CL changes the Cloud Build flows to retrieve dependencies from our self-hosted GCS repository, to ensure that the release build are reproducible and hermetic (Note that it is still not truely reproducible as the dependency publishing process will override any existing artifacts in GCS with the current artifacts in Maven central. This is an issue that we should fix later).
There are a couple of changes involved to get this working:
1. Changed internal repo location to pull from the new repo.
2. Remove jcenter repo. It is only used to pull in the docker gradle plugin, which is not used. We instead build the deploy jar file with Gradle and build the docker image with a Dockerfile. The docker gradle plugin artifacts uploaded to GCS cannot be read because it is using some special classifier which seems to not be preserved when uploading. The java application plugin is also removed because it is only used by the docker gradle plugin.
3. Removed netty tcnative library classifier. It does not appear to be actually used (the jar downloaded from Maven central is an uber jar) and the classifier again interferes with downloading the artifacts from GCS.
4. Removed the cyclic dependency of the util project on itself. It was added because the nebula linter wanted it, which I think is an erroneous warning which should be reported upstream. The cyclic dependency was not a problem before (for yet unknown reasons), but it seems like when we force the dependency resolution (by calling project.generateDependencyPublications during configuration stage) it exacerbated the hidden issue and caused a cyclic task dependency in the util project, which is fatal. Now Nebula will complain again, but the warning is considered benign and will not cause the build to fail.
5. Added the nebula dependency lock files. We need these files when using the GCS maven repo because the we only upload artifacts after conflict resolution to GCS. If both v1 and v2 of the same library are requested in the dependency graph, only one will be uploaded. If we do not have the lock files in place, when building from GCS maven repo, Gradle will try to first find both v1 and v2 in the repo (which fails because v1 is not present in the repo), before proceeding to select v2 to use.
6. Refactored the code to upload Maven artifacts to GCS. We need to manually edit the POM file to reproduce the dependencies for each artifact so that they are all put in the classpath during compilation. Before, the POM files do not have any dependency information, which causes compilation to fail because transitive dependencies are not loaded (even though they are present in the GCS repo).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233408051
This allows us to have the source mapping appear when debugging, just like we have when logging on to alpha, prod, or locally.
Tested on Crash with building from Gradle
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233092769
This CL does a few things:
- Adds the template Soy-to-JS compilation (note: this requires the extra
soyutils_usegoog.js file separately so that the compiled *.soy.js files work
- Adds the Closure Compiler to compile and check our JS
- Adds an NPM task to allow us to download dependencies
- Adds the Closure library as an NPM package
Note: this probably won't compile until we fix the test JS files
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233059414
This makes such tasks work with Gradle's incremental build.
In practice this change is not very useful:
- The Dagger annotation processor version we use is not fully
compatible with Gradle incremental build, and currently causes
unnecessary rebuild in the util package, and forces tests to always run.
Will try the latest version later, which claims to support incremental
build.
- AppEngine deploy task leaves behind non-writable tools.jar files.
Reruns of any builds that include :services:*:explodeWar would fail,
and the easiest work-around right now is to run Gradle clean task.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232929552
