feat: Automatic browsers and drivers download

[evgeniy-dikevich]

This PR introduces a GitHub Actions workflow for automatically downloading deb packages for browsers and drivers with the amd64 architecture (may add aarch64 support for browsers that support this architecture).

The pipeline can be launched manually and on a schedule (every Monday at 10 AM UTC time).
When starting manually, you can specify the browser version you want to download or leave the field empty to download the latest version.

After the pipeline is completed, he will create a branch in the repository of the form chrome-xxx.xx.xxx which will contain zip archives with deb packages of the browser and driver:

At the moment, the workflow does not support automatic cleanup, so from time to time we will have to manually delete unused branches.

It is also possible to store zip archives as a releases.

This PR is open for discussion on several points:

• Should I store the zip archives the same way it is done now (separate branch for each browser version) or store the archives in different folders (browser/version) in the main branch or in releases or somewhere else?
• Is aarch64 support required?
• Which browsers should be supported (currently chrome, chromium, edge, firefox)?
• How often should the workflow run (currently every Monday in the morning)?
• Should we be notified somehow if the pipeline crashes and if a new version of the browser appears?
• Do we need to somehow track how big this repository has become?

Related issue: #1
Related PR: input-output-hk/catalyst-ci#458

[kukkok3]

My take on your questions:

• Should I store the zip archives the same way it is done now (separate branch for each browser version) or store the archives in different folders (browser/version) in the main branch or in releases or somewhere else? I would say maybe better to have everything in the main branch in different folders?
• Is aarch64 support required?
  Yes where is possible (for ex there is no chrome for aarch64)
• Which browsers should be supported (currently chrome, chromium, edge, firefox)?
  chrome for testing please:)
• How often should the workflow run (currently every Monday in the morning)? That should work yes
• Should we be notified somehow if the pipeline crashes and if a new version of the browser appears? It makes sense to me but I dont know where would be the best place to send this notifications, slack? email?
• Do we need to somehow track how big this repository has become?

[jmgilman]

If we could figure out the easiest way to get AWS credentials inside of an Earthly build, then we could opt to use S3 instead of storing things in Git. That would solve the (very valid) concern about the size of this repository. If we want to keep things this way, we will eventually need to add a cleanup workflow, because GitHub does have a hard limit on repository size.

[evgeniy-dikevich]

If we could figure out the easiest way to get AWS credentials inside of an Earthly build, then we could opt to use S3 instead of storing things in Git. That would solve the (very valid) concern about the size of this repository. If we want to keep things this way, we will eventually need to add a cleanup workflow, because GitHub does have a hard limit on repository size.

Looks like we can grand access to AWS S3 bucket from specific public IP: https://repost.aws/knowledge-center/block-s3-traffic-vpc-ip so we can try to allow Hetzner machine public IP and check

[evgeniy-dikevich]

Instead of repo we will use AWS S3 bucket. Everything else remained the same.