jx boot should not mutate files on disk if the user doesn't change anything explicitly

[pmuir]

Summary

You can summarise this as "jx boot should be idempotent" - run it again and again with the same config and there should be no change to the cluster or to the git repo.

Currently when you run jx boot with an existing parameters.yaml and jx-requirements.yaml there can/will be still be a git diff after running jx boot (which we then push back up). This is not the right behavior for boot the config is supposed to be the requested state and jx boot is supposed to attempt to implement it (think of the Kubernetes model for an analogy).

Note this is different to when the user explicitly makes a change either by editing files or by answering a question. Then it is legitimate to change the git state.

Steps to reproduce the behavior

Run jx boot (or it's pipeline using tekton in non interpreted mode) in an pipeline and see that it does a git push

Expected behavior

If I add a step in the pipeline at the end that run's this target in a Makefile and see the pipeline exit successfully

Verifies that generated code is in sync with implementation

verify-generation-complete: stash generate ## Verify the generated code is up to date
	$(eval CHANGED = $(shell git ls-files --modified --others --exclude-standard))
	@if [ "$(CHANGED)" == "" ]; \
      	then \
      	    echo "No changes"; \
      	else \
      		echo "Changes"; \
      		echo "$(CHANGED)"; \
			git diff; \
      		exit 1; \
      	fi```

[abayer]

cc @garethjevans since I know you're behind some of the git operations going on in boot and friends. =) I'm going to be diving into this next week to try to get a thorough understanding of what we're actually trying to accomplish with regard to updating the local clone, creating/updating the dev env repo, etc...

As mentioned in a slack thread, I have some ideas about the problems specifically with jx-requirements.yaml and jenkins-x.yml - maybe we switch those to jx-requirements.base.yaml and jenkins-x.base.yml in the jenkins-x-boot-config repo, and copy those (if there isn't already a local copy) to jx-requirements.yaml and jenkins-x.yml in the local clone/dev env repo, so that we no longer have any worries with merge conflicts from upstream. We could then try to handle "merging" jx-requirements.yaml/jenkins-x.yml in upgrade scenarios by using something like mergo to reconcile the jx-requirements.base.yaml/jenkins-x.base.yml from the upgrade upstream with the existing jx-requirements.yaml/jenkins-x.yml, rather than leaving that to git to resolve. Since the actual files would only have history in the dev env repo, we don't need to worry about merge conflicts with them.

[deanesmith]

Dependent on @abayer discovery to identify and propose solutions to address related issues.

[jenkins-x-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale

[jenkins-x-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale

[jenkins-x-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten

[jenkins-x-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close

[jenkins-x-bot]

@jenkins-x-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository.