googlecloudplatform / appengine-plugins Goto Github PK

This would eliminate the numerous constructors.

For consumers of this API that can't rely on having to do gcloud auth login there needs to be a way to pass in the auth context.

An initial solution could be to support the --credential-file-override flag and require consumers to do the staging of the credential file themselves.

How should we handle [index.yaml] [cron.yaml] [dispatch.yaml] [datastore-indexes.xml]?

Since App Engine SDK can now be bundled with Cloud SDK, there doesn't seem to be a need for the users to provide a Cloud SDK path and an App Engine SDK path separately. That being the case, should we just merge AppEngineSdk with CloudSdk, and simply move the AppEngineSdk.runCommand() to CloudSdk?

see https://github.com/GoogleCloudPlatform/gradle-appengine-plugin/blob/master/src/main/groovy/com/google/appengine/task/appcfg/AppConfigTaskTemplate.groovy#L73

This way we don't have to update the maven dependency like we are in #29

It gets stripped out anyway by the staging command

We're currently depending on the App Engine SDK to stage standard GAE apps. (i.e., AppCfg.main()).

We should implement staging in the library, cutting the App Engine SDK dependency and also the SdkResolver one (which makes us set a system property with the GAE SDK root folder).

After staging a flexible style project, we need to ensure the artifact is readable by everyone or the user launching it inside the docker wont be able to run it. Deploys fail to verify the vm is running and an 502 is presented when trying to hit the url.

Currently this lib does not support staging and deployment for EAR based projects. The user is shown an error message indicating this, but the message does not provide any workaround suggestions.

If it doesn't make sense to add in this support then perhaps we should expand the error message guiding the user: i.e. deploy the modules individually instead.

Motivation: the IJ legacy App Engine plugin does support ear plugins.

Several of these gcloud preview app modules _ commands have been deprecated and migrated to gcloud preview app services

Package com.google.cloud.tools.app.config contains interfaces for each action's configuration.

Maven and Gradle will have implementations of their own, but the library should provide a default implementation for other clients which don't have any implementation. These implementations should probably use builder syntax.

e.g., DefaultDeleteConfigurationImpl.newDeleteConfiguration(requiredParam1, requiredParam2)
.optionalParam1(p1)
.optionalParam2(p2)

Both for sync or async.

Need to expose ability to kill a process that was started for consumers using a custom ProcessRunner.

This indicates an unpredictable environmental condition, not a program bug. This is exactly what checked exceptions were designed for.

Create standard log to file listener.

Several commands accept this flag and none should run in interactive mode.

CloudSdk class should use the PathResolver to automatically find the Cloud SDK path when one is not provided.

Sources jar is needed for IDEs to provide documentation and debugging support.

This parameter spans multiple commands. While it probably doesn't apply to all commands, I think it should be available to all of them in the same way that format is.

Maven and Gradle do not support automatic parameter binding to Path.

Identified scenarios that require validation:

Deploy normal Maven app with web.xml (guestbook)
Deploy normal Maven app with vm=true in appengine-web.xml (guestbook)
Deploy pure Java8 app without appengine-web.xml (sparkjava)
Deploy JAR and WAR apps, with/without appengine-web.xml
Test on Windows
Test with no authentication in gcloud
Test with no project set in gcloud
Test without gcloud

We could also test these scenarios in bugouts and new releases.

Let users pass in an argsMap for obscure/new/hidden flags in configurations.

See: GoogleCloudPlatform/app-maven-plugin/issues/15

Make sure everything works on windows.

• Gcloud actually runs
• All our pathing is OS agnostic
• Stage Flex sets the correct file permissions

Not only the Dockerfile from src/main/docker should be copied, but all the files and subdir content if any, as these files can serve as context files for the docker image build step.

The current version is outdated.

Use something like a which command to find the gcloud installation.

Followup to: #20

@patflynn let me know what else is there in terms of CI that needs to be taken care of.

...Not just app.yaml

For some clients its useful to be able to control the output format of cammand via the --format flag. For example --format=json so that the output is easily parseable.