renehernandez / appfile Goto Github PK

Would allow to validate the final app.yaml spec against a known set of rules. Specially useful to run as part of the CI/CD pipeline to avoid triggering a deployment with an invalid configuration

Command:

appfile -e <env_name> -f </path/to/appfile> lint

NOTE: To implement this, I have to wait for digitalocean/godo#422

New fields to cover:

• catchall_document or error_document only one can be present
• routes
• cors

To ease new users of appfile, it would be interesting to support reading directly from the app.yaml spec file. From an execution viewpoint, this would be similar to an appfile.yaml declaring just one spec and no environments.

It needs to validate the following fields:

• domain
• type

It needs to validate the following fields:

• key
• scope
• type

New command to be able to see logs from the deployed applications. Example invocations:

appfile logs <app_name> -e <env> -f </path/to/appfile.yaml 

appfile logs <app_name> --component <component name> -e <env> -f </path/to/appfile.yaml>

Flags:

• Support for -t/--tail option to follow the logs live
• Support selecting the type of logs to show (build, deploy, run). Should default to run

This command would allow to revert the application to a previous deployment id. The command would support two modes.

Rollback to the previous deployment:

appfile -f /path/to/appfile -e <env> rollback <app_name>

Rollback to a specific previous deployment id:

appfile -f /path/to/appfile -e <env> rollback <app_name> <deployment id>

If there is a domain defined in in the app.yaml spec linked to a DigitalOcean DNS-managed zone, it automatically adds a CNAME on app creation, but doesn't remove it when the App is destroyed.

Appfile should check during the destroy operation if there is a domain specified and delete it using the godo sdk

New fields to process:

• health_check (valid integers)
• cors
• routes
• routes cannot be set if internal_ports are set

Using the name portfolio-snippet-alpine-python-image, it will be trimmed to portfolio-snippet-alpine-python-, which is incompatible with the regex pattern used by the DigitalOcean API

This would be a great extension to the current appfile capabilities. It would be nice if it could behave similar to what helm does with repos and pulling charts from remote.

Stable repo

Ideally, there would be a stable repo, that could host community-maintained app specifications. In addition, the implementation could support (at least having this in mind for the first iteration) adding custom repos, so that orgs could have their own private repos.

Note: Appfile would ship with the stable repo by default

Implementation

The appfile specification would need to be modified to support the new releases block instead of the old specs block

appfile spec overview

environments:
  review:
    - ..
  production:
    - ..

releases:
  - name: my-ghost # could be optional
    spec: stable/ghost
    values:
      - values.yaml
  ...

Repo commands

appfile repo add <http_url>

appfile repo list

appfile repo delete

appfile repo update

Limitations

• Spec published in the stable repo need to use a container image with public access. Of course the image field itself could be overwritten to point towards any internal/private container registry

For CI systems it would be useful to have the option of appfile not retuning until the application has been fully built and deployed, with a non-zero exit code if something goes wrong.

Digital Ocean has added a similar --wait flag to doctl.

Instead of having to specify the environments variables as part of the CLI invocation or export them in the session, it would be convenient to load them from .env file. This improves the user experience when manually running appfile

New option to add to the root appfile command:

--env-file: Pointing to the path of the env file to load

If the app specification declares any domains:

# app.yaml
domains:
- domain: example.com
   ...

then the execution of appfile sync -f /path/to/appfile should output a log message showing the URL where the app will be accessible.

This is specially useful when the domains are dynamically generated based on the environment used by appfile

Fields that need to be added:

• kind

The list command should allow to list all the defined apps in a given appfile.yaml specification.
List all apps in an appfile:

appfile -f /path/to/appfile.yaml -e <env> list

Currently, the redirect is hardcoded to latest version at the moment (v0.0.5). This should be updated as part of the release process to point to the newer version

As the number of features start to increase, and complexity as well, it is important to verify that behavior at the system level is not affected.

E2E tests should cover execution of commands against known outputs

The current list command implies that is about listing different app specification, when what it can be done is provide status about the current deployment.

So, the list command should be replaced with a new status command which should cover the following:

global information

• name
• updated
• status
• deployment id
• default url

• Produce release artifacts for the supported os/arch
• Generate github release

It needs to validate the following fields:

• name
• engine