New feature: OS executor

[sarkiroka]

Hello
I use poco very intensively and sometimes I meet a problem: I need some setting, setup step before project start, but it can't be done with before_script because it run in a docker container. So I think good idea a new block (same level with before_script) which can run a script on hostmachine (for example a shell script whitin the current project, or any other command). But I know, it can run on Windows/Mac/Linux, so each command need to mark with OS selector:

# already exist feature
before_script:
  - ./script_in_container.sh

# the new feature
os_executor:
  - ./initial_setup.bat:win
  - ./initial_setup.sh:osx
  - ./initial_setup.sh:linux

What do you think about it? it's like a before start hook - later it can be extended.

[RCX07]

I could use this feature too. Especially when I'm working with multiple repositories to bootstrap a project and I don't want to deal with submodules and having the repository that I depend on in gitignore.

I would call it host_scripts or something like that, to better fit the docker lingo, but the flags are OK. Also, poco should ask for permission to run those scripts. I don't think that running scripts on the host arbitrary would be such a great idea.

[sarkiroka]

@RCX07

I don't think that running scripts on the host arbitrary would be such a great idea.

I agree, but some case I need this. For example I use private network, or ssh tunnel for access remote services (existing legacy remote services, not in poco plan) At this point I think good idea a script which check this connection, and create it when not connect. this ssh tunnel used by my browser too.
from docker container I cannot do this. (or don't know how yet)

[RCX07]

Sure. I'd have many use cases for this. If this would turn out to be some kinda lifecycle thing that would be even better. The other day I thought of a couple of things I could do in terms of cleaning up after my plan shuts down.

[sarkiroka]

Another use case, when I use one or more webserver in containers, and I want to open a browser from container. Currently I can't do this. But these scripts allow me to create a service which can open new browser tabs on host operating system. And when I end this session with containers, the poco will kill these processes too.

[kriszkern]

I don't think this would be an enhancement.
I believe the problems you stated here could be creatively solved with additional containers or the before_script feature.
Running OS dependent scripts on the host machine feels like taking a step back.

[sarkiroka]

Could you show a creative example to how to open a browser on the host machine from container?
Another example is an mssql service on windows host machine. When I start poco with poco up, I can start this service, and down when poco down - with this new feature. Otherwise I cannot do this in a single poco up step.

[kriszkern]

You could open a browser within a container, see this example.
For your other issue, there are perfectly usable SQL Server docker images provided by Microsoft here.

One of the principal ideas of the docker world is OS independence.
Introducing heavily OS dependent features like this would slow down the acceptance and progression of the container technology.

[sarkiroka]

Do you try these examples on windows computer?
I haven't got 4-6 GB RAM for only to the perfect SQL Server docker image. It is too big. On host machine it works well, but in docker container too big.