options in workflow and container.network in config file are in confilct #220

New Issue

sillyguodong · 2023-05-29T09:21:05Z

sillyguodong commented

2023-05-29 09:21:05 +00:00

See: https://gitea.com/xorm/xorm/actions/runs/3

An error message (db.Exec: dial tcp: lookup mysql on 127.0.0.11:53: no such host) was returned at the step of test mysql.

container.network of act_runner configuration file is empty string. According to the introduction of #184, empty string means that job container and its service containers will connect to a new network which created by act_runner. These containers can access each other by alias.

Obviously, the action performed in xorm above was not as expected.

Then, I found this in the log of the step of Setup job:

As we can see, networkmode is specified as bridge instead of a new network when service container created.

the defintion of services in workflow:

services:
  mysql:
    image: mysql:5.7
    env:
      MYSQL_ALLOW_EMPTY_PASSWORD: yes
      MYSQL_DATABASE: xorm_test
    #ports:
    #  - 3306:3306
    options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3 --network=bridge

So I guess it that the --network=bridge defiend in options covers the new network which created by act_runner.

In https://gitea.com/xorm/xorm/actions/runs/6, remove --network=bridge, networkmode is still specified as default.

Finally, remove options and it works as expect.

Cause

In the function of mergeContainerConfigs in act:

If the value of options is not a empty string, and specify --network to bridge, the logic of the merge will be executed. That's why it's covered as brigde.
If --network is not specified in options and options is not a empty, will be set to default.

		pkg/container/docker_cli.go
		Line 656 in 9283cfc9b1
	
						NetworkMode:    container.NetworkMode(copts.netMode.NetworkMode()),

// NetworkMode return the network mode for the network option
func (n *NetworkOpt) NetworkMode() string {
	networkIDOrName := "default"
	netOptVal := n.Value()
	if len(netOptVal) > 0 {
		networkIDOrName = netOptVal[0].Target
	}
	return networkIDOrName
}

Solution

There are two possible solutions.

Be consistent with Github, just ignore the --network flag in options (both jobs.<job_id>.services.<service_id>.options and jobs.<job_id>.container.options ) .
Add an option to the configuration file to control whether or not --network in options is effective.

See: https://gitea.com/xorm/xorm/actions/runs/3 An error message (`db.Exec: dial tcp: lookup mysql on 127.0.0.11:53: no such host`) was returned at the step of `test mysql`. `container.network` of `act_runner` configuration file is empty string. According to the introduction of https://gitea.com/gitea/act_runner/pulls/184, empty string means that job container and its service containers will connect to a new network which created by `act_runner`. These containers can access each other by alias. Obviously, the action performed in `xorm` above was not as expected. Then, I found this in the log of the step of `Setup job`: ![image](/attachments/45faee65-4e15-41ca-b047-4a4c34c3eb42) As we can see, `networkmode` is specified as `bridge` instead of a new network when service container created. the defintion of services in workflow: ```yaml services: mysql: image: mysql:5.7 env: MYSQL_ALLOW_EMPTY_PASSWORD: yes MYSQL_DATABASE: xorm_test #ports: # - 3306:3306 options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3 --network=bridge ``` So I guess it that the `--network=bridge` defiend in `options` covers the new network which created by `act_runner`. In https://gitea.com/xorm/xorm/actions/runs/6, remove `--network=bridge`, `networkmode` is still specified as `default`. ![image](/attachments/fb506dad-44a1-430e-b409-5894931e58d5) Finally, remove `options` and it works as expect. #### Cause In the function of [mergeContainerConfigs](https://gitea.com/gitea/act/src/commit/9283cfc9b16637669ddac20fb66935493dac35ec/pkg/container/docker_run.go#L348-L358) in `act`: - If the value of `options` is not a empty string, and specify `--network` to `bridge`, the logic of the merge will be executed. That's why it's covered as `brigde`. - If `--network` is not specified in `options` and `options` is not a empty, will be set to `default`. https://gitea.com/gitea/act/src/commit/9283cfc9b16637669ddac20fb66935493dac35ec/pkg/container/docker_cli.go#L656 ```go // NetworkMode return the network mode for the network option func (n *NetworkOpt) NetworkMode() string { networkIDOrName := "default" netOptVal := n.Value() if len(netOptVal) > 0 { networkIDOrName = netOptVal[0].Target } return networkIDOrName } ``` #### Solution There are two possible solutions. 1. Be consistent with [Github](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservicesservice_idoptions), just ignore the `--network` flag in `options` (both `jobs.<job_id>.services.<service_id>.options` and `jobs.<job_id>.container.options` ) . 2. Add an option to the configuration file to control whether or not `--network` in `options` is effective.

sillyguodong added the

kind

bug

labels 2023-05-29 09:21:26 +00:00

silverwind commented

2023-05-29 12:53:20 +00:00

Be consistent with Github, just ignore the --network flag in options (both jobs.<job_id>.services.<service_id>.options and jobs.<job_id>.container.options ) .

Sounds good. I think network config should not be part of a step, but part of the runner configuration.

> Be consistent with Github, just ignore the --network flag in options (both jobs.<job_id>.services.<service_id>.options and jobs.<job_id>.container.options ) . Sounds good. I think network config should not be part of a step, but part of the runner configuration.

👍 1

sillyguodong referenced this issue from gitea/act

2023-05-31 09:33:58 +00:00

Fix some `options` issue. #59

lunny referenced this issue from a commit

2023-05-31 10:33:41 +00:00

Fix some `options` issue. (#59)

lunny closed this issue

2023-05-31 10:33:41 +00:00

Sign in to join this conversation.