docs: consolidate expression links (#12617)

Signed-off-by: Anton Gilgur <agilgur5@gmail.com>

docs/argo-server-sso.md

@@ -83,7 +83,7 @@ metadata:
     # Must evaluate to a boolean.
     # If you want an account to be the default to use, this rule can be "true".
     # Details of the expression language are available in
-    # https://github.com/expr-lang/expr/blob/master/docs/language-definition.md.
+    # https://expr-lang.org/docs/language-definition.
     workflows.argoproj.io/rbac-rule: "'admin' in groups"
     # The precedence is used to determine which service account to use whe
     # Precedence is an integer. It may be negative. If omitted, it defaults to "0".

docs/data-sourcing-and-transformation.md

@@ -53,6 +53,6 @@ A `data` template must always contain a `source`. Current available sources:
 
 A `data` template may contain any number of transformations (or zero). The transformations will be applied serially in order. Current available transformations:
 
-* `expression`: an [`expr`](https://github.com/expr-lang/expr) expression. See language definition [here](https://github.com/expr-lang/expr/blob/master/docs/Language-Definition.md). When defining `expr` expressions Argo will pass the available data to the environment as a variable called `data` (see example above).
+* `expression`: an [expression](variables.md#expression). The data is accessible in the `data` variable (see example above).
 
     We understand that the `expression` transformation is limited. We intend to greatly expand the functionality of this template with our community's feedback. Please see the link at the top of this document to submit ideas or use cases for this feature.

docs/events.md

@@ -150,14 +150,12 @@ requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/
 
 ## Event Expression Syntax and the Event Expression Environment
 
-**Event expressions** are expressions that are evaluated over the **event expression environment**.
+**Event expressions** are [expressions](variables.md#expression) that are evaluated over the **event expression environment**.
 
 ### Expression Syntax
 
 Because the endpoint accepts any JSON data, it is the user's responsibility to write a suitable expression to correctly filter the events they are interested in. Therefore, DO NOT assume the existence of any fields, and guard against them using a nil check.
 
-[Learn more about expression syntax](https://github.com/expr-lang/expr).
-
 ### Expression Environment
 
 The event environment contains:

docs/retries.md

@@ -85,9 +85,8 @@ spec:
 
 > v3.2 and after
 
-You can also use `expression` to control retries. The `expression` field
-accepts an [expr](https://github.com/expr-lang/expr) expression and has
-access to the following variables:
+You can also use `expression` to control retries.
+This is an [expression](variables.md#expression) with access to the following variables:
 
 - `lastRetry.exitCode`: The exit code of the last retry, or "-1" if not available
 - `lastRetry.status`: The phase of the last retry: Error, Failed

docs/variables.md

@@ -56,7 +56,7 @@ The tag is substituted with the result of evaluating the tag as an expression.
 Note that any hyphenated parameter names or step names will cause a parsing error. You can reference them by
 indexing into the parameter or step map, e.g. `inputs.parameters['my-param']` or `steps['my-step'].outputs.result`.
 
-[Learn about the expression syntax](https://github.com/expr-lang/expr/blob/master/docs/language-definition.md).
+[Learn more about the expression syntax](https://expr-lang.org/docs/language-definition).
 
 #### Examples