Change Details

~~We run a custom git-fat package, which is in standard packages and deployed on every host. It's written in Python 2, which is EOL. Py3 support isn't completed upstream: https://github.com/jedbrown/git-fat/issues/92, so we could also collaborate with them if we want to continue to use git-fat.~~ We need to stop using git-fat. It's antiquated, based on Python2, and there's better ways to do this. Mostly, this means using git-lfs, but it may also mean just not using large object storage in-tree at all, or just saying screw it the blobs aren't so big. Subtasks for each usage we have. ---- Some caution, #scap does not properly support `git-lfs`. On the scap targets the local git repository cache has a remote set to the deployment server which does not offer LFS objects (T324664). Thus one has to add a `.lfsconfig` in the deployed repository in order for the scap target to fetch from the LFS server. Example with a Gitlab source repository: https://gitlab.wikimedia.org/repos/releng/jenkins-deploy/-/blob/master/.lfsconfig ``` name=.lfsconfig,lang=ini [lfs] url = https://gitlab.wikimedia.org/repos/releng/jenkins-deploy.git/info/lfs pushurl = git@gitlab.wikimedia.org:repos/releng/jenkins-deploy.git ``` With a Gerrit source repository: ``` name=.lfsconfig,lang=ini [lfs] url = https://gerrit.wikimedia.org/r/operations/software/gerrit.git/info/lfs pushurl = ssh://gerrit.wikimedia.org:29418/operations/software/gerrit.git ``` The `scap deploy-local` on the deployment target will fetch from the canonical LFS server (respectively Gitlab and Gerrit in the above examples).

~~We run a custom git-fat package, which is in standard packages and deployed on every host. It's written in Python 2, which is EOL. Py3 support isn't completed upstream: https://github.com/jedbrown/git-fat/issues/92, so we could also collaborate with them if we want to continue to use git-fat.~~ We need to stop using git-fat. It's antiquated, based on Python2, and there's better ways to do this. Mostly, this means using git-lfs, but it may also mean just not using large object storage in-tree at all, or just saying screw it the blobs aren't so big. Subtasks for each usage we have.

~~We run a custom git-fat package, which is in standard packages and deployed on every host. It's written in Python 2, which is EOL. Py3 support isn't completed upstream: https://github.com/jedbrown/git-fat/issues/92, so we could also collaborate with them if we want to continue to use git-fat.~~ We need to stop using git-fat. It's antiquated, based on Python2, and there's better ways to do this. Mostly, this means using git-lfs, but it may also mean just not using large object storage in-tree at all, or just saying screw it the blobs aren't so big. Subtasks for each usage we have. ---- Some caution, #scap does not properly support `git-lfs`. On the scap targets the local git repository cache has a remote set to the deployment server which does not offer LFS objects (T324664). Thus one has to add a `.lfsconfig` in the deployed repository in order for the scap target to fetch from the LFS server. Example with a Gitlab source repository: https://gitlab.wikimedia.org/repos/releng/jenkins-deploy/-/blob/master/.lfsconfig ``` name=.lfsconfig,lang=ini [lfs] url = https://gitlab.wikimedia.org/repos/releng/jenkins-deploy.git/info/lfs pushurl = git@gitlab.wikimedia.org:repos/releng/jenkins-deploy.git ``` With a Gerrit source repository: ``` name=.lfsconfig,lang=ini [lfs] url = https://gerrit.wikimedia.org/r/operations/software/gerrit.git/info/lfs pushurl = ssh://gerrit.wikimedia.org:29418/operations/software/gerrit.git ``` The `scap deploy-local` on the deployment target will fetch from the canonical LFS server (respectively Gitlab and Gerrit in the above examples).