Container Options not propagated to job containers #265

Closed
opened 2023-07-01 18:40:16 +00:00 by xtodpep · 4 comments

I'm trying to use --add-host=<my-gitea-url>:host-gateway in the container.options of the config.yaml.
However, this option does not seem to be passing through to the job containers.

as far as I can tell, this is because the container options are not being propagated through by https://gitea.com/gitea/act/src/branch/main/pkg/runner/run_context.go#L367
and my container options always end up being "" instead of what is set in the config.yaml

Other than container.options I am otherwise using the default config.yaml as generated by act_runner generate-config

I'm trying to use `--add-host=<my-gitea-url>:host-gateway` in the container.options of the config.yaml. However, this option does not seem to be passing through to the job containers. as far as I can tell, this is because the container options are not being propagated through by https://gitea.com/gitea/act/src/branch/main/pkg/runner/run_context.go#L367 and my container options always end up being "" instead of what is set in the config.yaml Other than container.options I am otherwise using the default config.yaml as generated by act_runner generate-config
wolfogre added the
kind
bug
label 2023-07-03 03:28:24 +00:00
Member

Hi @xtodpep , thanks for your report. Did you use the jobs.<job_id>.container option to specify the job container? If yes, you could try to add the option string to jobs.<job_id>.container.options and it should work.

Hi @xtodpep , thanks for your report. Did you use the [`jobs.<job_id>.container`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer) option to specify the job container? If yes, you could try to add the option string to `jobs.<job_id>.container.options` and it should work.

you could try to add the option string to jobs.<job_id>.container.options and it should work.

I have the same issue and this "fixed" it but...

On my side I need to apply some special settings (ie: mount volumes) to each custom container image used for build.

I'd like to keep those settings within runner configuration and outside sources (.gitea/workflow) because:

  • they're completely unrelated to sources
  • I'll be free to change them without affecting sources

Is this the way the config.yaml: container.options field is supposed to work?
If yes, there should be a way to change set Docker options for all child containers...

> you could try to add the option string to `jobs.<job_id>.container.options` and it should work. I have the same issue and this "fixed" it but... On my side I need to apply some **special settings** (ie: mount volumes) to each custom container image used for build. I'd like to keep those settings within runner configuration and **outside** sources (`.gitea/workflow`) because: - they're completely unrelated to sources - I'll be free to change them without affecting sources Is this the way the `config.yaml: container.options` field is supposed to work? If yes, there should be a way to change set Docker options for all child containers...

Looking at the code I've found that container.options in runner config.yaml file are applied only to default container; if a job has custom container configured, then it receives only its custom options (defined into .gitea/workflow file) and these additional options are discarded.

The function returning new container options is this (in gitea/act):

func (rc *RunContext) options(ctx context.Context) string {

func (rc *RunContext) options(ctx context.Context) string {
	job := rc.Run.Job()
	c := job.Container()
	if c == nil {
		return rc.Config.ContainerOptions
	}
	return c.Options
}

the temporary fix I've applied is this:

func (rc *RunContext) options(ctx context.Context) string {
	job := rc.Run.Job()
	c := job.Container()
	if c == nil {
		return rc.Config.ContainerOptions
	}
	// merge "general" and "child container" options
	return rc.Config.ContainerOptions + " " + c.Options
}

Before creating a PR, I'd like to know if this is how that configuration option is supposed to work.
Option comment reads like this:

container:
  # And other options to be used when the container is started (eg, --add-host=my.gitea.url:host-gateway).
  options: ""

What does the sentence other options to be used when the container is started mean?

1- "all jobs containers", including custom ones?
2- "only the default one"?

If 1), then the function above should be patched accordingly (like I did, but I'm not such a Go expert...).
If 2), then I'd like to have an additional option (maybe in runner section) to allow injecting options in all job containers, like I can do with environment vars.

Looking at the code I've found that `container.options` in runner `config.yaml` file are applied **only** to default container; if a job has **custom** container configured, then it receives only its custom `options` (defined into `.gitea/workflow` file) and these additional options are discarded. The function returning new container options is this (in `gitea/act`): https://gitea.com/gitea/act/src/commit/2069b04779e17c2b1a1aafcf66c7ae18b89ddcf3/pkg/runner/run_context.go#L645 ```go func (rc *RunContext) options(ctx context.Context) string { job := rc.Run.Job() c := job.Container() if c == nil { return rc.Config.ContainerOptions } return c.Options } ``` the temporary fix I've applied is this: ```go func (rc *RunContext) options(ctx context.Context) string { job := rc.Run.Job() c := job.Container() if c == nil { return rc.Config.ContainerOptions } // merge "general" and "child container" options return rc.Config.ContainerOptions + " " + c.Options } ``` Before creating a PR, I'd like to know if this is how that configuration option is supposed to work. Option comment reads like this: ```yaml container: # And other options to be used when the container is started (eg, --add-host=my.gitea.url:host-gateway). options: "" ``` What does the sentence _other options to be used when the container is started_ mean? 1- "all jobs containers", including custom ones? 2- "only the default one"? If 1), then the function above should be patched accordingly (like I did, but I'm not such a Go expert...). If 2), then I'd like to have an additional option (maybe in `runner` section) to allow injecting options in all job containers, like I can do with environment vars.
Member

Close by gitea/act#80

Close by https://gitea.com/gitea/act/pulls/80
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/act_runner#265
No description provided.