Mark some use-cases doc in need of refresh

If anyone thinks one of these does not need updates, then we can remove
it from this list. I added a notice to each doc that I haven't recently
reviewed, (regardless of whether I am the original author.)

The use-cases docs that are not covered here are all ones intended to be
migrated into the Installation guides, per the GSoD plan that is being
advanced here.

So the use-cases section of the docs may go away entirely, (unless some
of these docs turn out to survive all this without getting relocated):

#1560

Signed-off-by: Kingdon Barrett <[email protected]>

content/en/flux/use-cases/gh-actions-app-builder.md

@@ -5,6 +5,12 @@ description: "How to build and push image tags for Flux from Git branches and ta
 weight: 39
 ---
 
+{{% alert color="warning" title="Disclaimer" %}}
+Note that this guide needs review in consideration of Flux v2, and likely needs to be refreshed.
+
+Expect this doc to either be archived soon, or to receive some overhaul.
+{{% /alert %}}
+
 This guide shows how to configure GitHub Actions to build an image for each new commit pushed on a branch, for PRs, or for tags in the most basic way that Flux's automation can work with and making some considerations for both dev and production.
 
 A single GitHub Actions workflow is presented with a few variations but one simple theme: Flux's only firm requirement for integrating with CI is for the CI to build and push an image. So this document shows how to do just that.

content/en/flux/use-cases/gh-actions-auto-pr.md

@@ -4,6 +4,12 @@ linkTitle: GitHub Actions Auto PR
 description: "How to configure GitHub Pull Requests for Flux image updates."
 weight: 50
 ---
+{{% alert color="warning" title="Disclaimer" %}}
+Note that this guide needs review in consideration of Flux v2, and likely needs to be refreshed.
+
+Expect this doc to either be archived soon, or to receive some overhaul.
+{{% /alert %}}
+
 
 This guide shows how to configure GitHub Actions to open a pull request whenever a selected branch is pushed.
 

content/en/flux/use-cases/gh-actions-helm-promotion.md

@@ -5,6 +5,12 @@ description: "How to configure a promotion workflow for Flux HelmReleases with G
 weight: 31
 ---
 
+{{% alert color="warning" title="Disclaimer" %}}
+Note that this guide needs review in consideration of Flux v2, and likely needs to be refreshed.
+
+Expect this doc to either be archived soon, or to receive some overhaul.
+{{% /alert %}}
+
 This guide shows how to configure Flux and GitHub Actions to promote
 Helm Releases across environments when a new Helm chart version is available.
 

content/en/flux/use-cases/gh-actions-manifest-generation.md

@@ -5,6 +5,14 @@ description: "How to use GitHub Actions for Kubernetes manifest generation."
 weight: 40
 ---
 
+{{% alert color="warning" title="Disclaimer" %}}
+Note that this guide no longer is the recommended way to handle manifest generation in Flux, it was written before OCI Artifacts were available in Flux.
+
+If you want to use Flux with tooling-generated manifests today, you should capture the output and store it in an OCI Artifact with `flux push artifact`. The following doc uses an old method that has many disadvantages: can't be secured with Cosign, can't be indexed as efficiently as an OCI registry's tag-based distribution, nor can the delivery of a private Git repository typically be authenticated and authorized in a workload cluster with any cloud-based IAM or secure ambient environmental credentials that are used to access a private OCI registry.
+
+Expect this doc to either be archived soon, or to receive a major overhaul in support of the new preferred approach described above.
+{{% /alert %}}
+
 This example implements "build-time" manifest generation on GitHub Actions.
 
 Third-party tools are used to generate YAML manifests in a CI job. The updated YAML are committed and pushed to Git, where `kustomize-controller` finally applies them.

content/en/flux/use-cases/jenkins.md

@@ -5,6 +5,12 @@ description: "How to use Jenkins CI for building images together with Flux's ima
 weight: 50
 ---
 
+{{% alert color="warning" title="Disclaimer" %}}
+Note that this guide has not been updated since more than a year ago, it does not address Kubernetes 1.24 or above, and needs to be refreshed.
+
+Expect this doc to either be archived soon, or to receive an overhaul.
+{{% /alert %}}
+
 This guide explains how to configure Flux with Jenkins, with the core ideas of [GitOps Principles] in mind. Let Jenkins handle CI (or Continuous Integration: image build and test, tagging and pushing), and let Flux handle CD (or Continuous Deployment) by making use of the Image Update Automation feature.
 
 ## Declarative Artifacts

content/en/flux/use-cases/karmada.md

@@ -9,6 +9,12 @@ weight: 20
 Note that this guide is not for doing GitOps, but for managing Helm releases for applications among multiple clusters.
 {{% /alert %}}
 
+{{% alert color="warning" title="Disclaimer" %}}
+Note that this guide needs review in consideration of Flux v2, and likely needs to be refreshed.
+
+Expect this doc to either be archived soon, or to receive some overhaul.
+{{% /alert %}}
+
 ## Background
 
 [Karmada](https://github.com/karmada-io/karmada) is a Kubernetes management system that enables you to run your cloud-native applications across multiple Kubernetes clusters and clouds, with no changes to your applications.