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
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
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
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
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
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
Identified a few more tests that are impacted by test cleanup
issues outside of Nomulus code base, more likely thread pool
cleanup behaviors in AppEngine testing fixture.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229934266
This console is only to be used by Admins (either GAE admins for this project, or Support accounts). It is for "internal" use only, not for use by the registrars themselves.
To prevent abuse, the registrar is created in a non-functional PENDING state and can only be made functional from the nomulus shell tool.
While in "PENDING" state, the registrar can be updated from the registrar-console by admins.
Also - moving all the web consoles to the same directory (moving the otesetup/* files into registrar/)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229681011
*** Reason for rollback ***
Found more tests failing.
*** Original change description ***
Reenable Test Executor sharing in Gradle build
Combining all tests in one suite and drop the forkEvery=1 directive.
Issue was fixed by [] and []
TESTED=Run locally with maxParallelForks =1 and 5, and tested on travis
with maxParallelForks=5
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229430425
Combining all tests in one suite and drop the forkEvery=1 directive.
Issue was fixed by [] and []
TESTED=Run locally with maxParallelForks =1 and 5, and tested on travis
with maxParallelForks=5
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229414759
For each registrar, the daily email will only include threats that did not appear
in the prior run's email.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228889972
This backs out most of [] fixes the external build (which wasn't
finding Apache Commons correctly), and makes miscellaneous tweaks and fixes,
including better handling representing the default case of decrypting to stdout.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228877090
This also deletes the associated commands and domain application specific
entities.
We haven't used any of these TLD phases since early 2015 and have no
intent to do so in the future, so it makes sense to delete them now so we
don't have to carry them through the Registry 3.0 migration.
Note that, while there are data model changes, there should be no required
data migrations. The fields and entities being removed will simply remain
as orphans. I confirmed that the removed types (such as the SUNRUSH_ADD
GracePeriodType) are no longer used in production data, and left types
that are still used, e.g. BillingEvent.Flag.LANDRUSH or
HistoryEntry.Type.ALLOCATE.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228752843
Since we seem to be experiencing weird interference between tests on Travis,
run every test in its own JVM until we find a better solution.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228738848
Files.copy() attempts to delete the file if it already exists, which obviously
won't work very well for /dev/stdout. Instead copy directly from the decoder
to standard output.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228384575
There were two issues in the Gradle build.
1. Missing soyToJava conversion for newly added
google.registry.ui.soy.otesetup.
2. testSuccess_setAllowedTldsUncached_newTldNotInCache in
RegistrarTest modified the cache duration to 600 seconds
which broke other tests as those tests write to the storage
in initiation stage and expect the data to be available in
the cache immediately, this requires the duration to be
0.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228377715
Recent changes cause a bunch of new tests to have runtime conflicts.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=226499557
If the user runs "nomulus -e [ENV] login --remote", an URL will be provided, the user then can visit the URL on any machine (not necessary where the command is run) and copy&paste back the authorization code to complete authorization.
This makes it easy to login on machines where local browsers are not easily accessible.
Also upgraded nebula lint version to 10.3.5.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=225198700
It'd be nice if we can separate out the tool to its own package and reduce the transitive dependencies that it pulls in. However since the entire core project is a dependency of the tool, it doesn't make any difference as we'd be pulling in core and all its transitive dependencies as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=224821931
We are moving away from using Application Default Credentials generated by "gcloud auth application-default login" in our code base and consolidate on using self-managed credentials provided from AuthModule.
One of the remaining dependencies on the ADCs is from beam pipeline deployment commands, which by default use the ADCs to talk to GCS and upload the jar files and templates. In this CL, we explicitly provide the locally created credential to the Options used in deployments.
Also moved all credential qualifiers to CredentialModule, and removed @AppEngineAdminApiCredential, which is no longer used.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=224199812
RemoteApiOption has a package-private method that takes a Stream representing the content of a JSON and use a GoogleCredential created from it as its credential. This CL uses reflection to change the access modifier of that method in order to supply a credential stream that is self-managed. This is obviously not ideal and prone to breakage in case the getGoogleCredentialStream method is changed. Unfortunately upstream is not willing to make it public citing the reason that GoogleCredential.fromStream() (which getGoogleCredentialStream uses) is a @Beta annotated function (see https://groups.google.com[]forum/#!searchin/domain-registry-eng/remoteapioptions%7Csort:date/domain-registry-eng/Flsah6skszQ/CySZv2XEBwAJ). However this function is introduced 5 years ago as a public function (b857184bfa). I think at this point it is safe to assume that it is part of the widely used APIs and will not change without sufficient notice.
Note here that RemoteApiOptions creates its own copy of GoogleCredential to be used to call App Engine APIs locally, whereas communications to Nomulus endpoints use the Credential provided in AuthModule. Even though both credentials are created from the same client id, client secret and refresh token (the three elements needed to construct a GoogleCredential this way, see https://github.com/googleapis/google-api-java-client/blob/master/google-api-client/src/main/java/com/google/api/client/googleapis/auth/oauth2/GoogleCredential.java#L842), their refreshes cycles are independent of each other. I verified that refreshing one of the credential does not invalidate the access token of the other credential, as long as it is not expired yet.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=224156131
This commit introduced a new flag to enable SetNumInstancesCommand to
be able to set the number of instances for all non-live versions for
a given service or for all deployed services.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222826003
This CL adds two ways to build an docker image with gradle:
1) Adds a :proxy:deployJar task that builds an uber jar that contains all runtime dependencies. The jar can then be add to a docker image by calling docker with the added Dockerfile. The base image for this image can be both distroless java or openjdk:alpine.
2) Uses the Gradle distribution plugin to build a distribution tar file that contains all dependencies (as separate jar files) and a run script that sets up the classpath before calling the main class. Then the docker application plugin can build a docker image (with the dockerBuildImage task) using the application tar file. This only works with openjdk:alpline base image as the distroless java image does not contain a shell and therefore the script created by the distribution plugin cannot be launched.
We may later decide to use one of the method and remove the other.
Also adds an outcast test pattern that caused the tests to be flaky.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222145192
It will make it easier later to have the proxy project depend on it, rather
than on the entire core project
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222081994
1. Updated nebula lint version to 10.3.1
2. Do not apply plugins in the root projects that are not needed.
3. Only do linting when a build is successful, so that build failure message are not flushed by linter warnings.
4. Added explicitly stated java source and target version.
5. Moved source sets set up to the root project so that it applies to all subprojects. Currently there is only "core", but we will add at least "proxy" and "util" later, both of which will use mostly the same source sets (but with additional inclusion rules to only build classes in a specific sub folder in the source tree). By putting the set up closure inside the subprojects block in the root script, it can be reused.
6. Rename maybe_runtime configuration to maybeRuntime, which is consistent with other camelCase configuration names like testCompile.
7. Added a runtime dependency of the JAXB API which is removed from Java SE as of version 11.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222081092
These source sets are not configured correctly (no classpaths for example) and
they subsequently cannot compile. The special tests are put into separate tasks that
run from the same source set (test).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222080273
