Issues with git LFS objects

[kommendorkapten]

If a tuf repository contains LFS objects, the signing event action fails.
The action first uses actions/checkout which defaults to not checking out the actual files. Further, a git clone is executed by the action, eg, during update_targets:

tuf-on-ci/repo/tuf_on_ci/signing_event.py

Line 182 in 68ee75b

_git(["clone", "--quiet", ".", known_good_dir])

This doesn't fail the action's step, but shows up in the log with a non-informative error:

  File "/opt/hostedtoolcache/Python/3.11.11/x64/lib/python3.11/site-packages/tuf_on_ci/signing_event.py", line 29, in _git
    proc = subprocess.run(cmd, check=True, capture_output=True, text=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.11.11/x64/lib/python3.11/subprocess.py", line 571, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['git', '-c', 'user.name=TUF-on-CI', '-c', 'user.email=41898282+github-actions[bot]@users.noreply.github.com', 'clone', '--quiet', '.', '/tmp/tmpwpo77zk9']' returned non-zero exit status 128.

After some debugging I found out that the git LFS objects was the issue:

Error downloading object: 
<path to a file> (5a81c1c): Smudge error: Error downloading <path to a file> (...8c1ed4e3ec27a2d6...): error transferring "...8c1ed4e3ec27a2d6...": [0] remote missing object ...8c1ed4e3ec27a2d6...

Errors logged to '/tmp/tmp7ct3uf39fsn/.git/lfs/logs/20250318T100126.575129339.log'.
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: <path to a file>: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.

The solution for this case was to disable LFS smudge on the workflow level by configuring

env:
  GIT_LFS_SKIP_SMUDGE: 1

It's not a straight path forward on how to fix this, we could update the templates to set this, and document that for users relying on LFS objects that the feature is not currently working. I have not tested running actions/checkout with lfs: true to see if that makes the issue go away as we are not currently relying on the LFS objects for the TUF repo itself.