-
Notifications
You must be signed in to change notification settings - Fork 1.1k
https protocol for git support #2280
Comments
There is redundant code if you want to use I suppose fluxd might expect/create the key depending on the scheme of the git URL. Is that the sort of thing you had in mind? |
@squaremo Yup putting https:// works, I am more concerned about redundant code and bits and pieces which are being used for setting up and acting , if ssh:// was specified. It's just not neat and a bit misleading. I could try to make a pull request to address the redundant code, if you don't mind |
@vyckou Sure, that would be welcome! One catch I can think of is that we generally do want to create a key if the git URL isn't given. The reason is to do with bootstrapping: in Weave Cloud, for example, the daemon is started with no arguments, then the SSH key obtained for the user to install in their repo; this way, the daemon is will start syncing as soon as it's given the URL to the repo, rather than requiring another step. Another is that the read-only git feature (#1741) needs the k8s secret resource, to store its high water mark; so either that needs to be adapted, or we live with always having a secret, even if its empty. |
+1 to have this included. |
Anyway to use it already? / ETA for new release? :) |
For now, flux does support HTTPS protocol for gitops repository only partially. There are lots of code and functionality, which would not be required to execute, if git-url would be https:// and not ssh://
As you are using git CLI client and invoking git commands to deal with gitops repo, passing url https://apikey@github.com/org/repo.git works, but everything which is linked about SSH keypairs are not required and adds additional overhead for the setup and runtime
If using HTTPS protocol instead of SSH would not require:
On the git SCM side, that would bring pluses as:
this behaviour would enable to run flux in Openshift environments without granting flux a priv mode. - creation of the dockerfile with USER directive is not working, as often hardened Openshift setups expects userid with custom ranges.
The text was updated successfully, but these errors were encountered: