…of every 2nd month" to `github_action_build` workflow triggers

- `workflow_dispatch` can be used to manually trigger a build, in case action run was deleted or artifacts get expired.
- `cron` is scheduled to be run every 2nd month (`~60` days) because artifacts expire after `90` days by default, and there is no easy way to set `89` days from now/start of year or ideally last commit, and some months have 28 or 31 days, which would make it even harder. Additionally, workflow should get triggered based on `cron` schedule regardless of last push time, so multiple action runs may exist for every commit anyways, so using 2nd month shouldn't be an issue.
- `cron` is scheduled to be run on the 15th minute to reduce chances of workflow getting dropped. If it does get dropped, then `workflow_dispatch` can be used.
  > The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
  - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

The idea for using `cron` to trigger rebuild when artifacts were expected to expire was suggested by @twaik in #199, but it was meant to trigger every 3rd month instead of every 2nd month that is currently being used.

Co-authored-by: @twaik <twaikyont@gmail.com>
Co-authored-by: @agnostic-apollo <agnosticapollo@gmail.com>

…of every 2nd month" to `github_action_build` workflow triggers

- `workflow_dispatch` can be used to manually trigger a build, in case action run was deleted or artifacts get expired.
- `cron` is scheduled to be run every 2nd month (`~60` days) because artifacts expire after `90` days by default, and there is no easy way to set `89` days from now/start of year or ideally last commit, and some months have 28 or 31 days, which would make it even harder. Additionally, workflow should get triggered based on `cron` schedule regardless of last push time, so multiple action runs may exist for every commit anyways, so using 2nd month shouldn't be an issue.
- `cron` is scheduled to be run on the 15th minute to reduce chances of workflow getting dropped. If it does get dropped, then `workflow_dispatch` can be used.
  > The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
  - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

The idea for using `cron` to trigger rebuild when artifacts were expected to expire was suggested by @twaik in #199, but it was meant to trigger every 3rd month instead of every 2nd month that is currently being used.

Co-authored-by: @twaik <twaikyont@gmail.com>
Co-authored-by: @agnostic-apollo <agnosticapollo@gmail.com>

…of every 2nd month" to `github_action_build` workflow triggers

- `workflow_dispatch` can be used to manually trigger a build, in case action run was deleted or artifacts get expired.
- `cron` is scheduled to be run every 2nd month (`~60` days) because artifacts expire after `90` days by default, and there is no easy way to set `89` days from now/start of year or ideally last commit, and some months have 28 or 31 days, which would make it even harder. Additionally, workflow should get triggered based on `cron` schedule regardless of last push time, so multiple action runs may exist for every commit anyways, so using 2nd month shouldn't be an issue.
- `cron` is scheduled to be run on the 15th minute to reduce chances of workflow getting dropped. If it does get dropped, then `workflow_dispatch` can be used.
  > The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
  - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

The idea for using `cron` to trigger rebuild when artifacts were expected to expire was suggested by @twaik in #199, but it was meant to trigger every 3rd month instead of every 2nd month that is currently being used.

Co-authored-by: @twaik <twaikyont@gmail.com>
Co-authored-by: @agnostic-apollo <agnosticapollo@gmail.com>

…of every 2nd month" to `github_action_build` workflow triggers

- `workflow_dispatch` can be used to manually trigger a build, in case action run was deleted or artifacts get expired.
- `cron` is scheduled to be run every 2nd month (`~60` days) because artifacts expire after `90` days by default, and there is no easy way to set `89` days from now/start of year or ideally last commit, and some months have 28 or 31 days, which would make it even harder. Additionally, workflow should get triggered based on `cron` schedule regardless of last push time, so multiple action runs may exist for every commit anyways, so using 2nd month shouldn't be an issue.
- `cron` is scheduled to be run on the 15th minute to reduce chances of workflow getting dropped. If it does get dropped, then `workflow_dispatch` can be used.
  > The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
  - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

The idea for using `cron` to trigger rebuild when artifacts were expected to expire was suggested by @twaik in #199, but it was meant to trigger every 3rd month instead of every 2nd month that is currently being used.

Co-authored-by: @twaik <twaikyont@gmail.com>
Co-authored-by: @agnostic-apollo <agnosticapollo@gmail.com>

…of every 2nd month" to `github_action_build` workflow triggers

- `workflow_dispatch` can be used to manually trigger a build, in case action run was deleted or artifacts get expired.
- `cron` is scheduled to be run every 2nd month (`~60` days) because artifacts expire after `90` days by default, and there is no easy way to set `89` days from now/start of year or ideally last commit, and some months have 28 or 31 days, which would make it even harder. Additionally, workflow should get triggered based on `cron` schedule regardless of last push time, so multiple action runs may exist for every commit anyways, so using 2nd month shouldn't be an issue.
- `cron` is scheduled to be run on the 15th minute to reduce chances of workflow getting dropped. If it does get dropped, then `workflow_dispatch` can be used.
  > The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
  - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

The idea for using `cron` to trigger rebuild when artifacts were expected to expire was suggested by @twaik in #199, but it was meant to trigger every 3rd month instead of every 2nd month that is currently being used.

Co-authored-by: @twaik <twaikyont@gmail.com>
Co-authored-by: @agnostic-apollo <agnosticapollo@gmail.com>

…of every 2nd month" to `github_action_build` workflow triggers

- `workflow_dispatch` can be used to manually trigger a build, in case action run was deleted or artifacts get expired.
- `cron` is scheduled to be run every 2nd month (`~60` days) because artifacts expire after `90` days by default, and there is no easy way to set `89` days from now/start of year or ideally last commit, and some months have 28 or 31 days, which would make it even harder. Additionally, workflow should get triggered based on `cron` schedule regardless of last push time, so multiple action runs may exist for every commit anyways, so using 2nd month shouldn't be an issue.
- `cron` is scheduled to be run on the 15th minute to reduce chances of workflow getting dropped. If it does get dropped, then `workflow_dispatch` can be used.
  > The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
  - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

The idea for using `cron` to trigger rebuild when artifacts were expected to expire was suggested by @twaik in #199, but it was meant to trigger every 3rd month instead of every 2nd month that is currently being used.

Co-authored-by: @twaik <twaikyont@gmail.com>
Co-authored-by: @agnostic-apollo <agnosticapollo@gmail.com>