allow custom mutations through actions

.circleci/ciignore.sh

@@ -25,11 +25,6 @@ if [[ "$CIRCLE_BRANCH" = "release-"* ]]; then
     exit
 fi
 
-if [[ ! -a "$ROOT/.ciignore" ]]; then
-    echo "Skipping check since .ciignore is not found"
-	  exit # If .ciignore doesn't exists, just quit this script
-fi
-
 # get the diff
 if [[ ! -z "$CIRCLE_COMPARE_URL" ]]; then
     # CIRCLE_COMPARE_URL is not empty, use it to get the diff
@@ -39,36 +34,21 @@ if [[ ! -z "$CIRCLE_COMPARE_URL" ]]; then
         COMMIT_RANGE=$(echo $CIRCLE_COMPARE_URL | sed 's:^.*/compare/::g')
     fi
     echo "Diff: $COMMIT_RANGE"
-    changes="$(git diff $COMMIT_RANGE --name-only)"
+    changes="$(git diff $COMMIT_RANGE --name-only -- . ':!scripts' ':!assets' ':!docs' ':!community' ':!install-manifests' ':!github' ':!*.md' ':!.ciignore' ':!.gitignore' ':!LICENSE')"
 elif [[ "$CIRCLE_BRANCH" == "master" ]]; then
     # CIRCLE_COMPARE_URL is not set, but branch is master, diff with last commit
     echo "Diff: HEAD~1"
-    changes="$(git diff HEAD~1 --name-only)"
+    changes="$(git diff HEAD~1 --name-only -- . ':!scripts' ':!assets' ':!docs' ':!community' ':!install-manifests' ':!github' ':!*.md' ':!.ciignore' ':!.gitignore' ':!LICENSE')"
 else
     # CIRCLE_COMPARE_URL is not set, branch is not master, diff with origin/master
     echo "Diff: origin/master..HEAD"
-    changes="$(git diff-tree --no-commit-id --name-only -r origin/master..HEAD)"
+    changes="$(git diff-tree --no-commit-id --name-only -r origin/master..HEAD -- . ':!scripts' ':!assets' ':!docs' ':!community' ':!install-manifests' ':!github' ':!*.md' ':!.ciignore' ':!.gitignore' ':!LICENSE')"
 fi
 
 echo "Changes in this build:"
 echo $changes
 echo
 
