flux2
flux2 copied to clipboard
Clarification needed in documention how read-only Git repos work
Describe the bug
The background:
I want to setup Flux v2 with a GitLab repo that has a protected branch and the project access token used has no permissions to push to the repo.
The flux bootstrap
stops because it cannot write to the branch.
However, when I follow https://fluxcd.io/docs/migration/flux-v1-migration/#flux-read-only-mode I could set it up successfully with flux install
, flux create source git
, flux create ks
What is the difference between these two installation methods? How do the generated artifacts differ?
What are the downsides of using the Git repo in read-only mode?
Why is this only described for migration of Flux v1?
What I want to achieve: I want the Flux agent connected to a GitLab branch and the only way to get something updated should be to do a merge request.
Steps to reproduce
N/A
Expected behavior
N/A
Screenshots and recordings
No response
OS / Distro
N/A
Flux version
N/A
Flux check
N/A
Git provider
No response
Container Registry provider
No response
Additional context
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
The
flux bootstrap
stops because it cannot write to the branch.
However, when I follow https://fluxcd.io/docs/migration/flux-v1-migration/#flux-read-only-mode I could set it up successfully with
flux install
,flux create source git
,flux create ks
The flux bootstrap
process stops because the command itself attempts to write the the Git repository (as it takes care of the full bootstrap process). The other commands you used do not, but rather create the resource on the cluster (or the YAML using --export
) to source the resources from Git and apply them to the cluster, which does not attempt to write to the Git repository.
What is the difference between these two installation methods? How do the generated artifacts differ?
There is no difference between the generated artifacts, there is a difference in process.
What are the downsides of using the Git repo in read-only mode?
There are no direct downsides, except that image automation is not possible without a key that has write permissions to the repository. Also note that it is not required to write directly to the same branch as that is being applied to the cluster: https://fluxcd.io/docs/components/image/imageupdateautomations/#push
Why is this only described for migration of Flux v1?
Flux v1 had a "read-only mode", while in Flux v2 the Git repository is read-only by default unless image automation is enabled, which is driven through a separate object.
What I want to achieve: I want the Flux agent connected to a GitLab branch and the only way to get something updated should be to do a merge request.
No custom setup should be required, unless you want to automate image updates, in which case you can push the updates to a separate branch. See link shared above.
Yeah, that is the information missing in the documentation.
It should read this way:
If you have write acces to the branch do this. Else do that.
Probably this helps, apparently the key is readonly by default https://github.com/fluxcd/flux2/discussions/1819
Maybe this note can help. It describes bootstrapping on the repository with main
branch protected.
@guidoffm is this task still open?