diff options
author | ETL <etlweather@keylimebox.org> | 2016-03-12 16:53:26 -0500 |
---|---|---|
committer | ETL <etlweather@keylimebox.org> | 2016-03-12 16:53:26 -0500 |
commit | 71f22c557eece1a0e991c29c54b8d00b5cee6673 (patch) | |
tree | 5c8d23c286c7401f89a14dd91e83d6043ce2bdf0 /docs | |
parent | 997e40d045ee710b74a9b35afaa5dc26b7c66bc0 (diff) | |
download | Git-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.md | 52 |
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 |