feat: add Cloudflare Workers IaC and deployment workflow

[hazre]

Description

Adds repo managed Cloudflare Workers deployment infrastructure with OpenTofu and GitHub Actions.

read infra/README.md for setup and operational details.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

[jae1911]

Nice workflows overall, just two suggestions to optimize it further.

Please let me know what you think about this.

Also, good use of hashes when using third-party actions!

[jae1911]

Since this job-level env directive is present twice, here and on line 95, you could merge it within the top-level env directive, where the OPENTOFU_VERSION is defined.

For later:

You could then just define the environment on the job-level directive in case of different deployment envs.

GitHub environments can also be used to ease some of that stuff: https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments

[hazre]

what would be benefit of using GitHub environments in this case?

[jae1911]

Currently? None. There is only a single deployment target as-is, so
using environments would be kinda overkill.

I'm just putting this out there if one day there will be a clear
separation between dev, staging and production for deployments.
Environments allow you to set their own secrets and environment
variables within each as to be able to have all the variables named the
same, while containing different values for different targets.

Just to give an example, for instance, let's assume we have two
environments: staging and production.
In the following workflow, we have a workflow_dispatch trigger event
allowing the user to deploy to a specific environment:

on:
  workflow_dispatch:
    inputs:
      target:
        description: 'Target environment.'
        default: 'staging'
        required: true
        type: choice
        options:
          - staging
          - production

jobs:
  deploy:
    environment:
      name: ${{ inputs.target }}
    steps:
      - uses: actions/checkout@v6
      - runs: ./send --to ${{ inputs.target }} --auth ${{ secrets.auth }}
# ... and so on ...

In this case, the secrets.auth will be different depending on the
environment specified, despite having the same name. There's also a
bunch of other features like specify certain teams/people to approve
workflows in certain environments, etc.

Within the environment statement, you can also specify an url
parameter which will just display that deployment URL on the Actions
workflow, so more of a fancy UX thing. The other part of UX that changes
with environment is that all steps under that job will be grouped
together under that same link on the Actions status page.

But as I've mentioned, this feature is overkill for the current
pipelines, I just felt like mentioning it since it could be useful in
the future, shall the deployments become more complex.

In any case, this thread can be closed, thanks for the update!

[hazre]

Nice workflows overall, just two suggestions to optimize it further.

Please let me know what you think about this.

Also, good use of hashes when using third-party actions!

Thanks, did some of the suggestions you mentioned.

[jae1911]

Alright, great work on the pipelines, and thanks for listening to my advice.

I was being a bit troubled as of why install-command and build-command are left as an input in the setup Action, but seems you adapted the quality checks workflow quite nicely with the new Composite Actions, which some of those options are needed there.

Pipelines get an OK from me 👍