Use a new populse_mia clone from now on

[servoz]

After a long and difficult battle, we got rid of the old Git LFS objects that we hadn't used for a very long time but which remained on the Git LFS server, with no possibility for users to delete them ... when we have a free account like us.

To do this, we had to delete the repository from GitHub, then recreate it, put the issues back (I've only kept the open issues, the others are gone), and so on.

We now have a storage quota close to 0 for Git LFS on Populse.

But for the moment and while waiting for the Git LFS bandwidth reset it is no longer possible to download objects from Git LFS. Indeed, we're currently waiting for the monthly reset which should take place in 12 days as we have reached the maximum authorised bandwidth and can therefore no longer download objects tracked by Git LFS

So while waiting for the next bandwidth reset, use the following command to clone populse_mia:
GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/populse/populse_mia.git

Mia works perfectly well without the Git LFS objects. It just won't have the .png decorations, like the image to launch a pipeline, etc.. But as there are often several ways of doing things in Mia, a workaround will normally be found until the Git LFS bandwidth is reset (for example to run a pipeline use Pipeline> Run pipeline). In a fortnight, we will be able to use the git clone again as usual. Normally, we shouldn't have any more problems with Git LFS quotas, as their use has been optimised (for example, unit tests will no longer be cloned with Git FLS, etc.).

[servoz]

That's also why you've been getting alerts about old discussions.

It's just because I've put them back into the issue section with the GitHub API ... It's just that it had the unintended benefit of reigniting discussions on topics that are still unresolved, even though they're important!

[sapetnioc]

Good work. I would have bet that it is not complicated to erase things from history. This would had been a mistake.

Having a monthly limit of data exchange on git LFS seems a big problem to me since we have no control on who is downloading the project. The more users we have, the more likely we will reach the limit. I do not know if there are robots that download projects for statistics, etc. but we would like to be able to forbid that to save bandwidth.

[servoz]

It is indeed very complicated to delete data tracked by git LFS because even if we delete everything from the history (which I naively thought and did at first it does not delete the objects on the Git LFS server)!

The only solution is to completely delete the GitHub repository and reinstall it from scratch with the right files to track (which necessarily implies the loss of GitHub metadata) or to ask GitHub support to do it ... Except that for this second case we quickly notice that it is only possible if we have a paid GitHub account ... People with bad intentions could say that it is a commercial plan ...

I spent several days struggling to understand what was possible to do in our case (free account) because things are quite obscure (another business plan?). I actually looked for how to configure GitHub to be able to pull only a repository without the Git LFS objects but unless I missed something it is not possible. It seems that to pull a clone without the Git LFS objects we have to configure the pull locally... The only solution I found and implemented is to limit as much as possible the objects tracked by git LFS (we only have a few MB now) and not to pull the Git LFS objects in the unit tests (it is possible because you can configure the build during the UTs to not do it).

I agree with you it is a problem because we can ask users in the documentation to configure locally not to pull Git LFS objects but we can't force them and for robots it's the same.

What I can say is that now things are optimized in such a way that to exceed the bandwidth, we would really have to pull a lot to reach the monthly quota... The only solution would be to switch to a paid solution... I always wondered when Microsoft's business model would appear...

[servoz]

we now have exactly:

• 1.47 MB for populse_mia
• 739 KB for mia_processes

So it's not perfect, but we'd need about 1,000 pulls a month to reach our bandwidth quota. I think that when we have an audience like that, we'll be very proud and we might have to think about getting a paid GitHub account...

[servoz]

The bandwidth for Git LFS has been reset. We can now clone populse repositories as usual with git clone.

I'll keep a close eye on bandwidth on populse_mia.

According to GitHub support, one option would be to make the populse project private.

Personally, I'm not in favour of this. But as @sapetnioc pointed out, if we run into quota issues again, we'll have to find a solution. To be continued ...