WIP - example cloudControl deploy hooks configuration

.ccconfig.yml

BaseConfig:
  WebContent: /web
  AdminEmail: [email protected]

PHPConfig:
  apcEnabled: 1
  xdebugProfilerEnable: 0
  xdebugDefaultEnable: 0

# How these deployment hooks work:
# 1. $ cctrl app/deployment deploy
# 2. The hooks listed under "pre" are pre-deployment hooks.
# 3. The internal deployment on cloudControl itself.
# 4.1 The hooks listed under "post" are post-deployment hooks on successful deployment.
# 4.2 The hooks listed under "onerror" are post-deployment hooks if the deployment failed.
# 5. Deployment completed.
Deploy:
  pre:
    # Lock worker.add commands other than defined in the "Deploy" section.
    - { type: "cctrl", command: "worker.lock" }
    # Issue worker.remove on each worker after waiting for 15 seconds and forcing (SIGKILL) after additional 20 seconds.
    - { type: "cctrl", command: "worker.kill", options: { wait: 15, force: 20 } }

  post:
    # Use worker.add API to add specific worker
    # Those are allowed even while workers are locked.
    # Each entry will only be executed after the previous has been successfully executed.

    # The following example shows two parallel workers.
    # In case the number of entries exceeds the maximum amount of workers on this deployment, they will be executed in batches sequentially.
    - [
      { type: "worker", command: "app/console", parameters: "app:disable" },
      { type: "worker", command: "app/console", parameters: "propel:migrate" }
    ]
    # This one will only be executed after both of the above workers have finished and exited with the zero error code.
    - { type: "worker", command: "app/console", parameters: "app:enable" }

    # Allow worker.add from "outside"
    - { type: "cctrl", command: "worker.unlock" }
    # Start a worker right away.
    # If the worker's return code is "1" (restart), retry 3 times, on 4th time: erroneous deployment.
    - { type: "worker", command: "app/console", parameters: "cctrl:cron", options: { retry: 3 } }

  # These hooks are called whenever the deployment fails.
  # A deployment failed if at least one of the following conditions apply.
  # a) The third step (internal deployment) failed for whatever reason.
  # b) Any of the "pre" or "post" hooks returned an error state.
  #    An application worker returned "2" error code.
  #    An application worker returned "1" restart code more than allowed "retries". (see example above)
  onerror:
    # Notify the admin via email, as defined in BaseConfig.AdminEmail of this configuration file.
    - { type: "cctrl", command: "notify.admin" }
    # Start this worker, even while workers are locked.
    - { type: "worker", command: "app/console", parameters: "app:disable" }
    # Rollback the deployment to its previous version.
    - { type: "cctrl", command: "deploy.rollback" }

  # This section contains additional commands to be issued on a rollback initiated by the "deploy.rollback" task.
  # The environment of e.g. workers in this situation will contain two additional entries:
  # a) "DEP_VERSION_ROLLBACK" The version to which will the rollback is initiated (e.g. the previously deployed sha-hash for a git repository).
  # b) "DEP_VERSION_FAIL" The version that has failed to be deployed with this attempt.
  rollback:
    # These commands will be issued on the failed deployment.
    # Use those wisely as the deployment may be corrupt!
    pre:
      - { type: "worker", command: "app/console", parameters: "app:disable" }
      - { type: "worker", command: "app/console", parameters: "propel:migrate:rollback" }
    # Those commands will be issued on the previous version, the rollback has been finished.
    post:
      - { type: "worker", command: "app/console", parameters: "app:disable" }
      - { type: "worker", command: "app/console", parameters: "cache:warmup" }
      - { type: "worker", command: "app/console", parameters: "app:integrity-check" }
      - { type: "worker", command: "app/console", parameters: "app:enable" }
    # In case even the rollback fails, which should actually never happen, but in scenarios where a migration step partly worked and the rollback cannot revert certain parts .. failed rollback!
    onerror:
      - { type: "cctrl", command: "notify.admin" }

@havvg I have started a bundle which will at the very least have a command to run propel migrations through the CLI using credentials from a config file.
Secondly I thought of implementing this:
https://github.com/cloudControl/cctrl_tutorial_app/blob/master/_config.php

but why would amazon change the db credentials? sites would go down??

It's about generic credentials. They may change, e.g. if you revoke your API access by replacing it with a newly generated. But you won't be required to change your application, as it reads the credentials from the CRED_FILE which is filled automatically with the correct values by the add-on provider.

Furthermore you can use those credentials in third-party libraries without having the user think of setting up the authentication. For an example, see https://github.com/havvg/php-cctrl/blob/feature/rewrite/src/Cloudcontrol/Runtime/Runtime.php#L76 ff. and https://github.com/havvg/php-cctrl/blob/feature/rewrite/tests/Cloudcontrol/Tests/Runtime/RuntimeTest.php#L58 ff.

Hmm, there is an API, I saw in your code.

Did i miss that on their site?

Changes things a bit....thanks for pointing me in the right direction

There is the API documentation: https://api.cloudcontrol.com/doc/