Spinnaker currently cannot have inter-dependencies between different pipelines.
As a result we put the WAR files for all environments in one tarball which
triggers a single pipeline that first deploys to sandbox and then to
production.
Temporarily disabled pulling dependencies from GCS while that is being worked
out.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=239448777
Our Gradle build now requires three programs to build: Java, npm and gcloud. There are no existing images that contain all of them. Even if there were, they probably come from some random Joe on the Internet and we cannot trust the image to be free of malwares. Therefore we need to build our own builder.
The builder images will be built by Cloud Build and upload to our container registry. We should periodically rebuild it to pull in the latest security updates both for the base Ubuntu image, and for the components that we install. I have not figured out a way to do that yet. For now we'll just trigger Cloud Build manually once in a while.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=234009343
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
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
The artifacts for each service will be packaged inside a tar file that, when untared, is ready for Spinnaker to deploy to GAE.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=226516223
The private repo structure is re-done to mirror that of the public repo to facilitate easy merging.
Also removed steps to tag the private repos. This will likely cause a race condition if both the nomulus and the proxy cloud build are triggered by the same tag. They will both try to tag the private repo with the same tag.
The tagging of the private repo should happen simultaneously with the public repo tagging, and in an out-of-band process as far as the build process is concerned. The build process should not have side effect on its source.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=225544063
