Automate calendar building via GH actions

[beyarkay]

Currently the GH actions scripts aren't automating the builds. There's a bunch of issues from obscure ones to API rate limits.

The deployment should be as follows:

1. A change is pushed to manually_specified.yaml
2. GitHub action starts, checking out the repo, downloading the python packages and rust crates
3. The project is built with cargo run --release, causing ics calendar files to be saved in calendars/
4. The tag latest should be moved to the latest commit.
5. All files under the relase corresponding to the latest tag should be deleted.
6. The ics calendar files from this build must be uploaded to the release corresponding to the latest tag

This should fully automate the updating of the calendar files. The trickery with the latest tag is so that github can maintain one URL (something like https://github.com/beyarkay/eskom-calendar/releases/tag/latest that points to the most recent and up-to-date calendars. This means that users won't have to update their calendar's URL every time there's a change from eskom.

[beyarkay]

Currently struggling with API rate limits:

Updating tag
Updating tag latest to 36c04c7811c147cf2ab87252a4a2e8c00bc93810
(node:5977) UnhandledPromiseRejectionWarning: HttpError: API rate limit exceeded for installation ID 17256562.
    at /home/runner/work/_actions/beyarkay/update-existing-release/master/dist/main.js:2:53922
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:5977) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:5977) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

And another error that's like this Te [HttpError]: Validation Failed: {"resource":"ReleaseAsset","code":"already_exists","field":"name"}:

  Uploading release asset /home/runner/work/eskom-calendar/eskom-calendar/calendars/eastern-cape-portalfred.ics
  Error occurred uploading release asset `/home/runner/work/eskom-calendar/eskom-calendar/calendars/eastern-cape-portalfred.ics` 
to release with release_id: 72030383: 
Te [HttpError]: Validation Failed: {"resource":"ReleaseAsset","code":"already_exists","field":"name"}
      at /home/runner/work/_actions/beyarkay/update-existing-release/master/dist/main.js:2:53922
      at processTicksAndRejections (internal/process/task_queues.js:97:5) {
    status: 422,
    response: {
      url: 'https://uploads.github.com/repos/beyarkay/eskom-calendar/releases/72030383/assets?name=eastern-cape-portalfred.ics&',
      status: 422,
      headers: {
        'cache-control': 'no-cache',
        connection: 'close',
        'content-length': '208',
        'content-security-policy': "default-src 'none'",
        'content-type': 'application/json; charset=utf-8',
        date: 'Fri, 15 Jul 2022 15:51:37 GMT',
        'strict-transport-security': 'max-age=31557600',
        vary: 'Accept-Encoding, Accept, X-Requested-With',
        'x-content-type-options': 'nosniff',
        'x-frame-options': 'deny',
        'x-github-media-type': 'github.v3; format=json',
        'x-github-request-id': '0443:7BA7:166AEB:26DA70:62D18D08',
        'x-xss-protection': '1; mode=block'
      },
      data: {
        message: 'Validation Failed',
        request_id: '0443:7BA7:166AEB:26DA70:62D18D08',
        documentation_url: 'https://docs.github.com/rest',
        errors: [Array]
      }
    },
    request: {
      method: 'POST',
      url: 'https://uploads.github.com/repos/beyarkay/eskom-calendar/releases/72030383/assets?name=eastern-cape-portalfred.ics&',
      headers: {
        accept: 'application/vnd.github.v3+json',
        'user-agent': 'octokit-core.js/3.6.0 Node.js/12.22.7 (linux; x64)',
        'content-type': 'text/calendar',
        'content-length': 5190,
        authorization: 'token [REDACTED]'
      },
      body: <Buffer 42 45 47 49 4e 3a 56 43 41 4c 45 4e 44 41 52 0d 0a 56 45 52 53 49 4f 4e 3a 32 2e 30 0d 0a 50 52 4f 44 49 44 3a 49 43 41 4c 45 4e 44 41 52 2d 52 53 0d ... 5140 more bytes>,
      request: { agent: [Agent], hook: [Function: bound bound e] }
    }
  }

I have no clue what that second one is about. It shouldn't be happening AFAIK because all the assets get deleted before attempting an upload. I'm currently pointing the GH action at a personal fork of IsaacShelton/update-existing-release in an attempt to find the problem.

[beyarkay]

Also note that, for now, the automated GH workflow will NOT work. I've created a manual one that I'm using for testing until I find something that does work consistently

[beyarkay]

@IsaacShelton has made a change to his update-existing-release repo that might fix this. Turns out GH has a limit of 100 items when listing release assets, so only the first 100 assets are getting deleted (see the discussion here)

[beyarkay]

Fixed after many iterations to the workflow files, and after registering a PAT in 2a8fe6b