Add support for resources requests and limits

[AlexisColes]

The actions runner controller allows me to run a bunch of github agents waiting for container jobs in k8. As these agents don't really do anything it would be good if I could keep a whole bunch of these agents running ready to pick up jobs as and when required with minimal resource requests.

resources:
        requests:
          cpu: 5m
          memory: 150Mi

I would then like the container jobs to define the amount of resources they want for each container and for this information to be passed through to the container spec.

jobs:
  container-test-job:
    runs-on: my-container-waiter
    container:
      image: node:14.16
      resources:
         requests:
           cpu: 500m
           memory: 2Gi
    services:
      postgres:
        image: postgres
         resources:
           requests:
             cpu: 500m
             memory: 2Gi

This would be very useful as we would not have to keep warm compute running for all the different permutations of required resources for out jobs and could just keep an amount of warm low priority compute to be share by all the different jobs.

Unfortunately there is no resources property for either a container or a service but maybe we can supply this information via the env property, something like.

jobs:
  container-test-job:
    runs-on: my-container-waiter
    container:
      image: node:14.16
      env:
         k8_resource_request_cpu:  500m
         k8_resource_request_memory: 2Gi
    services:
      postgres:
        image: postgres
        env:
           k8_resource_request_cpu:  500m
           k8_resource_request_memory: 2Gi

[nikola-jokic]

Hey @AlexisColes,

Thank you for submitting this issue so clearly! There is an ongoing work right now to allow merges and customization of container specs. But based on your description, I can see that it can't fit all cases well, especially for different workflows requiring different sets of limits and requests based on containers it needs to spin up.

Right now, I would prefer the env approach. It would eliminate changes in the workflow yaml file, but can carry a special meaning to the hook. I will bring this up to the team, but it seems like a great suggestion to me

[nikola-jokic]

Hey, closing this issue since it has been fixed with 0.4.0 release allowing definition overrides :relaxed:

[jmccarty3]

@nikola-jokic I'm not sure how the overrides that were introduced in 0.4.0 (and refined in later versions) fixes this specific issue. The template overrides that can be provided for containers are great for static mutations like imagePullSecrets, sidecars, volumets, etc.

The overrides however do not allow for dynamic resource setting as originally proposed in the issue. Static resources could be added with the $job entry but that would only allow a user to provide every job container with the same resource requests/limits. If pulling information from the container env variables is not ideal, it would be a nice middle ground to have the job resource request/limits set from reading the --cpus and --memory options from the jobs.*.container.options.

I think this issue should be reopend until proper support is in place or is stated as not going to be supported.