Add warnings about changes: to CI Config docs

Customers have frequently attempted to use changes: policies in
scheduled and manually run pipelines that have no Git push event.
There are no new or old commits in this scenario, and changes:
returns true by default and causes a great deal of confusion. We
should be more vocal about what `changes:` means and why it works
the way it does.

doc/ci/yaml/README.md

@@ -728,6 +728,16 @@ Learn more about [variables expressions](../variables/README.md#environment-vari
 Using the `changes` keyword with `only` or `except` makes it possible to define if
 a job should be created based on files modified by a Git push event.
 
+This means the `only:changes` policy is only useful for Pipelines that are
+triggered via `push`, `merge_request_event`, or `external_merge_request_event`.
+If there is no Git push event, `changes` cannot determine if any given file is
+new or old and will return true by default.
+
+CAUTION: **Warning:**
+Pipelines triggered via `web`, `trigger`, `schedule`, `api`, `external`,
+`pipeline`, or `chat`, the pipeline **will have no modified paths and `changes`
+policies will always evaluate to true**.
+
 For example:
 
 ```yaml
@@ -910,7 +920,13 @@ at all, the behavior defaults to `job:when`, which continues to default to
 #### `rules:changes`
 
 `changes` works exactly the same way as [`only`/`except`](#onlychangesexceptchanges),
-accepting an array of paths.
+accepting an array of paths. This includes the caveat about using `changes:` in
+pipelines that do not have an associated Git push event.
+
+CAUTION: **Warning:**
+Pipelines triggered via `web`, `trigger`, `schedule`, `api`, `external`,
+`pipeline`, or `chat`, the pipeline **will have no modified paths and `changes`
+clauses will always evaluate to true**.
 
 For example: