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
I should have caught this in the review, but [] is loading *ALL*
contacts individually from Datastore on every domain update. This will add a
large number of Datastore round trips and thus significantly reduce update
performance.
This CL changes the behavior to *ONLY* load contacts when there is a duplicate
(which is needed to determine the contact's display name to generate the error
message), and loads all of them in a single batch rather than individually.
This also makes some minor changes around domain getters returning empty sets
instead of null.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=233128140
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 change also added a test to verify that EPP request to modify
both contacts and registrant at same time can be handled as expected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232935690
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
This is to remind the user that the function actually uses cache, and also
for naming consistency with EppResourceUtils.loadByForeignKeyCached().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232870846
We figure out the TLD state so that we properly check whether or not we can provision sunrise domains in that TLD. We also change the message slightly so that it's a bit more clear when we aren't in sunrise.
Note: it is deliberate that NAME_COLLISION reservations are provisionable in sunrise.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232742813
The publish and generateDependencyMetadata tasks need to run
on root project as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232742630
The redacted text for the email field displays a longer prompt to
contact the registrar, per the request filed at b/123573370.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232716133
We want to make it clear what query (or POST) inputs the user needs to / can give for each Action. That means moving all the @Injects of these parameters to the Actions themselves instead of injecting them in "hidden" indirect dependencies.
This has the extra benefit of allowing these indirect dependencies to work for JSON Actions as well, since the "regular" way we @Inject parameters can corrupt the POST JSON data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232540758
Similar to [] these are issues found by Google Java Format. Most of the output is just using the standard [] formatter, then fixing any line-length issues.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232488284
These files will have errors later when we run the Google Java Format plugin over their entirety (e.g. a situation where fixed indentation leads to a line that's longer than 100 characters). It's simpler to fix them now so we won't have to fix them later.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232353791
Remove Nebula plugin and enable Gradle locking.
Update publishing task to include build dependencies in resolved artifacts
list.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232349134
These files are unused by the tests in this directory, have no obvious purpose
and have no README explaining their existence.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232014732
This should have gone in with the implementation of BaseDnsWriter.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=232009971
Right now it's logging the raw bytes, which look like:
response data: [65, 117, 116, 104, 111, 114, 105, 122, 97, 116, 105, 111, 110, 32, 114, 101, 113, 117, 105, 114, 101, 100]
We'd rather convert it to ASCII characters (what the NORDN service uses) before
logging it, so that it'd instead look like:
response data: Authorization required
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231998658
The daily template is the only one that needs it but we can always pass it in without issue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231295089
This should have been deleted in [] when the underlying entity was
deleted, but it was missed. It's been a no-op since then. This is just cleanup.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231293033
We make some modifications to the internal Google checkstyle file because Google's linter uses a modified build of Checkstyle that introduces some new classes and allows for more specific checks than the open-source Checkstyle (e.g. only enforcing UPPER_SNAKE_CASE on deeply immutable fields). There exists a public Checkstyle file that purports to be the Google java format file (https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml) but it doesn't quite match up with what the internal linter says in certain situations (e.g. what operators must/can appear on new lines).
The suppressions are basically "don't run on generated code + don't care about Javadoc in test code"
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231283700
This code was never finished or fully working anyway. It would require
substantial reworking for the Registry 3.0 migration because it's closely tied
to the Datastore model and App Engine MapReduce framework, both of which will be
going away. We can bring back some of these deleted test files as necessary
if/when we rewrite RDE import for the new schema.
On the plus side, in a relational database, RDE import will be much simpler.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231265578
They are passed around in the format username:password, whereas just saying
"login" implies it's just a username and not necessarily also a secret
password. Putting password in the variable name makes it obvious what this is
and reduces the likelihood of anyone ever logging it or otherwise using it
inappropriately.
Note that this does not require data migrations as the actual key used to store
the data in KMS remains unchanged.
This is a follow-up to []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231253964
This will help us to debug the current MarksDB issue. This also throws an explicit error earlier when attempting to connect to MarksDB without login credentials being specified, which we know will fail.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231236317
AppEngineRule throws an exception during teardown if
an empty datastore-indexes-auto.xml is created during
testing. This scenario should be fine, just like if this file
has not been created at all.
This issue causes some flakiness in tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231229692
We now display the results of each check in addition to the overall result.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231051913
The most common issues were:
* Arrays.asList() shouldn't be called with a single parameter.
* Broken Javadoc @links.
* Unnecessary casts and type declarations.
* Unnecessary unused variable initializations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230994311
Most common:
- Unnecessary parentheses and operator precedence clarify (self-explanatory)
- Reference equality--there were a few instances of using == or != improperly
- Qualification of Builder (and similar) imports so that it's clear which type of Builder we're referring to
- Marking some immutable classes with @Immutable since EP desires that all enums be deeply immutable
- String.split() having "surprising behavior"
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230971531
This view used to point to the latest datastore backup
using the deprecated export mechanism, which has been
disabled. We will point this view to the new backups.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230930872
This eliminates the use of Objectify polymorphism for EPP resources entirely
(yay!), which makes the Registry 3.0 database migration easier.
It is unfortunate that the naming parallelism of EppResources is lost between
ContactResource, HostResource, and DomainResource, but the actual type as far as
Datastore was concerned was DomainBase all along, and it would be a much more
substantial data migration to allow us to continue using the class name
DomainResource now that we're no longer using Objectify polymorphism. This
simply isn't worth it.
This also removes the polymorphic Datastore indexes (which will no longer
function as of this change). The non-polymorphic replacement indexes were added
in []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230930546
This is currently erroring out on entities that fail to load properly through Objectify (e.g. because their entity type is no longer registered). The proper thing to do is to catch the error, log it, and fall back to the raw Datastore operation, which will succeed.
The exact Exception this is designed to catch is:
com.google.apphosting.runtime.jetty9.JettyLogger warn: /_dr/admin/deleteEntity (JettyLogger.java:29)
java.lang.IllegalStateException: No registered subclass for discriminator 'DomainApplication'
at com.googlecode.objectify.v4.impl.PolymorphicEntityMetadata.getConcrete(PolymorphicEntityMetadata.java:133)
at com.googlecode.objectify.v4.impl.PolymorphicEntityMetadata.load(PolymorphicEntityMetadata.java:164)
at com.googlecode.objectify.v4.impl.LoadEngine.load(LoadEngine.java:220)
at com.googlecode.objectify.v4.impl.LoadEngine$1.nowUncached(LoadEngine.java:178)
at com.googlecode.objectify.v4.impl.LoadEngine$1.nowUncached(LoadEngine.java:164)
at com.googlecode.objectify.v4.util.ResultCache.now(ResultCache.java:30)
at com.googlecode.objectify.v4.impl.Round$1.nowUncached(Round.java:73)
at com.googlecode.objectify.v4.util.ResultCache.now(ResultCache.java:30)
at com.googlecode.objectify.v4.LoadResult.now(LoadResult.java:25)
at google.registry.tools.server.DeleteEntityAction.loadOfyEntity(DeleteEntityAction.java:103)
at google.registry.tools.server.DeleteEntityAction.run(DeleteEntityAction.java:74)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230737553
Having py_binary in deps is deprecated and will break in 19Q1.
[] for more details.
If this CL broke you, please fix forward by manually running
[]/devtools/python/janitor:lib_split_binary []
Tested:
TAP --sample for global presubmit queue
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230359276
