Loki Operator 發布流程全解從 bundle 生成到 OperatorHub 上架【免費下載鏈接】lokiLike Prometheus, but for logs.項目地址: https://gitcode.com/GitHub_Trending/lok/loki本指南系統講解 Grafana Loki Operator位于 operator/ 目錄的社區版本發布機制如何通過make bundle-all生成 OLM bundle、如何借助 release-please 自動化版本號提升與 CHANGELOG 生成、如何將鏡像發布到制品倉庫以及如何自動向兩個 OperatorHub 社區倉庫提交上架 PR。讀完本文你將完整掌握 Loki Operator 從一次代碼合并到在 Kubernetes 生態中可被 OLM 安裝的端到端發布鏈路并理解每一環背后的工作流設計與配置細節。發布流程總體設計發布一個 Loki Operator 社區版本需要依次完成以下四件事對應 release.md 中 Design 一節的描述提升 Loki Operator 版本號并生成 bundle 清單執行make bundle-all更新 CHANGELOG.md到新版本創建 release tag 與 GitHub release向 [k8s-operatorhub/community-operators] 與 [redhat-openshift-ecosystem/community-operators-prod] 兩個倉庫各開一個 PR提交新版本 bundle 的內容。其中第 2、3 步由 GitHub 官方維護的release-pleaseaction 自動化完成第 4 步則由一個在 release tag 創建時觸發的 workflow 自動執行。第 1 步bundle 生成目前仍是人工操作是整條鏈路中唯一沒有自動化的環節。值得強調的是Loki Operator 與 Loki 主項目共享同一個倉庫但Operator 的 release-please 流程與 Loki 自身的發布流程是相互獨立的Operator 的配置單獨存放在 operator/release-please-config.json且 workflow 只監聽operator/**路徑的變更。第 1 步用 make bundle-all 生成 bundle 清單bundle 是什么bundle 是 OLMOperator Lifecycle Manager生態中 Operator 的標準打包格式包含 ClusterServiceVersionCSV清單、CustomResourceDefinitionCRD以及元數據注解。Loki Operator 針對不同發行渠道維護了三個 bundle 變體見 operator/Makefile 中的VARIANT變量變體鏡像倉庫通道適用場景communitydocker.io/grafanaalpha通用社區分發默認community-openshiftdocker.io/grafanaalpha帶 OpenShift 兼容注解的社區包openshiftquay.io/openshift-loggingstableOpenShift 官方渠道隨 OpenShift Logging 發行bundle-all目標會依次生成以上三個變體operator/Makefile.PHONY: bundle-all bundle-all: ## Generate both bundles. $(MAKE) bundle $(MAKE) bundle VARIANTcommunity-openshift $(MAKE) bundle VARIANTopenshiftbundle 生成的具體動作單個bundle目標operator/Makefile做三件事.PHONY: bundle bundle: manifests $(KUSTOMIZE) $(OPERATOR_SDK) ## Generate variant bundle manifests and metadata, then validate generated files. cd config/manager $(KUSTOMIZE) edit set image controller$(IMG) cd $(BUNDLE_DIR) cp ../../PROJECT . $(KUSTOMIZE) build ../../$(MANIFESTS_DIR) | $(OPERATOR_SDK) generate bundle $(BUNDLE_BUILD_GEN_FLAGS) rm PROJECT $(OPERATOR_SDK) bundle validate $(BUNDLE_DIR)通過kustomize edit set image controller$(IMG)把 CSV 中的控制器鏡像地址替換為當前版本鏡像用operator-sdk generate bundle從config/manifests/variant生成 bundle 清單輸出到./bundle/variant目錄如 operator/bundle/community/用operator-sdk bundle validate校驗生成的 bundle 是否符合 OLM 規范。版本號由VERSION變量控制當前倉庫默認值為0.11.0見 operator/Makefile。發布前需要先在 PR 中把該版本號提升為目標版本例如升級到0.11.1或0.12.0同時保證提交信息規范見下文 Releasing 一節這也是原文檔強調 be careful with the commit message 的原因。第 2、3 步release-please 自動化版本發布release-please 的工作原理release-please 通過解析 git 歷史中的Conventional Commit提交信息來驅動整個發布流程掃描到可發布單元releasable unit即以feat、fix、deps為前綴的提交后自動創建 release PR其中包含版本號提升與 CHANGELOG 生成release PR 被合并后release-please 自動創建 GitHub release隨后繼續等待下一個可發布單元再開啟下一輪 release PR。Operator 的 release-please workflow 位于 .github/workflows/operator-release-please.yml其觸發條件與關鍵參數如下on: push: paths: - operator/** branches: - main即只有當operator/**路徑下有合并到main的提交時才會運行使用 GitHub Apploki-gh-app簽發的 token 調用googleapis/release-please-actionv5.0.0并指定path: operator只關注operator子目錄config-file: operator/release-please-config.json使用獨立的 manifest 配置。operator/release-please-config.json 詳解operator/release-please-config.json 是理解整個發布策略的關鍵其完整內容如下{ bump-minor-pre-major: true, bump-patch-for-minor-pre-major: true, include-component-in-tag: true, draft: true, tag-separator: /, packages: { operator: { component: operator, release-type: go, pull-request-title-pattern: chore(${component}): Community release ${version}, changelog-path: CHANGELOG.md } } }結合原文檔的說明各配置項的含義如下include-component-in-tagtag-separator: /release tag 采用operator/vX.Y.Z格式組件名 斜杠 版本號。這個 tag 前綴也是后續 OperatorHub 發布 workflow 的觸發過濾器release-type: go按 Go 模塊語義處理版本提升作用于 operator/ 目錄pull-request-title-patternrelease PR 的標題固定為chore(operator): Community release version格式——注意這個標題格式正是下一節 防止未更新 manifests 就合并 檢查工作流的匹配依據changelog-path: CHANGELOG.md生成的變更日志寫入 operator/CHANGELOG.md。從該文件可以看到 release-please 的實際輸出風格每個版本一節包含? BREAKING CHANGES、Features、Bug Fixes分組且 security/deps 類提交也會被歸類記錄。為什么使用 bump-minor-pre-major 與 bump-patch-for-minor-pre-major由于 Operator 目前仍處于v1.0.0之前的階段pre-major配置開啟了bump-minor-pre-major與bump-patch-for-minor-pre-major效果是合并feat、fix、deps提交 → 只提升patch版本如v0.10.1→v0.10.2合并feat!、fix!帶感嘆號的破壞性變更提交→ 提升minor版本如v0.10.x→v0.11.0。由此在未引入破壞性變更的前提下當前僅監聽main分支的 release-please 可以支撐兩種發布場景Case 1patch 發布從v0.Y.x的 diff 發布v0.Y.x1。該場景在破壞性特性合并進main之前一直有效Case 2minor 發布從v0.Y.x的 diff 發布新版本v0.Y1.0。為什么啟用 draftOperator 與 Loki 主項目共享同一個 GitHub 倉庫直接由 release-please 創建的 release 會被標記為倉庫的latest導致 Loki 最新版本 被誤顯示為 Operator 的版本。release-please 本身沒有提供關閉latest標記的選項因此配置了draft: true讓 release-please 只創建草稿 release再由后續步驟發布.github/workflows/operator-release-please.yml 中的publishReleasejob 在鏡像構建完成后執行gh release edit $RELEASE_NAME --draftfalse --latestfalse即把草稿轉為正式 release同時明確不設為 latest從而與 Loki 主項目的發布記錄區分開。publishImages構建并推送 Operator 鏡像當 release-please 判定需要發布release_created輸出為 true時publishImagesjob 通過復用工作流 .github/workflows/operator-reusable-image-build.yml 構建并推送 Operator 鏡像傳入參數包括dockerfile: operator/Dockerfile見 operator/Dockerfileregistry: us-docker.pkg.dev、organization: grafanalabs-global/dockerhub-loki-prod-mirror、image_name: loki-operatortag由 release-please 輸出的major.minor.patch三部分拼接而成。鏡像最終推送到 Google Artifact RegistryGAR的地址為us-docker.pkg.dev/grafanalabs-global/dockerhub-loki-prod-mirror/loki-operator:version之后由gar-image-mirror服務將其鏡像同步到 Docker Hub 的docker.io/grafana/loki-operator。從復用工作流源碼可以看到構建細節.github/workflows/operator-reusable-image-build.yml使用 QEMU Docker Buildx 進行多架構構建platforms: linux/amd64,linux/arm64,linux/arm構建上下文按鏡像名推斷loki-operator-bundle使用operator/bundle/openshift其余含loki-operator使用operator目錄該復用工作流同時支持兩套倉庫體系登錄 GARus-docker.pkg.dev或從 Vault 拉取憑據登錄quay.ioOpenShift 渠道使用。第 4 步向 OperatorHub 社區倉庫發布觸發機制發布工作流 .github/workflows/operator-publish-operator-hub.yml 監聽 GitHubrelease 發布事件并校驗 tag 前綴on: release: types: [published] jobs: operator-hub-prod-release: if: startsWith(github.event.release.tag_name, operator/) ...當 tag 以operator/開頭即 release-please 創建的operator/vX.Y.Z時會并發調用兩次復用工作流 .github/workflows/operator-reusable-hub-release.yml分別面向redhat-openshift-ecosystem/community-operators-prodOpenShift 生產渠道k8s-operatorhub/community-operators通用社區渠道。復用工作流做了哪些事.github/workflows/operator-reusable-hub-release.yml 依次完成以下動作簽發 GitHub App token使用loki-operator-hub-publisher這個專用 GitHub App保證后續以受信任的 bot 身份操作提取版本號從 tagoperator/vX.Y.Z中通過${TAG:10}切片去掉operator/v前綴得到純版本號寫入環境變量同步 fork用gh repo sync grafanabot/$INPUTS_REPO --source org/repo --force先把 grafanabot 名下的 fork 同步到最新避免拉取完整上游倉庫淺克隆會導致 push 報 shallow update not allowed檢出兩個倉庫分別 checkout grafanabot fork 的 operatorhub 倉庫工作目錄與grafana/loki主倉庫tmp/目錄復制 bundle 清單將新版本目錄創建到 operatorhub 倉庫的operators/loki-operator/version/下內容來自./tmp/operator/bundle/community${OCP_DIR}/*mkdir operators/loki-operator/${VERSION} cp -R ./tmp/operator/bundle/community${OCP_DIR}/* operators/loki-operator/${VERSION} rm -f operators/loki-operator/${VERSION}/bundle.Dockerfile注意這里同時做了兩件重要的適配一是按目標渠道選擇community或community-openshift變體二是刪除 bundle.DockerfileOperatorHub 社區目錄不需要它添加 OpenShift 支持版本注解僅 OpenShift 倉庫使用fjogeleit/yaml-update-action在operators/loki-operator/version/metadata/annotations.yaml中寫入annotations[com.redhat.openshift.versions]當前值為v4.12。這正是原文檔所說 Adding the ocp supported version annotation to the metadata.yaml 的實現創建 PR以 grafanabot 身份CLA 已批準新建分支update-loki-operator-to-version提交并gh pr create --repo org/repo --base mainPR 標題為Update the loki-operator to version。防止未更新 manifests 就合并 release-please PR由于第 1 步make bundle-all生成 bundle尚未自動化、與 release-please 相互獨立存在release-please PR 先合并、bundle 后補的時序風險。為此倉庫設置了專門的守衛工作流 .github/workflows/operator-check-prepare-release-commit.yml。該工作流只針對 release-please PR 運行通過兩個條件限定if: | github.event.pull_request.head.ref release-please--branches--main--components--operator contains(github.event.pull_request.title, chore( operator): Community release)其邏輯是先從 PR 標題chore( operator): Community release semver中提取目標版本號再用gh search commits在main分支搜索提交信息為chore(operator): Prepare community release vsemver的提交若找不到則以退出碼 1 使檢查失敗阻止 PR 合并。也就是說人工提交的版本提升 bundle 生成準備提交必須先于 release-please PR 存在。原文檔也指出一旦第 1 步實現自動化這個守衛工作流就可以移除。Releasing一次完整發布的操作清單綜合以上設計一次真實的 Loki Operator 社區發布按以下步驟執行對應原文檔 Releasing 一節創建版本提升 PR先手動提交一次包含版本號提升與 bundle 生成的變更提交信息務必為chore(operator): Prepare community release vversion例如 v0.6.1 的準備工作并合并到main在 release-please PR 上重新觸發operator-publish-operator-hub檢查確保守衛工作流通過合并 release-please PR合并后 release-please 自動創建 release草稿態標題形如chore(operator): Community release vversion鏡像發布publishImagesjob 構建多架構鏡像并推送到 GAR隨后由gar-image-mirror同步到 Docker Hub 的docker.io/grafana/loki-operatorOperatorHub PR 自動創建operator-publish-operator-hubworkflow 檢測到operator/前綴的正式 release 后自動向k8s-operatorhub/community-operators與redhat-openshift-ecosystem/community-operators-prod兩個倉庫各開一個包含新版本 bundle 的 PR。全鏈路小結把整條發布流水線串起來看Loki Operator 的發布由四類 GitHub Actions 工作流協同完成工作流觸發時機職責operator-release-please.ymloperator/**合并到main生成 CHANGELOG、創建草稿 release、調度鏡像構建與正式發布operator-reusable-image-build.yml被 release workflow 調用多架構構建并推送 Operator 鏡像到 GAR / quay.iooperator-check-prepare-release-commit.ymlrelease-please PR 上校驗 Prepare community release 準備提交已存在operator-publish-operator-hub.ymltag 以operator/開頭的 release 發布觸發向兩個 OperatorHub 社區倉庫的上架 PR其中唯一的人工環節是第 1 步更新 operator/Makefile 中的VERSION并執行make bundle-all重新生成 operator/bundle/ 下的清單隨后以約定的提交信息合入main。其余版本號計算、CHANGELOG 生成、release 創建、鏡像發布與 OperatorHub 上架全部由自動化流水線接管既保證了與 Loki 主項目發布記錄的清晰隔離operator/tag 前綴 draft --latestfalse也保證了每次上架內容的規范性與可追溯性。【免費下載鏈接】lokiLike Prometheus, but for logs.項目地址: https://gitcode.com/GitHub_Trending/lok/loki創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Loki Operator 發布流程全解：從 bundle 生成到 OperatorHub 上架
Loki Operator 發布流程全解從 bundle 生成到 OperatorHub 上架【免費下載鏈接】lokiLike Prometheus, but for logs.項目地址: https://gitcode.com/GitHub_Trending/lok/loki本指南系統講解 Grafana Loki Operator位于 operator/ 目錄的社區版本發布機制如何通過make bundle-all生成 OLM bundle、如何借助 release-please 自動化版本號提升與 CHANGELOG 生成、如何將鏡像發布到制品倉庫以及如何自動向兩個 OperatorHub 社區倉庫提交上架 PR。讀完本文你將完整掌握 Loki Operator 從一次代碼合并到在 Kubernetes 生態中可被 OLM 安裝的端到端發布鏈路并理解每一環背后的工作流設計與配置細節。發布流程總體設計發布一個 Loki Operator 社區版本需要依次完成以下四件事對應 release.md 中 Design 一節的描述提升 Loki Operator 版本號并生成 bundle 清單執行make bundle-all更新 CHANGELOG.md到新版本創建 release tag 與 GitHub release向 [k8s-operatorhub/community-operators] 與 [redhat-openshift-ecosystem/community-operators-prod] 兩個倉庫各開一個 PR提交新版本 bundle 的內容。其中第 2、3 步由 GitHub 官方維護的release-pleaseaction 自動化完成第 4 步則由一個在 release tag 創建時觸發的 workflow 自動執行。第 1 步bundle 生成目前仍是人工操作是整條鏈路中唯一沒有自動化的環節。值得強調的是Loki Operator 與 Loki 主項目共享同一個倉庫但Operator 的 release-please 流程與 Loki 自身的發布流程是相互獨立的Operator 的配置單獨存放在 operator/release-please-config.json且 workflow 只監聽operator/**路徑的變更。第 1 步用 make bundle-all 生成 bundle 清單bundle 是什么bundle 是 OLMOperator Lifecycle Manager生態中 Operator 的標準打包格式包含 ClusterServiceVersionCSV清單、CustomResourceDefinitionCRD以及元數據注解。Loki Operator 針對不同發行渠道維護了三個 bundle 變體見 operator/Makefile 中的VARIANT變量變體鏡像倉庫通道適用場景communitydocker.io/grafanaalpha通用社區分發默認community-openshiftdocker.io/grafanaalpha帶 OpenShift 兼容注解的社區包openshiftquay.io/openshift-loggingstableOpenShift 官方渠道隨 OpenShift Logging 發行bundle-all目標會依次生成以上三個變體operator/Makefile.PHONY: bundle-all bundle-all: ## Generate both bundles. $(MAKE) bundle $(MAKE) bundle VARIANTcommunity-openshift $(MAKE) bundle VARIANTopenshiftbundle 生成的具體動作單個bundle目標operator/Makefile做三件事.PHONY: bundle bundle: manifests $(KUSTOMIZE) $(OPERATOR_SDK) ## Generate variant bundle manifests and metadata, then validate generated files. cd config/manager $(KUSTOMIZE) edit set image controller$(IMG) cd $(BUNDLE_DIR) cp ../../PROJECT . $(KUSTOMIZE) build ../../$(MANIFESTS_DIR) | $(OPERATOR_SDK) generate bundle $(BUNDLE_BUILD_GEN_FLAGS) rm PROJECT $(OPERATOR_SDK) bundle validate $(BUNDLE_DIR)通過kustomize edit set image controller$(IMG)把 CSV 中的控制器鏡像地址替換為當前版本鏡像用operator-sdk generate bundle從config/manifests/variant生成 bundle 清單輸出到./bundle/variant目錄如 operator/bundle/community/用operator-sdk bundle validate校驗生成的 bundle 是否符合 OLM 規范。版本號由VERSION變量控制當前倉庫默認值為0.11.0見 operator/Makefile。發布前需要先在 PR 中把該版本號提升為目標版本例如升級到0.11.1或0.12.0同時保證提交信息規范見下文 Releasing 一節這也是原文檔強調 be careful with the commit message 的原因。第 2、3 步release-please 自動化版本發布release-please 的工作原理release-please 通過解析 git 歷史中的Conventional Commit提交信息來驅動整個發布流程掃描到可發布單元releasable unit即以feat、fix、deps為前綴的提交后自動創建 release PR其中包含版本號提升與 CHANGELOG 生成release PR 被合并后release-please 自動創建 GitHub release隨后繼續等待下一個可發布單元再開啟下一輪 release PR。Operator 的 release-please workflow 位于 .github/workflows/operator-release-please.yml其觸發條件與關鍵參數如下on: push: paths: - operator/** branches: - main即只有當operator/**路徑下有合并到main的提交時才會運行使用 GitHub Apploki-gh-app簽發的 token 調用googleapis/release-please-actionv5.0.0并指定path: operator只關注operator子目錄config-file: operator/release-please-config.json使用獨立的 manifest 配置。operator/release-please-config.json 詳解operator/release-please-config.json 是理解整個發布策略的關鍵其完整內容如下{ bump-minor-pre-major: true, bump-patch-for-minor-pre-major: true, include-component-in-tag: true, draft: true, tag-separator: /, packages: { operator: { component: operator, release-type: go, pull-request-title-pattern: chore(${component}): Community release ${version}, changelog-path: CHANGELOG.md } } }結合原文檔的說明各配置項的含義如下include-component-in-tagtag-separator: /release tag 采用operator/vX.Y.Z格式組件名 斜杠 版本號。這個 tag 前綴也是后續 OperatorHub 發布 workflow 的觸發過濾器release-type: go按 Go 模塊語義處理版本提升作用于 operator/ 目錄pull-request-title-patternrelease PR 的標題固定為chore(operator): Community release version格式——注意這個標題格式正是下一節 防止未更新 manifests 就合并 檢查工作流的匹配依據changelog-path: CHANGELOG.md生成的變更日志寫入 operator/CHANGELOG.md。從該文件可以看到 release-please 的實際輸出風格每個版本一節包含? BREAKING CHANGES、Features、Bug Fixes分組且 security/deps 類提交也會被歸類記錄。為什么使用 bump-minor-pre-major 與 bump-patch-for-minor-pre-major由于 Operator 目前仍處于v1.0.0之前的階段pre-major配置開啟了bump-minor-pre-major與bump-patch-for-minor-pre-major效果是合并feat、fix、deps提交 → 只提升patch版本如v0.10.1→v0.10.2合并feat!、fix!帶感嘆號的破壞性變更提交→ 提升minor版本如v0.10.x→v0.11.0。由此在未引入破壞性變更的前提下當前僅監聽main分支的 release-please 可以支撐兩種發布場景Case 1patch 發布從v0.Y.x的 diff 發布v0.Y.x1。該場景在破壞性特性合并進main之前一直有效Case 2minor 發布從v0.Y.x的 diff 發布新版本v0.Y1.0。為什么啟用 draftOperator 與 Loki 主項目共享同一個 GitHub 倉庫直接由 release-please 創建的 release 會被標記為倉庫的latest導致 Loki 最新版本 被誤顯示為 Operator 的版本。release-please 本身沒有提供關閉latest標記的選項因此配置了draft: true讓 release-please 只創建草稿 release再由后續步驟發布.github/workflows/operator-release-please.yml 中的publishReleasejob 在鏡像構建完成后執行gh release edit $RELEASE_NAME --draftfalse --latestfalse即把草稿轉為正式 release同時明確不設為 latest從而與 Loki 主項目的發布記錄區分開。publishImages構建并推送 Operator 鏡像當 release-please 判定需要發布release_created輸出為 true時publishImagesjob 通過復用工作流 .github/workflows/operator-reusable-image-build.yml 構建并推送 Operator 鏡像傳入參數包括dockerfile: operator/Dockerfile見 operator/Dockerfileregistry: us-docker.pkg.dev、organization: grafanalabs-global/dockerhub-loki-prod-mirror、image_name: loki-operatortag由 release-please 輸出的major.minor.patch三部分拼接而成。鏡像最終推送到 Google Artifact RegistryGAR的地址為us-docker.pkg.dev/grafanalabs-global/dockerhub-loki-prod-mirror/loki-operator:version之后由gar-image-mirror服務將其鏡像同步到 Docker Hub 的docker.io/grafana/loki-operator。從復用工作流源碼可以看到構建細節.github/workflows/operator-reusable-image-build.yml使用 QEMU Docker Buildx 進行多架構構建platforms: linux/amd64,linux/arm64,linux/arm構建上下文按鏡像名推斷loki-operator-bundle使用operator/bundle/openshift其余含loki-operator使用operator目錄該復用工作流同時支持兩套倉庫體系登錄 GARus-docker.pkg.dev或從 Vault 拉取憑據登錄quay.ioOpenShift 渠道使用。第 4 步向 OperatorHub 社區倉庫發布觸發機制發布工作流 .github/workflows/operator-publish-operator-hub.yml 監聽 GitHubrelease 發布事件并校驗 tag 前綴on: release: types: [published] jobs: operator-hub-prod-release: if: startsWith(github.event.release.tag_name, operator/) ...當 tag 以operator/開頭即 release-please 創建的operator/vX.Y.Z時會并發調用兩次復用工作流 .github/workflows/operator-reusable-hub-release.yml分別面向redhat-openshift-ecosystem/community-operators-prodOpenShift 生產渠道k8s-operatorhub/community-operators通用社區渠道。復用工作流做了哪些事.github/workflows/operator-reusable-hub-release.yml 依次完成以下動作簽發 GitHub App token使用loki-operator-hub-publisher這個專用 GitHub App保證后續以受信任的 bot 身份操作提取版本號從 tagoperator/vX.Y.Z中通過${TAG:10}切片去掉operator/v前綴得到純版本號寫入環境變量同步 fork用gh repo sync grafanabot/$INPUTS_REPO --source org/repo --force先把 grafanabot 名下的 fork 同步到最新避免拉取完整上游倉庫淺克隆會導致 push 報 shallow update not allowed檢出兩個倉庫分別 checkout grafanabot fork 的 operatorhub 倉庫工作目錄與grafana/loki主倉庫tmp/目錄復制 bundle 清單將新版本目錄創建到 operatorhub 倉庫的operators/loki-operator/version/下內容來自./tmp/operator/bundle/community${OCP_DIR}/*mkdir operators/loki-operator/${VERSION} cp -R ./tmp/operator/bundle/community${OCP_DIR}/* operators/loki-operator/${VERSION} rm -f operators/loki-operator/${VERSION}/bundle.Dockerfile注意這里同時做了兩件重要的適配一是按目標渠道選擇community或community-openshift變體二是刪除 bundle.DockerfileOperatorHub 社區目錄不需要它添加 OpenShift 支持版本注解僅 OpenShift 倉庫使用fjogeleit/yaml-update-action在operators/loki-operator/version/metadata/annotations.yaml中寫入annotations[com.redhat.openshift.versions]當前值為v4.12。這正是原文檔所說 Adding the ocp supported version annotation to the metadata.yaml 的實現創建 PR以 grafanabot 身份CLA 已批準新建分支update-loki-operator-to-version提交并gh pr create --repo org/repo --base mainPR 標題為Update the loki-operator to version。防止未更新 manifests 就合并 release-please PR由于第 1 步make bundle-all生成 bundle尚未自動化、與 release-please 相互獨立存在release-please PR 先合并、bundle 后補的時序風險。為此倉庫設置了專門的守衛工作流 .github/workflows/operator-check-prepare-release-commit.yml。該工作流只針對 release-please PR 運行通過兩個條件限定if: | github.event.pull_request.head.ref release-please--branches--main--components--operator contains(github.event.pull_request.title, chore( operator): Community release)其邏輯是先從 PR 標題chore( operator): Community release semver中提取目標版本號再用gh search commits在main分支搜索提交信息為chore(operator): Prepare community release vsemver的提交若找不到則以退出碼 1 使檢查失敗阻止 PR 合并。也就是說人工提交的版本提升 bundle 生成準備提交必須先于 release-please PR 存在。原文檔也指出一旦第 1 步實現自動化這個守衛工作流就可以移除。Releasing一次完整發布的操作清單綜合以上設計一次真實的 Loki Operator 社區發布按以下步驟執行對應原文檔 Releasing 一節創建版本提升 PR先手動提交一次包含版本號提升與 bundle 生成的變更提交信息務必為chore(operator): Prepare community release vversion例如 v0.6.1 的準備工作并合并到main在 release-please PR 上重新觸發operator-publish-operator-hub檢查確保守衛工作流通過合并 release-please PR合并后 release-please 自動創建 release草稿態標題形如chore(operator): Community release vversion鏡像發布publishImagesjob 構建多架構鏡像并推送到 GAR隨后由gar-image-mirror同步到 Docker Hub 的docker.io/grafana/loki-operatorOperatorHub PR 自動創建operator-publish-operator-hubworkflow 檢測到operator/前綴的正式 release 后自動向k8s-operatorhub/community-operators與redhat-openshift-ecosystem/community-operators-prod兩個倉庫各開一個包含新版本 bundle 的 PR。全鏈路小結把整條發布流水線串起來看Loki Operator 的發布由四類 GitHub Actions 工作流協同完成工作流觸發時機職責operator-release-please.ymloperator/**合并到main生成 CHANGELOG、創建草稿 release、調度鏡像構建與正式發布operator-reusable-image-build.yml被 release workflow 調用多架構構建并推送 Operator 鏡像到 GAR / quay.iooperator-check-prepare-release-commit.ymlrelease-please PR 上校驗 Prepare community release 準備提交已存在operator-publish-operator-hub.ymltag 以operator/開頭的 release 發布觸發向兩個 OperatorHub 社區倉庫的上架 PR其中唯一的人工環節是第 1 步更新 operator/Makefile 中的VERSION并執行make bundle-all重新生成 operator/bundle/ 下的清單隨后以約定的提交信息合入main。其余版本號計算、CHANGELOG 生成、release 創建、鏡像發布與 OperatorHub 上架全部由自動化流水線接管既保證了與 Loki 主項目發布記錄的清晰隔離operator/tag 前綴 draft --latestfalse也保證了每次上架內容的規范性與可追溯性。【免費下載鏈接】lokiLike Prometheus, but for logs.項目地址: https://gitcode.com/GitHub_Trending/lok/loki創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考