Conversation
gh-pages is being retired as part of the CAAPIM->Broadcom / GH Actions-> Jenkins migration. The chart-publish pipeline (push charts to Artifactory as OCI artifacts) currently lives only on the gh-pages branch, so it needs a permanent home before that branch is deleted. Pure relocation, byte-identical to origin/gh-pages:Jenkinsfile and origin/gh-pages:push_helm_charts.py - no logic changes yet. Adapting this to build the chart from the workspace instead of downloading a GitHub Release asset is a separate, later step. Still needed (outside this repo, not part of this commit): - Re-point the internal Jenkins job that currently reads Jenkinsfile from gh-pages to read Jenkinsfile-charts from this branch instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Wires the existing, already-working layer7-operator-test-automation
pipeline (job L7Operator/Components/L7Operator Test Automation/develop)
into PR builds, gating merge status on its result.
- Runs only on PR builds (env.CHANGE_ID) - a full regression run takes
~15min and spins up a kind cluster, not worth it on every branch push.
- Passes OPERATOR_REF=env.CHANGE_BRANCH so the harness tests the PR's
actual proposed source, not just whatever main/develop already is.
- No separate chart-lint stage added here: layer7-operator-test-automation's
own "Lint & scan" stage already runs `ct lint` (blocking when charts
changed) plus warn-only golangci-lint/govulncheck - confirmed via a real
console log (job Operator_Test_Automation_develop, 2026-08-27 run,
passed=226 failed=0). Adding another lint stage here would duplicate it.
- Relies on `build job:`'s default propagate:true: if the downstream run
doesn't succeed, this stage throws and this build fails too, which the
existing post{failure{pullRequest.createStatus(...)}} block already
reports back to GitHub - no new status-reporting mechanism needed.
- Left an explicit NOTE in the stage: this passes OPERATOR_REF only, so
the harness rebuilds the operator image from source independently
rather than consuming the image the "Build and Push Image" stage above
just pushed. layer7-operator-test-automation's own PLAN.md already
tracks that gap as a planned, opt-in USE_UPSTREAM_BUILD mode (default
off) - revisit this call once that lands, to avoid the double build.
Still needed (Jenkins job config, not a repo commit - tracked in the
migration plan): add a real GitHub-webhook PR trigger to the Build
L7Operator multibranch job for develop/main, since it currently only
builds on branch-indexing/daily cron rather than firing live on PRs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… (Phase 2b) push_helm_charts.py no longer downloads a pre-built chart tarball from a GitHub Release (that source disappears once GH Actions/Releases are removed) - it now `helm package`s charts/layer7-operator directly from the checked-out workspace, then pushes the result as before. Dropped the now-unneeded GitHub API download path (requests/ruamel.yaml, GITHUB_TOKEN) entirely, and the --index argument that went with it. Also fixed a pre-existing bug: the old script called sys.exit(...) without importing sys. Jenkinsfile-charts is now branch-aware instead of hardcoding --release: - PR branches -> dev-local only (usw1 Artifactory already blocks promoting dev-local to layer7.packages.broadcom.com, so there's nothing further to do for a PR build). - main -> release-local (a separate, not-yet-built workflow will later promote this to layer7.packages.broadcom.com - Phase 2c). - any other branch -> skipped. Also dropped the GITHUB_CREDS/GITHUB_TOKEN env and the `pip3 install requests ruamel.yaml` step, both unused now. Still needed (Jenkins job config, not a repo commit - tracked in the migration plan): convert helm-github-to-release-operator from a standalone job into a multibranch job, so env.CHANGE_ID/BRANCH_NAME are actually populated per PR/branch the way this script now expects. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…follow-up) chart-releaser-action (the old GH Actions flow) only ever created a new GitHub Release - and thus only ever gave the gh-pages job something new to publish - when Chart.yaml's version had actually changed since the last release. The Jenkinsfile-charts rewrite in the previous commit lost that: it would unconditionally `helm package` + `helm push` on every run, regardless of whether the chart changed at all, risking a failed or duplicate push of an already-published version. push_helm_charts.py now gates on two checks: - --check-changed TARGET_BRANCH (optional): a cheap `ct list-changed` short-circuit for PR builds, skipping entirely if the chart directory isn't in the changed list vs TARGET_BRANCH. Deliberately NOT used for the release path - `ct list-changed --target-branch main` run while already on main always reports no changes, so it would be actively wrong there. - version_exists(): before packaging, checks whether the chart's current Chart.yaml version already exists in the target Artifactory OCI repo (`helm pull ... --version <version>`) and skips if so. This is the closer equivalent of chart-releaser's own "don't recreate an existing release" behavior, and applies to both the PR and release paths. Also wrapped login-through-logout in try/finally so a failed push no longer leaves the agent logged in (a latent issue in the original script, which called docker logout sequentially after push with no error handling). Jenkinsfile-charts: PR builds now pass --check-changed main; main builds rely solely on the version_exists() check (see above for why --check-changed doesn't apply there). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Comments should describe the current system on its own terms, not reference internal migration-plan phase labels or chart-releaser (the GH-Actions-era tool this pipeline replaces, which won't exist by the time anyone reads this comment again). That context belongs in commit messages, not baked into the code. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kk640244
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Part of the CAAPIM -> Broadcom / GitHub Actions -> Jenkins CI migration.
GitHub Actions and GitHub Pages won't be supported once this repo moves to
the
broadcomorg, so this is the layer7-operator half of building out anequivalent Jenkins-based pipeline before that org move happens - the
transfer itself is the last step of the overall migration, done once
everything here is proven.
This PR is untested against a live Jenkins run. It's ready for review
on content/approach, but the Jenkins job config changes listed at the
bottom still need doing before any of this actually executes for real.
What changed and why
Relocate the chart-publish pipeline off
gh-pages.Jenkinsfile+push_helm_charts.py(the pipeline behind the existinghelm-github-to-release-operatorjob) only existed on thegh-pagesbranch.
gh-pagesis scheduled for removal later in this migration, sothese needed a permanent home first - relocated here as
Jenkinsfile-chartspush_helm_charts.pyat the repo root.Wire the existing test-automation harness into PR builds. Added a
Test Automationstage to the rootJenkinsfilethat calls the already-workingL7Operator/Components/L7Operator Test Automation/developJenkins job onevery PR (passing the PR's actual branch as
OPERATOR_REF), and gates thePR's merge status on its result - reusing the existing
pullRequest.createStatuspost-block, no new plumbing. Runs PR-only (notevery branch push) since a full run takes ~15min and spins up a kind
cluster. Left an explicit note in the stage: it currently passes
OPERATOR_REFonly, so the harness rebuilds the operator image from sourceindependently rather than consuming the image this same pipeline's
Build and Push Imagestage just built - a known, deliberately deferred gap(
USE_UPSTREAM_BUILD, already tracked in that harness's ownPLAN.md).Make chart publishing self-sufficient and idempotent.
push_helm_charts.pyused to download an already-built chart tarball froma GitHub Release; GH Releases-for-charts is going away as part of this
migration (chart distribution is moving to an Artifactory OCI registry), so
it now packages the chart directly from the workspace
(
helm package charts/layer7-operator). Also madeJenkinsfile-chartsbranch-aware: PR branches publish to Artifactory's dev-local repo only (usw1
Artifactory blocks promoting dev-local any further, so there's nothing more
to do for a PR build);
mainpublishes to release-local, which a separate,not-yet-built promotion job will later push on to the public distribution
point. Added gating (
ct list-changedshort-circuit for PRs + anArtifactory version-existence check for both paths) to replace the
idempotency the old GH-Actions
chart-releasertool used to provide, sothis won't try to republish an already-published version.
Explicitly not included here
portal-devops-util(separate repo), not here.bundle.yaml/cw-bundle.yaml) - see Automate operator release (bundle.yaml/cw-bundle.yaml) on tag builds #106.the eventual org transfer, not part of this migration's critical path.
Jenkins job config changes needed before this takes effect (not repo changes)
helm-github-to-release-operator: repoint from branchgh-pages(fileJenkinsfile) to branchmain(fileJenkinsfile-charts) once thismerges, and convert it from a standalone job to a multibranch job so
env.CHANGE_ID/env.BRANCH_NAMEare actually populated for the newbranch-aware dev-local/release-local logic.
Build L7Operator: add a real GitHub webhook PR trigger fordevelop/main(it currently only builds via daily cron/branch-indexing,so the new Test Automation stage won't fire live on PRs until this is
done).