flux push command

[chanwit]

WARNING: This is the proposal from the Dev's perspective, not the Ops-ish way of thinking. Please thinking of that a user who'd love to use this command is junior Devs, who'd like to use GitOps in their development workflow. Thinking of this feature from an experienced Ops perspective would seeing it very differently ;-)

This issue propose a new command called flux push.

Q: Why flux push would give a good UX for developers?
A: cf push was a nice example. flux push represents a behavioral semantic that after I push, I'd get something running inside my K8s right away. And this feature tends to make the behavior synchronous as much as possible.

It integrates the concept of git push and flux reconcile together to make developers to adopt Flux for their development workflow.

0. the CLI checks whether the current repo is dirty or not, if the repo is dirty, the CLI exits with an error code
1. the CLI detects the current branch and remote
2. the CLI then performs the git push operation
3. If the git push operation error == 0, the CLI obtains the last git commit from head.
4. the CLI then performs the flux reconcile operation to make sure that the current revision of Flux objects matches not only the remote repo's HEAD but also the local repo's HEAD.

[hiddeco]

Couple of thoughts on this:

1. This behaviour is already possible by configuring a Receiver for the GitRepository resource(s), without introducing a new command. This does not provide feedback to the user in the console, but can be combined with an Alert to receive direct feedback in e.g. Slack.
2. Multiple GitRepository resources in multiple namespaces can exist with the same branch and remote, and if there are many of them, this command will take a long time.
3. I am not sure what percentage of users does a push to a repository and branch that is synchronized in some cluster, I think most users work via pull requests.
4. I think that having to commit with git and push with flux is not very UX friendly, it would also open the door for more "git aliases" for flux.

[chanwit]

1. Nop. For a junior dev's perspective and day 1 with GitOps / Flux, s/he mostly understands NOTHING around GitOps and Flux. Adding extra concepts the the junior devs may make them turn away from Flux / GitOps, or have bad impression about the GitOps concept.

[chanwit]

2. Yes, I can agree on this. If GitRepository objects > 1, we could tell that your have many GitRepository objects, syncing all of them would take a while. But a day-1 junior dev would have only 1 GitRepository defined as s/he just has been following a Flux tutorial, for example.

[chanwit]

3. For the beginners + Devs, I'm quite confident that they just want to use this command rather than doing GitOps via a PR. Later, after they learn about the concepts of GitOps, yes - they'll do things the way you suggested.

[chanwit]

4. I answered this above in the proposal body. Copy and paste here.

Q: Why flux push would give a good UX for developers?
A: cf push was a nice example. flux push represents a behavioral semantic that after I push, I'd get something running inside my K8s right away. And this feature tends to make the behavior synchronous as much as possible.

[hiddeco]

For a junior dev's perspective and day 1 with GitOps / Flux, s/he mostly understands NOTHING around GitOps and Flux. Adding extra concepts the the junior devs may make them turn away from Flux / GitOps, or have bad impression about the GitOps concept.

The concept and combination of Git and webhooks to perform certain actions after you make a commit is nothing new, and I would expect developers to learn this pretty early on.

For the beginners + Devs, I'm quite confident that they just want to use this command rather than doing GitOps via a PR. Later, after they learn about the concepts of GitOps, yes - they'll do things the way you suggested.

That would mean that this command is purely aimed at the junior developer that runs some (temporary?) cluster somewhere and is just learning and/or getting started. I am then of opinion that it is much better to learn them the additional trick of flux reconcile [...], than to teach them an anti-pattern that hides what is really happening in the world.

[squaremo]

I think the underlying idea is that this joins up a flow between committing changes and seeing them reflected in the cluster. That intention is good I think.

But as it's presently described, it has a pretty serious problem: you are very likely not going to be pushing the branch that you are syncing, as Hidde mentioned. Relatedly, what happens when you flux push a branch that doesn't correspond to a sync? There's a disconnect between where you are, and what you might want to happen next, that is not accounted for.

I also don't like flux encroaching on git's territory. You're asking people to retrain their muscle memory, for no especial gain. It would be better to work in sympathy with git, than to replace parts of it.