Abbiamo già visto con uno script precedente (https://www.dopsitalia.com/script/86/Migrare-Repository-Contiene-Large-File-Storage-Objects-GitHub.aspx) come sia possibile effettuare la migrazione di un repository che contiene large file objects (LFS). Oggi vediamo, invece, come possiamo fare il clone di questi oggetti durante l'esecuzione di un workflow di GitHub.

Sebbene la pratica sia la stessa vista nell'altro script, bisogna prestare attenzione alla quantità di dati che vengono inviati da GitHub al runner (o agent) che eseguirà il workflow. Infatti, LFS lo paghiamo non solo per spazio occupato, ma anche per il traffico che genera in entrata/uscita dal repository.

Per ovviare a questo problema, possiamo sfruttare la cache di GitHub:

steps:
- name: Checkout
  uses: actions/checkout@v3

- name: Create LFS file list
  shell: bash
  run: git lfs ls-files -l | cut -d' ' -f1 | sort > .lfs-assets-id

- name: Restore LFS cache
  uses: actions/cache@v2
  id: lfs-cache
  with:
    path: .git/lfs
    key: ${{ runner.os }}-lfs-${{ hashFiles('.lfs-assets-id') }}-v1

- name: Git LFS Pull
  shell: bash
  run: git lfs pull

Ci sono quattro diversi passaggi in questo workflow. Nel primo, andiamo solo ad effettuare il checkout del repository. Nel secondo, andiamo a creare un file contenente l'elenco degli oggetti LFS presenti nel repository. Nel terzo, andiamo a recuperare la cache di GitHub, se presente (in quanto deve fare match con l'elenco degli oggetti generati precedentemente), e nel quarto, andiamo a recuperare gli oggetti LFS con l'operazione di pull.

Se la cache non è presente, come per la prima esecuzione del workflow, GitHub la creerà automaticamente al termine dello stesso. In questo modo, possiamo evitare di effettuare il pull di tutti gli oggetti LFS tutte le successive volte che verrà eseguito il workflow, risparmiando banda di LFS.