fix(docs): update API doc links (argoproj#3310)

Signed-off-by: Derek Wang <[email protected]>

docs/concepts/event_source.md

@@ -35,7 +35,7 @@ Available event-sources:
 
 ## Specification
 
-The complete specification is available [here](https://github.com/argoproj/argo-events/blob/master/api/event-source.md).
+The complete specification is available [here](../APIs.md#argoproj.io/v1alpha1.EventSourceSpec).
 
 ## Examples
 

docs/concepts/sensor.md

@@ -9,7 +9,7 @@ A dependency is an event the sensor is waiting to happen.
 
 ## Specification
 
-Complete specification is available [here](https://github.com/argoproj/argo-events/blob/master/api/sensor.md).
+Complete specification is available [here](../APIs.md#argoproj.io/v1alpha1.Sensor).
 
 ## Examples
 

docs/eventbus/eventbus.md

@@ -18,6 +18,6 @@ The common practice is to create an EventBus named `default` in the namespace. I
 you want to use a different name, or you want to have multiple EventBus in one
 namespace, you need to specify `eventBusName` in the spec of EventSource and
 Sensor correspondingly, so that they can find the right one. See EventSource
-[spec](https://github.com/argoproj/argo-events/tree/stable/api/event-source.md#eventsourcespec)
+[spec](../APIs.md#argoproj.io/v1alpha1.EventSourceSpec)
 and Sensor
-[spec](https://github.com/argoproj/argo-events/tree/stable/api/sensor.md#sensorspec).
+[spec](../APIs.md#argoproj.io/v1alpha1.SensorSpec).

docs/eventbus/jetstream.md

@@ -11,8 +11,9 @@ metadata:
  name: default
 spec:
  jetstream:
- version: latest # Do NOT use "latest" but a specific version in your real deployment
- # See: https://argoproj.github.io/argo-events/eventbus/jetstream/#version
+ version:
+ latest # Do NOT use "latest" but a specific version in your real deployment
+ # See: https://argoproj.github.io/argo-events/eventbus/jetstream/#version
 ```
 
 The example above brings up a Jetstream
@@ -22,7 +23,7 @@ with 3 replicas in the namespace.
 ## Properties
 
 Check
-[here](https://github.com/argoproj/argo-events/blob/master/api/event-bus.md#argoproj.io/v1alpha1.JetstreamBus)
+[here](../APIs.md#argoproj.io/v1alpha1.JetStreamBus)
 for the full spec of `jetstream`.
 
 ### version
@@ -35,7 +36,6 @@ kubectl get configmap argo-events-controller-config -o yaml
 
 Check [here](https://docs.nats.io/nats-concepts/jetstream/streams#configuration) for a list of configurable features per version.
 
-
 ### A more involved example
 
 Another example with more configuration:
@@ -80,9 +80,9 @@ metadata:
  name: default
 spec:
  jetstreamExotic:
-  url: nats://xxxxx:xxx
-  accessSecret:
-  name: my-secret-name
-  key: secret-key
-  streamConfig: ""
+ url: nats://xxxxx:xxx
+ accessSecret:
+ name: my-secret-name
+ key: secret-key
+ streamConfig: ""
 ```

docs/eventbus/kafka.md

@@ -8,35 +8,42 @@ topics created (unless you have auto create enabled, see [topics](#topics)
 below).
 
 ## Example
+
 ```yaml
 kind: EventBus
 metadata:
  name: default
 spec:
  kafka:
- url: kafka:9092  # must be managed independently
- topic: "example"  # optional
+ url: kafka:9092 # must be managed independently
+ topic: "example" # optional
 ```
 
-See [here](https://github.com/argoproj/argo-events/blob/master/api/event-bus.md#kafkabus)
+See [here](../APIs.md#argoproj.io/v1alpha1.KafkaBus)
 for the full specification.
 
 ## Properties
+
 ### url
+
 Comma seperated list of kafka broker urls, the kafka broker must be managed
 independently of Argo Events.
 
 ### topic
+
 The topic name, defaults to `{namespace-name}-{eventbus-name}`. Two additional
 topics per Sensor are also required, see see [topics](#topics) below for more
 information.
 
 ### version
+
 Kafka version, we recommend not manually setting this field in most
 circumstances. Defaults to the oldest supported stable version.
 
 ### tls
+
 Enables TLS on the kafka connection.
+
 ```
 tls:
  caCertSecret:
@@ -51,7 +58,9 @@ tls:
 ```
 
 ### sasl
+
 Enables SASL authentication on the kafka connection.
+
 ```
 sasl:
  mechanism: PLAIN
@@ -64,22 +73,27 @@ sasl:
 ```
 
 ### consumerGroup.groupName
+
 Consumer group name, defaults to `{namespace-name}-{sensor-name}`.
 
 ### consumerGroup.rebalanceStrategy
+
 The kafka rebalance strategy, can be one of: sticky, roundrobin, range.
 Defaults to range.
 
 ### consumerGroup.startOldest
+
 When starting up a new group do we want to start from the oldest event
 (true) or the newest event (false). Defaults to false
 
 ## Security
+
 You can enable TLS or SASL authentication, see above for configuration
 details. You must enable these features in your Kafka Cluster and make
 the certifactes/credentials available in a Kubernetes secret.
 
 ## Topics
+
 The Kafka EventBus requires one event topic and two additional topics (trigger
 and action) per Sensor. These topics will not be created automatically unless
 the Kafka `auto.create.topics.enable` cluster configuration is set to true,
@@ -92,20 +106,20 @@ EventBus be sure to create topics with more than one partition.
 
 By default the topics are named as follows.
 
-| topic | name |
-| ----- | ---- |
-| event | `{namespace}-{eventbus-name}` |
+| topic  | name  |
+| ------- | --------------------------------------------------- |
+| event  | `{namespace}-{eventbus-name}`  |
 | trigger | `{namespace}-{eventbus-name}-{sensor-name}-trigger` |
-| action | `{namespace}-{eventbus-name}-{sensor-name}-action` |
+| action  | `{namespace}-{eventbus-name}-{sensor-name}-action`  |
 
 If a topic name is specified in the EventBus specification, then the topics are
 named as follows.
 
-| topic | name |
-| ----- | ---- |
-| event | `{spec.kafka.topic}` |
+| topic  | name  |
+| ------- | ------------------------------------------ |
+| event  | `{spec.kafka.topic}`  |
 | trigger | `{spec.kafka.topic}-{sensor-name}-trigger` |
-| action | `{spec.kafka.topic}-{sensor-name}-action` |
+| action  | `{spec.kafka.topic}-{sensor-name}-action`  |
 
 ## Horizontal Scaling and Leader Election
 

docs/eventbus/stan.md

@@ -1,4 +1,3 @@
-
 ## NATS Streaming
 
 You can create a `native` NATS EventBus, or connect to an existing NATS
@@ -44,7 +43,7 @@ spec:
 #### Properties
 
 Check
-[here](https://github.com/argoproj/argo-events/tree/stable/api/event-bus.md#argoproj.io/v1alpha1.NativeStrategy)
+[here](../APIs.md#argoproj.io/v1alpha1.NativeStrategy)
 for the full spec of `native`.
 
 - `replicas` - StatefulSet replicas, defaults to 3, and requires minimal 3.
@@ -167,4 +166,4 @@ A sample result:
 ```
 
 All the events in a namespace are published to same channel/subject/topic
- named `eventbus-{namespace}` in the EventBus.
+named `eventbus-{namespace}` in the EventBus.

docs/eventsources/gcp-pubsub.md

@@ -8,7 +8,7 @@ combination.
 
 | Topic Provided/Existing | Sub ID Provided/Existing | Actions |
 | ----------------------- | ------------------------ | --------------------------------------------------------------------- |
-| Yes/Yes | Yes/Yes | Validate if given topic matches subscription's topic  |
+| Yes/Yes | Yes/Yes | Validate if given topic matches subscription's topic |
 | Yes/Yes | Yes/No | Create a subscription with given ID |
 | Yes/Yes | No/- | Create or re-use subscription with auto generated subID |
 | Yes/No | Yes/No | Create a topic and a subscription with given subID |
@@ -23,7 +23,7 @@ If you have configured
 [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
 and want to use it for a PubSub EventSource, leave `credentialSecret` nil.
 
-Full spec is available [here](https://github.com/argoproj/argo-events/tree/stable/api/event-source.md#pubsubeventsource).
+Full spec is available [here](../APIs.md#argoproj.io/v1alpha1.PubSubEventSource).
 
 See a PubSub EventSource
 [example](https://github.com/argoproj/argo-events/tree/stable/examples/event-sources/gcp-pubsub.yaml).

docs/eventsources/setup/bitbucket.md

@@ -24,22 +24,22 @@ The structure of an event dispatched by the event-source over the eventbus looks
 
 ## Specification
 
-Bitbucket event-source specification is available [here](https://github.com/argoproj/argo-events/blob/master/api/event-source.md#bitbucketeventsource). <br />
+Bitbucket event-source specification is available [here](../../APIs.md#argoproj.io/v1alpha1.BitbucketEventSource). <br />
 Example event-source yaml file is [here](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucket.yaml).
 
 ## Setup
 
 > **_NOTE:_** In this setup, we will use the basic auth strategy together with [App password](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/) (there is also support for [OAuth](https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/)).
 
-1. Create an App password if you don't have one. Follow [instructions](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/) to create a new Bitbucket App password.
- Grant it the `Webhooks - Read and Write` permissions as well as any permissions that applies to the events that the webhook subscribes to (e.g. if you're using the [example event-source yaml file](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucket.yaml) which subscribes to `repo:push` event then you would also need to grant the `Repositories - Read` permission).
+1.  Create an App password if you don't have one. Follow [instructions](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/) to create a new Bitbucket App password.
+  Grant it the `Webhooks - Read and Write` permissions as well as any permissions that applies to the events that the webhook subscribes to (e.g. if you're using the [example event-source yaml file](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucket.yaml) which subscribes to `repo:push` event then you would also need to grant the `Repositories - Read` permission).
 
-1. Base64 encode your App password and your Bitbucket username.
+1.  Base64 encode your App password and your Bitbucket username.
 
  echo -n <username> | base64
  echo -n <password> | base64
 
-1. Create a secret called `bitbucket-access` that contains your encoded Bitbucket credentials.
+1.  Create a secret called `bitbucket-access` that contains your encoded Bitbucket credentials.
 
  apiVersion: v1
  kind: Secret
@@ -50,28 +50,28 @@ Example event-source yaml file is [here](https://github.com/argoproj/argo-events
   username: <base64-encoded-username-from-previous-step>
   password: <base64-encoded-password-from-previous-step>
 
-1. Deploy the secret into K8s cluster.
+1.  Deploy the secret into K8s cluster.
 
  kubectl -n argo-events apply -f bitbucket-access.yaml
 
-1. The event-source for Bitbucket creates a pod and exposes it via service.
- The name for the service is in `<event-source-name>-eventsource-svc` format.
- You will need to create an Ingress or OpenShift Route for the event-source service so that it can be reached from Bitbucket.
- You can find more information on Ingress or Route online.
+1.  The event-source for Bitbucket creates a pod and exposes it via service.
+  The name for the service is in `<event-source-name>-eventsource-svc` format.
+  You will need to create an Ingress or OpenShift Route for the event-source service so that it can be reached from Bitbucket.
+  You can find more information on Ingress or Route online.
 
-1. Create the event source by running the following command. You can use the [example event-source yaml file](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucket.yaml) but make sure to replace the `url` field and to modify `owner`, `repositorySlug` and `projectKey` fields with your own repo.
+1.  Create the event source by running the following command. You can use the [example event-source yaml file](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucket.yaml) but make sure to replace the `url` field and to modify `owner`, `repositorySlug` and `projectKey` fields with your own repo.
 
  kubectl apply -n argo-events -f <event-source-file>
 
-1. Go to `Webhooks` under your project settings on Bitbucket and verify the webhook is registered. You can also do the same by looking at the event-source pod logs.
+1.  Go to `Webhooks` under your project settings on Bitbucket and verify the webhook is registered. You can also do the same by looking at the event-source pod logs.
 
-1. Create the sensor by running the following command.
+1.  Create the sensor by running the following command.
 
  kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/master/examples/sensors/bitbucket.yaml
 
-1. Make a change to one of your project files and commit. It will trigger an argo workflow.
+1.  Make a change to one of your project files and commit. It will trigger an argo workflow.
 
-1. Run `argo list` to find the workflow.
+1.  Run `argo list` to find the workflow.
 
 ## Troubleshoot
 

docs/eventsources/setup/bitbucketserver.md

@@ -24,19 +24,19 @@ The structure of an event dispatched by the event-source over the eventbus looks
 
 ## Specification
 
-Bitbucket Server event-source specification is available [here](https://github.com/argoproj/argo-events/blob/master/api/event-source.md#bitbucketservereventsource). <br />
+Bitbucket Server event-source specification is available [here](../../APIs.md#argoproj.io/v1alpha1.BitbucketServerEventSource). <br />
 Example event-source yaml file is [here](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucketserver.yaml).
 
 ## Setup
 
-1. Create an API token if you don't have one. Follow [instructions](https://confluence.atlassian.com/bitbucketserver072/personal-access-tokens-1005335924.html) to create a new Bitbucket Server API Token.
- Grant it the `Projects: Admin` permissions.
+1.  Create an API token if you don't have one. Follow [instructions](https://confluence.atlassian.com/bitbucketserver072/personal-access-tokens-1005335924.html) to create a new Bitbucket Server API Token.
+  Grant it the `Projects: Admin` permissions.
 
-1. Base64 encode your API token key.
+1.  Base64 encode your API token key.
 
  echo -n <api-token-key> | base64
 
-1. Create a secret called `bitbucketserver-access` that contains your encoded Bitbucket Server API token. You can also include a secret key that is encoded with `base64` for your webhook if any.
+1.  Create a secret called `bitbucketserver-access` that contains your encoded Bitbucket Server API token. You can also include a secret key that is encoded with `base64` for your webhook if any.
 
  apiVersion: v1
  kind: Secret
@@ -47,28 +47,28 @@ Example event-source yaml file is [here](https://github.com/argoproj/argo-events
   token: <base64-encoded-api-token-from-previous-step>
   secret: <base64-encoded-webhook-secret-key>
 
-1. Deploy the secret into K8s cluster.
+1.  Deploy the secret into K8s cluster.
 
  kubectl -n argo-events apply -f bitbucketserver-access.yaml
 
-1. The event-source for Bitbucket Server creates a pod and exposes it via service.
- The name for the service is in `<event-source-name>-eventsource-svc` format.
- You will need to create an Ingress or Openshift Route for the event-source service so that it can be reached from Bitbucket Server.
- You can find more information on Ingress or Route online.
+1.  The event-source for Bitbucket Server creates a pod and exposes it via service.
+  The name for the service is in `<event-source-name>-eventsource-svc` format.
+  You will need to create an Ingress or Openshift Route for the event-source service so that it can be reached from Bitbucket Server.
+  You can find more information on Ingress or Route online.
 
-1. Create the event source by running the following command. You can use the example event-source yaml file from [here](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucketserver.yaml) but make sure to replace the `url` field and to modify the `repositories` list with your own repos.
+1.  Create the event source by running the following command. You can use the example event-source yaml file from [here](https://github.com/argoproj/argo-events/blob/master/examples/event-sources/bitbucketserver.yaml) but make sure to replace the `url` field and to modify the `repositories` list with your own repos.
 
  kubectl apply -n argo-events -f <event-source-file>
 
-1. Go to `Webhooks` under your project settings on Bitbucket Server and verify the webhook is registered. You can also do the same by looking at the event-source pod logs.
+1.  Go to `Webhooks` under your project settings on Bitbucket Server and verify the webhook is registered. You can also do the same by looking at the event-source pod logs.
 
-1. Create the sensor by running the following command.
+1.  Create the sensor by running the following command.
 
  kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/master/examples/sensors/bitbucketserver.yaml
 
-1. Make a change to one of your project files and commit. It will trigger an argo workflow.
+1.  Make a change to one of your project files and commit. It will trigger an argo workflow.
 
-1. Run `argo list` to find the workflow.
+1.  Run `argo list` to find the workflow.
 
 ## Troubleshoot
 

docs/eventsources/setup/calendar.md

@@ -24,19 +24,19 @@ The structure of an event dispatched by the event-source over the eventbus looks
 
 ## Specification
 
-Calendar event-source specification is available [here](https://github.com/argoproj/argo-events/blob/master/api/event-source.md#calendareventsource).
+Calendar event-source specification is available [here](../../APIs.md#argoproj.io/v1alpha1.CalendarEventSource).
 
 ## Setup
 
-1. Install the event source in the `argo-events` namespace.
+1.  Install the event source in the `argo-events` namespace.
 
  kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/event-sources/calendar.yaml
 
-1. The event-source will generate events at every 10 seconds. Let's create the sensor.
+1.  The event-source will generate events at every 10 seconds. Let's create the sensor.
 
-  kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/sensors/calendar.yaml 
+ kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/sensors/calendar.yaml
 
-1. Once the sensor pod is in running state, wait for next interval to occur for sensor to trigger workflow.
+1.  Once the sensor pod is in running state, wait for next interval to occur for sensor to trigger workflow.
 
 ## Troubleshoot