Fix Big Bang example to do GitOps correctly #185
Conversation
…gitops # Conflicts: # examples/big-bang/manifests/other_manifests.yaml
| secretRef: | ||
| name: zarf-git-secret | ||
| ref: | ||
| branch: feature/145-big-bang-core-example-correct-gitops |
There was a problem hiding this comment.
This should change to master right before we merge
|
Proof this works:
|
|
Needs more documentation to be added before we merge also |
|
Is there a reason any of the BB repo need to be private? Since upstream is publicly readable, I would expect no one to have an issue with a publicly readable BB on this repo either. |
|
@runyontr Zarf automatically makes all repos that it loads into Gitea private. If you think it would be valuable we can create a feature request to be able to configure whether repos are public or private. |
|
There's obviously a tradeoff on complexity between making zarf more complex/flexible (public/private repos) vs making the repos needed to build our packages more complex. Just wondering if there were other considerations on that. |
|
I'll write up an issue for the feature request. |
|
@YrrepNoj this is ready for review and merge, other than the one thing to change the branch ref back to |
RothAndrew
changed the title
|
/test all |
|
/test all |
|
@YrrepNoj Where's the nit? I don't see a comment from you. Changing the branch ref and I'll fix your nit, then I'll need one last approve then we can merge |
|
/test all |
RothAndrew
deleted the
feature/145-big-bang-core-example-correct-gitops
branch
Signed-off-by: Jeff McCoy <code@jeffm.us>
Signed-off-by: Jeff McCoy <code@jeffm.us>
Fix the Big Bang Core example to do GitOps properly, by applying a
GitRepositoryandKustomizationmanifest, rather than applying the output ofkustomize buildBecause Flux can't pull from private bases without making modifications to the Flux deployment we decided to vendor the base rather than modify the deployment of flux. The
package-example-big-bangMake target automatically pulls the base from the upstream Big Bang repo. It has a hard coded tag version right now which we should fix in a future issue. Because of this, reviewers should disregard any files that are in thevendorfolder. They need to be included in the repo since the repo is what is pulled into the Zarf package that Flux uses inside the airgap.