Bintray storage quota - Clean up older AppImage

• Mar 22, 2016 - 07:21
Reported version
2.1
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Just got an email from Bintray that we are over our quota.
We need to remove old AppImages.

@shoogle? Would you take a look?


Comments

Let's store the last 30 AppImage per arch+version on bintray. If we could make a it a variable, so we can adjust if necessary, that would be perfect.

Like I said in irc, I can't figure out any easy way using the bintray api to be able to store only the last N AppImages. I imagine first querying bintray via api to see list previously uploaded, then figuring out oldest one, then telling bintray to delete that one. But such a bash script seems unnecessarily complicated. Maybe shoogle knows a better way to do that, so I'll let him figure that out.

Quoting bintray email communication...
"Your current storage quota is 12.5GB, so as long as you are kept within the storage limits you should be fine.
While it is permitted, keeping the integration versions of nightly builds is not the intended behaviour of Bintray but to store and share release versions."

So in the end I wonder... Maybe a solution is to

1/ Move our nightlies for mac, windows and linux on OSUOSL. I didn't want to do that because I didn't want to share the same credentials for nightlies and releases for security reason.

2/ To solve the above, move our release artefacts on bintray. We would get nice stats that we don't have on osuosl currently. Bintray looks solid. We might want to check further on their history so we can be reassure that they don't turn the sourceforge way... We could also asked for another share on OSUOSL for nightlies.

Accessing OSUOSL is via SFTP, it's relatively easy to do rolling listings.

well sounds like should just use bintray for releases, and use OSUOSL for nighties.

I can't understand what you mean in (2): "move our release artefacts on bintray".

I was also going to say for archiving older builds, we don't need to store the entire app image, but just the executable binary mscore. The app image stuff is really only for convenineence for new downloaders. But for devs that already have the dependencies downloaded, we just need to archive the binary mscore. Then don't need to worry about wasting OSUOSL's storage capacity, and can still keep a mscore binary of every commit.

(The only use of archiving binaries is for easily tracing back which commit caused an error, without having to recompile every commit.)

Thank you for fixing! Now it seems to be working again ...
There now seem to be available again the newest dev-versions.

Both the nightly and stable AppImage packages are available for download again. Now we need to check the translations of /download and if they list the old links to bintray, replace them with the new links.

The consequence of having to change these links for all languages is something which will be tackled with the musescore.org site upgrade. Read more at https://musescore.org/en/node/173731

Status (old) active closed

The script to upload on bintray does clean old versions and we are now storing nightlies on OSUOSL to please bintray since it's not supposed to be used like this but just for stable versions. Stable versions are now also pushed to OSUOSL anyway. I close this issue.