| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Running `git push` when the remote is up-to-date
no-ops (it does not trigger a deployment, but it does not fail either).
Running `clever deploy` when the remote is up-to-date triggers a failure. Here, we care about the _end result_ (ie the app is deployed on the correct commit), so no-oping is more appropriate.
This behaviour is not baked in `clever-tools`, but I think it should. I opened an issue. This script
is a temporary workaround. (at least I hope it's temporary)
https://github.com/CleverCloud/clever-tools/issues/422
|
| |
|
|
|
|
| |
Closes #52
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The env can be provided as a JSON list `[{"name": "PORT", "value": "8080"}]`.
The `dict2items` filter provided by ansible is _almost_ what we want, but it
keeps the value original types (a boolean is kept as a boolean in the JSON value).
Since environment variables are strings and `clever-tools` does not want to make
the implicit coercion for us, we need to do it ourselves.
|
|
|
|
|
| |
See recent changes (https://github.com/CleverCloud/clever-tools/pull/415)
introduced in 2.5.0+ version of the clever cli tools
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19 we removed the polling script to rely on the clever cli's
ability to wait on `clever deploy` command.
After more than 6 months of experimentation it seems the command is
still not reliable (sometimes the command never returns, sometimes it
returns even when the deployment has finished..).
Thus we are reverting back to our manual process of polling `clever
activity` every 5 seconds.
The timeout for this polling is set at the Ansible level (not in the
bash script) and set for 40 minutes. This should give enough time for
any of our applications to deploy.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Updating to latest version of 1.1.1 helps to have a stable `clever
deploy` command.
This commit relies on the output of the command instead of manually
pooling the results with `clever activity` command.
|
| |
|
| |
|
|
|
|
|
| |
This reverts commit 695ceaa28821660e17a1cf819cffebe1b5d8c7ca, reversing
changes made to 5485dbc4db3e141673457475bcda5fc88057739f.
|
|
|
|
|
| |
This reverts commit b17a839d622bdb36ddbe2e0667559c33e9b7fd8a, reversing
changes made to 695ceaa28821660e17a1cf819cffebe1b5d8c7ca.
|
| |
|
|
|
|
|
|
|
|
| |
Updating to latest version of 1.1.1 helps to have a stable `clever
deploy` command.
This commit relies on the output of the command instead of manually
pooling the results with `clever activity` command.
|
|
|
|
|
|
|
| |
Followup after the fix of #15 it was still missing another case of
"git" usage.
This should be the last fix about this variable 🤞.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imagine such a usecase:
- project is in `/project`
- executing Ansible in `/ansible` with `clever_app_root: /project`
will fail deploying with the git push with the following error:
```
Not a git repository (or any of the parent directories): .git"
```
This PR fixes this.
|
|
|
|
|
| |
All variables "namespaced" with the role name is helpful to read
"client" configurations
|
|
|
|
|
|
|
|
| |
Every other variables are prefixed with `clever_` which makes the
definition of variables clearer from a "app" configuration point of
view.
WDYT?
|
|
|
|
|
|
|
|
| |
If your build tool only uses a shallow clone of your project, Clever
cloud will fail on first time git push. You need to git push a full
clone of your git repo for the first time deployment to clever.
This PR fixes that.
|
| |
|
| |
|
|
|