-# Load the patterns we want to skip into an array
-mapfile -t blacklist < "$ROOT/.ciignore"
-
-for i in "${blacklist[@]}"
-do
-	  # Remove the current pattern from the list of changes
-	  changes=( ${changes[@]/$i/} )
-
-	  if [[ ${#changes[@]} -eq 0 ]]; then
-		    # If we've exhausted the list of changes before we've finished going
-		    # through patterns, that's okay, just quit the loop
-		    break
-	  fi
-done
-
 if [[ ${#changes[@]} -gt 0 ]]; then
 	  # If there's still changes left, then we have stuff to build, leave the commit alone.
     echo "Files that are not ignored present in commits, need to build, succeed the job"

docs/graphql/manual/actions/action-handlers.rst

@@ -0,0 +1,36 @@
+Action handlers
+===============
+
+
+.. contents:: Table of contents
+  :backlinks: none
+  :depth: 1
+  :local:
+
+WORK IN PROGRESS
+
+Actions need to be backed by custom business logic. This business logic can be defined in different types of handlers.
+
+
+HTTP handler
+------------
+
+WIP
+
+Postgres functions
+------------------
+
+WIP
+
+Postgres PLV8
+----
+
+Similar to postgres functions but in nodejs.
+
+
+Managing and deploying action handlers
+--------------------------------------
+
+HTTP handlers in serverless functions, micoservice APIs etc 
+
+Postgres functions as migrations, etc

docs/graphql/manual/actions/async-actions.rst

@@ -0,0 +1,35 @@
+Async Actions
+=============
+
+
+.. contents:: Table of contents
+  :backlinks: none
+  :depth: 1
+  :local:
+
+WORK IN PROGRESS
+
+Sometimes you may not want to wait for an action to complete (say if the business logic takes a long time). In such cases you can create an **asynchronous** action, which returns an ``action_id`` immediately to the client before contacting the webhook.
+
+If you mark an action as **asynchronous**, graphql-engine also generates a query and a subscription field for the action so that you can query/subscribe to its status. In the above example, let's say ``place_order`` is an asnychronous action, your client code looks something like this:
+
+.. code-block:: graphql
+
+   mutation place_order($order_input: place_order_input!) {
+     place_order(input: $order_input) {
+       action_id
+     }
+   }
+
+.. code-block:: graphql
+
+   subscription order_status($action_id: uuid!) {
+     place_order(action_id: $action_id) {
+       order {
+         id
+         payment_url
+         total_amount
+         discount
+       }
+     }
+   }

docs/graphql/manual/actions/getting-started.rst

@@ -0,0 +1,69 @@
+Getting Started with Actions
+============================
+
+
+.. contents:: Table of contents
+  :backlinks: none
+  :depth: 1
+  :local:
+
+WORK IN PROGRESS
+
+Let's say you are building an ecommerce application where you need to provide a mutation for placing an 'order', ``place_order``.
+
+Example
+-------
+
+WORK IN PROGRESS
+
+First, you will need to first define the input types for this mutation in the console:
+
+.. code-block:: graphql
+
+   enum payment_method {
+     stripe
+     paypal
+   }
+
+   input type place_order_input {
+     selected_payment_mode payment_method!
+     items [order_item_input!]!
+     address_id uuid!
+     coupon_code String
+   }
+
+   input order_item_input {
+     skuId uuid!
+     quantity Int!
+   }
+
+   type place_order_response {
+     order_id uuid!
+   }
+
+You will then define an action called ``place_order`` with ``place_order_input`` as the **input** type, ``place_order_response`` as the **output** type.
+
+Once you have the action setup, you'll have to define the permissions for the role for which you want to allow this action. For all such roles, this action will be exposed as a mutation. The client can then execute this mutation as follows:
+
+.. code-block:: graphql
+
+   mutation place_order($order_input: place_order_input!) {
+     place_order(input: $order_input) {
+       response {
+         order_id
+       }
+     }
+   }
+
+
+But how is this action executed? An action can be linked to different types of handlers (see: :doc:`Action handlers <action-handlers>`) . In this example, let's use a HTTP handler which will be invoked when this action is called by the client. The logic of this handler could look something like this:
+
+.. code-block:: python
+
+   def place_order(payload):
+       input_args = payload['input']
+       session_variables = payload['session_variables']
+       order_id = validate_and_insert_order(input_args, session_variables) # some business logic code
+       return {"order_id": order_id}
+
+And that's it. You have created your first action!

docs/graphql/manual/actions/index.rst

@@ -0,0 +1,40 @@
+Actions
+=======
+
+.. contents:: Table of contents
+  :backlinks: none
+  :depth: 1
+  :local:
+
+
+WORK IN PROGRESS
+
+Actions are user defined mutations with custom business logic. Actions can be added to Hasura to handle various use cases such as data validation, data enrichment and other complex business logic.
+
+When the permissions system isn't enough to specify the required constraints, you would typically add such mutation through a remote schema. However actions can handle these use cases better because of the following reasons:
+
+1. No need to write a remote schema. Actions can be executed in ordinary webhooks or postgres itself.
+
+2. Return graphql-engine's types without writing any extra code. You might want to return the new "state" after a mutation.
+
+3. Can be executed asynchronously for building powerful event-driven apps.
+
+Architecture Diagram
+--------------------
+
+WORK IN PROGRESS
+
+
+Learn more
+----------
+
+.. toctree::
+  :maxdepth: 1
+  :titlesonly:
+
+  Getting started <getting-started>
+  Input types <input-types>
+  Response types <response-types>
+  Action handlers <action-handlers>
+  Async actions <async-actions>
+  Sample use cases <use-cases>

docs/graphql/manual/actions/input-types.rst

@@ -0,0 +1,45 @@
+Action Input Types
+==================
+
+.. contents:: Table of contents
+  :backlinks: none
+  :depth: 1
+  :local:
+
+WORK IN PROGRESS
+
+Reference for creating different input types.
+
+
+Scalar Input Types
+------------------
+
+WORK IN PROGRESS
+
+.. code-block:: graphql
+
+   enum payment_method {
+     stripe
+     paytm
+   }
+
+
+Object Input Types
+------------------
+
+WORK IN PROGRESS
+
+.. code-block:: graphql
+
+   input type place_order_input {
+     selected_payment_mode payment_method!
+     items [order_item_input!]!
+     address_id uuid!
+     coupon_code String
+   }
+
+   input order_item_input {
+     skuId uuid!
+     quantity Int!
+   }
+

docs/graphql/manual/actions/response-types.rst

@@ -0,0 +1,67 @@
+Action Response Types
+=====================
+
+
+.. contents:: Table of contents
+  :backlinks: none
+  :depth: 1
+  :local:
+
+
+WORK IN PROGRESS
+
+You can return different types of responses when an action is executed.
+
+Basic Response
+--------------
+
+WORK IN PROGRESS
+
+.. code-block:: graphql
+
+
+   mutation place_order($order_input: place_order_input!) {
+     place_order(input: $order_input) {
+       response {
+         order_id
+       }
+     }
+   }
+
+Complex response with relationships
+-----------------------------------
+
+WORK IN PROGRESS
+
+.. code-block:: graphql
+
+   mutation place_order($order_input: place_order_input!) {
+     place_order(input: $order_input) {
+       response {
+         order {
+           id
+           payment_url
+           total_amount
+           discount
+         }
+       }
+     }
+   }
+
+You can fetch relationships of the ``order`` like you would when you query the ``order`` table. Thus with actions you can write the minimum needed code that is needed to validate the mutation and still not lose out on the powerful query fields that graphql-engine generates.
+
+Async response
+--------------
+
+WORK IN PROGRESS
+
+.. code-block:: graphql
+
+   mutation place_order($order_input: place_order_input!) {
+     place_order(input: $order_input) {
+       action_id
+     }
+   }
+
+Where ``action_id`` is a unique id generated for every async action that has been performed.
+