Mea culpa!

[hiran]

I configured the Github workflow that builds our nice nightly releases to give them distinct names so we can host more than just one in parallel.
Then I figured out that the cleanup step I introduced would never get active since the if condition was written the wrong way.
https://github.com/OoliteProject/oolite ... l.yml#L275

Obviously I corrected that mistake, which triggered the next build as planned. But then something happened that I did not foresee. Here is a screenshot of the log output:



Despite the cleanup step to be configured for removing old prereleases, it decided to delete releases. I do not understand why it did, and I can no longer find ouy why it did so since these builds are no longer available. They are deleted.

1) I deactivated the build step again. No more deletions will be carried out
2) I will need help restoring these versions
3) I will need help to understand why some of the versions still seem to be online. Were they deleted or were they not? How come only some are missing?

This definitely needs to be clarified before I'd activate automatic deletions again.
I am sorry for the inconvenience and happy for any support.

[hiran]

To be a bit more precise:

- 1.77.1 was deleted, but it is still on Github
- 1.80 was deleted, but it is still on Github
- 1.80a was deleted, and I cannot find it on Gibhub

[Mauiby de Fug]

Slight correction:
1.77.1 was deleted and is no longer on GitHub
1.77.1a is still there and can be downloaded from GitHub
1.80 was deleted and is no longer on GitHub
1.80a was deleted and is no longer on GitHub
1.80b is still there and can be downloaded from Github

Looking at the oolite tags using the wayback machine shows that those that were deleted had, at the time of recording, the pre-release tag, which is not present on the others. And makes sense, since they were superseded by the later versions a and or b. If this was still the case, then arguably the workflow did what it was supposed to, and deleted the oldest pre-releases. Whether they were meant to be tagged as pre-release and kept is a different question.

Full restoration if desired would be tricky. There is a tag corresponding to the commit, so it should be possible to checkout at that commit and then run our build process to re-generate the limited number of builds we currently make. Which could potentially be uploaded somewhere. I've never played around with releases on GitHub so I don't know how much can be done, but the GitHub documentation implies that they are editable. However, some of the other builds, the Mac ones especially, could be lost.

The question is whether this is worth doing, since we still have the most recent examples tagged of each version number.

Possible recommendation: before playing around with the next iteration of adding/deleting releases, it might be an idea for someone to download all the previously stored release artifacts as a backup in case something goes wrong.

[hiran]

Slight correction:
1.77.1 was deleted and is no longer on GitHub
1.77.1a is still there and can be downloaded from GitHub
1.80 was deleted and is no longer on GitHub
1.80a was deleted and is no longer on GitHub
1.80b is still there and can be downloaded from Github

Looking at the oolite tags using the wayback machine shows that those that were deleted had, at the time of recording, the pre-release tag, which is not present on the others. And makes sense, since they were superseded by the later versions a and or b. If this was still the case, then arguably the workflow did what it was supposed to, and deleted the oldest pre-releases. Whether they were meant to be tagged as pre-release and kept is a different question.

Thank you for that analysis. It may mean we did not really loose important builds.

Possible recommendation: before playing around with the next iteration of adding/deleting releases, it might be an idea for someone to download all the previously stored release artifacts as a backup in case something goes wrong.

I like that procedure. It is easy to implement and really allows to restore if something else gets lost.

[phkb]

Can anything be recovered from here?
https://sourceforge.net/projects/oolite.mirror/
https://sourceforge.net/projects/oolite ... ios/files/

[hiran]

https://sourceforge.net/projects/oolite.mirror/

That link offers 1.82, 1.84, 1.86, 1.88 and 1.90 - none of which were deleted.

https://sourceforge.net/projects/oolite ... ios/files/

That link offers 1.77.1 and previous.

So we can use it to restore 1.77.1 - but as Maulby put it: We still have 1.77.1a, so it would be questionable if we want to offer 1.77.1 again.
Restoring prereleases would make absolutely no sense. Otherwise the whole idea of automatic cleanups would be broken.

[hiran]

As I learned we did not have loss of our beloved releases. But I also noticed it may have been close.

Therefore - before activating it again - I'll build some script that can backup all releases and their attachements.

[hiran]

I built the script that downloads a project's releases and their assets and ran it to have a backup.
Then I activated the cleanup step again, and it only removed the intended parts.

So we are good now, and in future the amount of prereleases will not spill over.

[another_commander]

Who is cube?

[hiran]

Who is cube?

It could have been anyone.

Code: Select all

git config --global user.name "Mona Lisa"

[phkb]

Yep. Anyone.



Well, that's now squared away!

[another_commander]

OK cool, for a moment I thought we had an unauthorized repo access. Carry on.

[Cholmondely]

Just stumbled across this: Github: Backup the Berlios

Oolite was on Berlios before moving to GitHub

[hiran]

Just stumbled across this: Github: Backup the Berlios

Oolite was on Berlios before moving to GitHub

That project has 5000+ repositories!