summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorETL <etlweather@keylimebox.org>2016-03-12 16:53:26 -0500
committerETL <etlweather@keylimebox.org>2016-03-12 16:53:26 -0500
commit71f22c557eece1a0e991c29c54b8d00b5cee6673 (patch)
tree5c8d23c286c7401f89a14dd91e83d6043ce2bdf0 /docs
parent997e40d045ee710b74a9b35afaa5dc26b7c66bc0 (diff)
downloadGit-Auto-Deploy-71f22c557eece1a0e991c29c54b8d00b5cee6673.zip
Git-Auto-Deploy-71f22c557eece1a0e991c29c54b8d00b5cee6673.tar.gz
Git-Auto-Deploy-71f22c557eece1a0e991c29c54b8d00b5cee6673.tar.bz2
Changes to a more versatile filter mechanism.
I found myself needing to filter the build events using the build status (GitLab sends web hook events on build status changes so you get "running" events which aren't very useful in deploy context). Instead of building a whole lot of variable, parsing all possible options I or others may want in the future, I coded the changes so that any element from the web hook data is simply available for filtering. I put in some code so that the earlier functionality works too - specifically the action filter option which isn't an attribute in GitLab's web hook data.
Diffstat (limited to 'docs')
-rw-r--r--docs/Configuration.md52
1 files changed, 45 insertions, 7 deletions
diff --git a/docs/Configuration.md b/docs/Configuration.md
index c1be297..b911048 100644
--- a/docs/Configuration.md
+++ b/docs/Configuration.md
@@ -32,14 +32,25 @@ Repository configurations are comprised of the following elements:
With filter, it is possible to trigger the deploy only if the criteria are met.
For example, deploy on `push` to the `master` branch only, ignore other branches.
-Filters are defined by providing an `action` and/or a `ref` element (most the
-time both would be used in the filter )
+Filters are defined by providing keys/values to be looked up in the original
+data sent by the web hook.
-A special filter syntax also exist to take care of GitHub pull-requests. See
-[Continuous Delivery via Pull requests](./Continuous Delivery via Pull requests.md)
-for details on how it works.
+For example, GitLab web hook data looks like this:
+
+```json
+ {
+ "object_kind":"build",
+ "ref":"master",
+ "tag":false,
+ ...
+ }
+```
+
+A filter can use `object_kind` and `ref` attributes for example to execute the
+deploy action only on a `build` event on the `master` branch.
# Examples
+*(Note: the filter examples below are valid for GitLab)*
Execute pre-deploy script, don't `pull` the repository but execute a deploy
script, and finish with a post-deploy script. Execute only for `push` events on
@@ -60,7 +71,7 @@ the `master` branch.
"deploy": "echo deploying",
"filters": [
{
- "action": "push",
+ "object_kind": "push",
"ref": "refs/heads/master"
}
]
@@ -84,11 +95,38 @@ Clone repository on `push` to `master`.
"path": "~/repositories/hooktest",
"filters": [
{
- "action": "push",
+ "object_kind": "push",
"ref": "refs/heads/master"
}
]
}
]
}
+```
+
+Execute script upon GitLab CI successful build of `master` branch.
+
+```json
+{
+ "pidfilepath": "~/.gitautodeploy.pid",
+ "host": "0.0.0.0",
+ "port": 8080,
+ "global_deploy": [
+ "echo Pre-deploy script",
+ "echo Post-deploy script"
+ ],
+ "repositories": [
+ {
+ "url": "http://gitlab/playground/hooktest.git",
+ "deploy": "echo deploying project!",
+ "filters": [
+ {
+ "object_kind": "build",
+ "ref": "master",
+ "build_status": "success"
+ }
+ ]
+ }
+ ]
+}
``` \ No newline at end of file