Update docs

docs/configuration/basic_usage.md

@@ -180,18 +180,7 @@ Version calculation rules:
 
 ### GitHub workflow context
 
-If `release` task is executed in GitHub workflow it will generate an output variable `released-version`
-that you can access later on in your workflow steps.
-
-```
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - id: release
-        run: ./gradlew release
-      - run: echo ${{steps.release.outputs.released-version}}
-```
+See [GitHub outputs](ci_servers.md#github-outputs)
 
 ## Accessing previous version
 

docs/configuration/ci_servers.md

@@ -29,10 +29,38 @@ This behavior is experimental and has been tested on the following CI servers:
 
 `axion-release` has dedicated support for GitHub Actions and you don't need any custom configs to make it working.
 
-Here's what Axion does for you under the hood:
+### GitHub outputs
 
-- gets the original branch name for workflows triggered by `pull_request` -
-  see [versionWithBranch](version.md#versionwithbranch-default)
+To make it easier for you to chain jobs in a workflow, `axion-release` will provide some information as GitHub outputs.
+
+| name                | description                                 |
+|---------------------|---------------------------------------------|
+| `released-version`  | Provided after executing the `release` task |
+| `published-version` | Provided after executing the `publish` task |
+
+#### Multi-module builds
+
+If all your subprojects use the same version, the output will be a single value, such as:
+```
+1.0.0
+```
+
+However, if each subproject has its own version, the output will be in JSON format, for example:
+```json
+{"root-project":"1.0.0","sub-project":"2.0.0"}
+```
+
+#### Example
+
+```
+jobs:
+  build:
+    steps:
+      - id: release
+        run: ./gradlew release
+
+      - run: echo ${{ steps.release.outputs.released-version }}
+```
 
 ## Jenkins