Adding support for pluggable Container Execution Environments like AWS ECS Fargate and similar

[yuriy-yarosh]

Act version

act version 0.2.63

Feature description

Github Actions autoscaling is kinda busted if you don't want to rely on Github Actions Webhooks.
AWS CodeBuild and AWS CodeCatalyst are overpriced, and it makes more sense to replace them with AWS ECS Fargate Spot, or EC2 Spot Fleet Instances.

ACT has a pre-defined workflow graph for jobs that can be traversed and respective resources could be provisioned, autoscaled on demand, or scrapped during idling.

This would make ACT a very convenient tool for those who don't want to dive deep into Kubernetes and prefer to focus on simpler Cloud Managed Solutions.

[yuriy-yarosh]

Shoes have something similar for EC2 Spots, implemented as a hashicorp plugin.

[ChristopherHX]

What is your longterm Goal?, some of solutions are already available in the wild

Some potential Goals are listed here, maybe it's not in the list

• replace GitHub Actions completely
  • Want to use nektos/act cli with the feature requested here
  • my runner.server project, webhook based fake GitHub Actions Server. Not ready outside POC testing.
• replace both GitHub and GitHub Actions completely
  • => Gitea + Gitea Actions
    • act_runner based on nektos/act for job execution
    • MIT License
    • self-hostable
    • I'm not aware of an autoscaler
• replace the GitHub Actions Runner and keep using GitHub Actions
  • => github-act-runner
    • Disclaimer my project
    • based on my fork of nektos/act
    • allows to create a pipe shell script to move the job into anything you can pipe stdin/stdout to (maybe complicated to set up), this allows you to execute a fixed/variable count of runners on the same node as long polling listener that creates anything you like if you have something like ssh access
    • can be remote controlled by my fake GitHub Actions backend (runner.server), that doesn't implement sending workflow_job events
    • also can tunnel actions/runner into different containers
    • Could satisfy these requirements taken from linked issue

      nothing similar to an external workflow or external execution environments providers.

    • I'm not aware of an autoscaler
      • you might be able to script one with this runner
      • This runner can be created in memory as a go api
      • For example workflow_job webhook based https://github.com/ChristopherHX/megascaler

BTW I don't have the time to implement feature requests