gitLib is_dirty_worktree

@nrdxp

Lines 3 to 7 in 874fb8c

    
           function is_git_repository { 
        
             local path="${1}" 
        
             git -C "${path}" rev-parse 2> /dev/null 
        
           }

Complement with an is_dirty_worktree

I figured in some situations one might want to ensure that things are run on a clean dir.

One such use case is:

function ensure_clean_workdir {
  if test -n "$(git status --short)"; then
    critical Please witness deployment from a clean workdir. \
      Commit your local changes first.
  fi
}

(a witness of a deployed state, but this can be moved up the chain and only allow deploys on clean git workdirs in the first place)

/cc @nrdxp

@blaggacao

@blaggacao what about gitignored files ? should they be considered part of the dirty state? git status does not take them into account, but if they exists, they will cause NAR serializations drift on nix-stable

should we consider a clean worktree one that is: git reset --hard COMMIT && git clean -dffx ?
the above is exactly equal as cloning the repository from scratch and checking out a given commit

I'd say that if a gitops engineer deploys any state off of a gitignore file, that engineer is very deliberately shooting himself in the foot (or doesn't know better).

I currently don't think we need to prevent that type of self harm if minimum gitops ethics is a given.

The issue here is rather deploying an uncommitted change by mistake (and thereby loosing auditability).

Understood,

my concern was more purity and security. I heard of someone once deploying a file with plain text secrets to a public docker container image. The file was gitignored so that person was not aware of its existence. Other story is, python automatically writes __pycache__ folders when executed, which are also gitignored, and they cause ./path/to/folder hashes to change on Nix stable. Since those folders are "invisible", people normally have bad times debugging why the hash changes

If you use the unstable path, Nix itself already warns you of a dirty worktree, so doing this in makes may become redundant. Then again you can choose to turn that warning off in Nix.

I heard of someone once deploying a file with plain text secrets to a public docker container image. The file was gitignored so that person was not aware of its existence.

Oh yeah, I can see that happen. Let's ignore it for is_dirty_worktree, I'd say. Here is why:

Here we want to hint a user at: "please commit your changes before proceeding"
The other use case, that you bring up is: "do whatever will be done on a pristine checkout"
These use cases are slightly different, though often one could wrap the former into the latter. But I can see cases where you genuinely want to say: "please remember to commit your changes first".
Let's rename to has_uncommitted_changes, that's less of a misnomer, then.

If you use the unstable path, Nix itself already warns you of a dirty worktree, so doing this in makes may become redundant. Then again you can choose to turn that warning off in Nix.

My main used case here is to make a hard stop sign for a run-book and don't let the user get past that point during the control flow of an interactive script.

Navigation Menu

Repository navigation

gitLib `is_dirty_worktree` #654

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	function is_git_repository {
	local path="${1}"

	git -C "${path}" rev-parse 2> /dev/null
	}

gitLib is_dirty_worktree #654

Description

Activity

kamadorueda commented on Sep 30, 2021

blaggacao commented on Sep 30, 2021

kamadorueda commented on Sep 30, 2021

nrdxp commented on Sep 30, 2021

blaggacao commented on Oct 1, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

gitLib `is_dirty_worktree` #654