Add workflow to generate file containing release information for applets

[Gr3q]

Description

These scripts will create/update the releases.json inside .releases folder on every commit to master.

Documents every change for every currently released applet in json format, including:

• applet id
• path to files folder in repo
• versions array, including
  • version string pulled from metadata (in there is no version it's changed to 0.0.0)
  • commit hash
  • commit message
  • ISO timestamp
  • applet folder's git sha1 checksum
  • download url for the repo's snapshot for the commit (best I can do with github, unless you have subversion, then you can use svn checkout -r{hash} https://github.com/linuxmint/cinnamon-spices-applets/{appletname}/files/, but it might be slow)

It also appends a -{revision} to a released version if the version number was not changed but the code was to reliably track versions.

Reasoning

• Full release history can be accessed by more tools
• It might be easier to handle caching for the website and the applet/etc updater (Take this with a grain of salt because I have no idea of the currently implemented logic)
• I also thought about generating releases in this repo when this is ran (with the zipped subfolder of the applet), which is definitely can be done with github actions.
• It might be easier (for someone...) to implement rollback functionality - I know applets and extensions should just work and bugs should never happen, but still.

@NikoKrause if you think this is not useful for you guys in any way then I can keep this code elsewhere and close this, otherwise please review.

Gotchas

• Only processes applets present in the repo with the latest commit, meaning deleted applets will disappear from the generated output.
• In the future if we want to compare the old generated output and the new one, If master is getting commits in quick succession release_generator might produce a race condition with each other if not run sequentially (this is untested). As said it is currently not used in this way.

Example output (part of)

{
    "AutostartPrograms@spacy01": {
        "id": "AutostartPrograms@spacy01",
        "path": "AutostartPrograms@spacy01/files/AutostartPrograms@spacy01",
        "versions": [
            {
                "version": "0.0.0-1",
                "commit": "ba0627d3",
                "message": "Initial commit",
                "date": "2016-12-31T14:25:05+00:00",
                "applet_checksum": "740473f8cf878c44481cf4f1fe1d3caed7f6bcc8",
                "url": "https://github.com/linuxmint/cinnamon-spices-applets/archive/ba0627d3.zip"
            },
            {
                "version": "0.0.0-2",
                "commit": "fd105009",
                "message": "Create bg.po",
                "date": "2017-04-24T20:11:06+03:00",
                "applet_checksum": "afb893fc6691e479d041b9ccf73c3c703cd4f410",
                "url": "https://github.com/linuxmint/cinnamon-spices-applets/archive/fd105009.zip"
            },

[rcalixte]

Should this have one user's credentials hard-coded?

[Gr3q]

It's been a long time, but I think I copied it from the workflow to generate the translation tables.

I'm not sure what I should be using, if it were on me I would use a generic CI account

[rcalixte]

I'm going to take a shot at adding some workflows in a few weeks that will work on a similar basis. Let's see what we can come up with that is a cleaner design.