diff --git a/content/en/flux/use-cases/gh-actions-app-builder.md b/content/en/flux/use-cases/gh-actions-app-builder.md index a1811e428..f1cbc1694 100644 --- a/content/en/flux/use-cases/gh-actions-app-builder.md +++ b/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. diff --git a/content/en/flux/use-cases/gh-actions-auto-pr.md b/content/en/flux/use-cases/gh-actions-auto-pr.md index 277012de9..e14f92ca5 100644 --- a/content/en/flux/use-cases/gh-actions-auto-pr.md +++ b/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. diff --git a/content/en/flux/use-cases/gh-actions-helm-promotion.md b/content/en/flux/use-cases/gh-actions-helm-promotion.md index 3183239fe..c5bd47cf5 100644 --- a/content/en/flux/use-cases/gh-actions-helm-promotion.md +++ b/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. diff --git a/content/en/flux/use-cases/gh-actions-manifest-generation.md b/content/en/flux/use-cases/gh-actions-manifest-generation.md index a6c34332c..fcc8809f9 100644 --- a/content/en/flux/use-cases/gh-actions-manifest-generation.md +++ b/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. diff --git a/content/en/flux/use-cases/jenkins.md b/content/en/flux/use-cases/jenkins.md index 5a8c27dce..915df3804 100644 --- a/content/en/flux/use-cases/jenkins.md +++ b/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 diff --git a/content/en/flux/use-cases/karmada.md b/content/en/flux/use-cases/karmada.md index 12f49d93d..59850e1d9 100644 --- a/content/en/flux/use-cases/karmada.md +++ b/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.