Group commands based on networks?

[pyrossh]

Just as we have different hosts, can't we have commands that run on different host. Like I don't want to run the build command on my production host but would like to have it only in development. In ansible we generally use roles for this I think.

networks:
  dev:
    hosts:
      - localhost
  prod:
    hosts:
      - api1.example.com
      - api2.example.com

commands:
  dev:
    build:
      desc: Build the go binary
      run: go build . -o project
  prod:
    upload:
      desc: Upload the go binary
      upload: ./project

[eduardonunesp]

Sup don't have these rules, instead it let you free to leverage the sh shell or bash. I have created a basic solution. Actually I think you have two options.

First:

version: 0.3

networks:
  dev:
    hosts:
      - dev.example.com

  prod:
    hosts:
      - prod.example.com

commands:
  build:
    run: |
      if [[ $SUP_NETWORK != dev ]]; then exit 0; fi
      echo "BUILD!"

  something:
    run: echo "FOOBAR"

targets:
  deploy:
    - build
    - something

Second:

version: 0.3

networks:
  dev:
    hosts:
      - dev.example.com

  prod:
    hosts:
      - prod.example.com

commands:
  build:
    run: echo "BUILD!"

  something:
    run: echo "FOOBAR"

targets:
  run_dev:
    - build
    - something

  run_prod:
    - something

[VojtechVitek]

We considered having this functionality, since this is quite common use case - but we wanted to keep SUP as simple as possible.

That's why we introduced $SUP_NETWORK env var instead so you can nest sup commands like this:

Supfile:

networks:
  production:
     hosts:
        - api1.example.com
        - api2.example.com
        - api3.example.com

commands:
  build:
    local: sup -f ./Supfile.builder $SUP_NETWORK build

Supfile.builder:

networks:
  production:
     hosts:
        - builder.example.com

commands:
  build:
    run: docker build -t image . && docker push image

sup production build will build docker image only on builder.example.com.

@pyros2097 @eduardonunesp Does this make sense? I didn't do a good job documenting this feature, let me fix that.

[pyrossh]

I think the sup_networks and targets think is what suits me for now. I'm not very keen on maintaining many supfiles for now as it is very small project for now. Maybe that would help a lot when you have many things to do and on different hosts. Thanks! :smile:

[VojtechVitek]

Ok, great. Closing for now. Feel free to reopen, if you have any further suggestions/questions.

[solher]

I am trying to run far away from Ansible and I am currently using Sup with docker-machine/docker-compose. It is almost perfect for that task but I have kind of the same problem.

For example, I would love to be able to have a "init" command that creates a new development docker-machine VM, but that command should only appear in the CLI under the "dev" network as the creation of a dev VM in production doesn't make any sense.

Using the above example, maybe something like that?

networks:
  dev:
    hosts:
      - localhost
  prod:
    hosts:
      - api1.example.com
      - api2.example.com

commands:
  build:
    desc: Build the go binary
    run: go build . -o project
    networks:
      - dev

  upload:
    desc: Upload the go binary
    upload: ./project
    networks:
      - prod
``

[pkieltyka]

@VojtechVitek @solher I believe we set a $SUP_NETWORK env var.. you could check that and exit if $SUP_NETWORK isn't "dev" .. right in your command. I believe its the best way without having to change anything in sup.

[solher]

I totally got that but it feels like a weird behavior. A user would try:

$ sup prod
Targets:

Commands:
- init   Initialize a new dev VM using docker-machine.

Usage: sup [OPTIONS] NETWORK COMMAND [...]
       sup [ --help | -v | --version ]

And would probably wonder "Why is there a dev command in production?". And a sup prod init would print "No you can't use a dev command in production".

It isn't really a technical issue and it is probably not urgent but I know it may confuse people to use a tool like that.