[eas-cli] Skip makeShallowCopyAsync if requireCommit

[sjchmiela]

Why

requireCommit: true setups expect worktree to be clean (e.g. encrypted files to be locked).

How

Made it so if requireCommit is true we don't copy files over.

Test Plan

I have enabled git-crypt in my test repository, added a secret file, ran easd build:inspect -p android -s archive -o ~/test-production --force. The clone did contain secret file in plaintext.

Then I enabled requireCommit: true and repeated the command. The clone did contain the file encrypted.

[github-actions]

Size Change: +1.25 kB (0%)

Total Size: 53.4 MB

Filename	Size	Change
./packages/eas-cli/dist/eas-linux-x64.tar.gz	53.4 MB	+1.25 kB (0%)

_{compressed-size-action}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 52.62%. Comparing base (b3d0924) to head (1907f8d).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2885      +/-   ##
==========================================
+ Coverage   52.41%   52.62%   +0.21%     
==========================================
  Files         588      588              
  Lines       23169    23170       +1     
  Branches     4851     4852       +1     
==========================================
+ Hits        12142    12190      +48     
+ Misses      10053    10014      -39     
+ Partials      974      966       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@szdziedzic, @khamilowicz, @radoslawkrzemien

Generated by CodeMention

[szdziedzic]

I'm not sure if I understand. Why should we not do git clone when requireCommit: true is present?

[sjchmiela]

It comes down to secrets and locked / unlocked repository (if using git-crypt).

Looks like requireCommit flag wasn't being used just as a "it's a good practice to always commit your changes", but more like "make tarball look exactly like a cloned repository at this commit would". In the former understanding it's not a big deal if we copy unlocked files to the tarball because the user did make a commit. In the latter understanding requireCommit is more like makeTarballResembleClone or something.

See discussion in here and how it broke Brent's setup with encrypted files (he was using requireCommit: true and was expecting encrypted files to be locked and worktree clean).

[github-actions]

✅ Thank you for adding the changelog entry!