Move <target> option to <commands>

[lexa-uw]

Some improvements :)

Was:

network:
  local:
    hosts:
      - localhost
  remote:
    hosts:
      - [email protected]

commands:
  prepare:
    desc: Prepare to upload
    run: npm run build
    network: local

  upload:
    desc: Upload this repository
    upload:
      - src: ./
        dst: /tmp/$IMAGE

targets:
  deploy:
    - prepare
    - upload

Became:

network:
  local:
    hosts:
      - localhost
  remote:
    hosts:
      - [email protected]

commands:
  prepare:
    desc: Prepare to upload
    run: npm run build
    network: local

  upload:
    desc: Upload this repository
    upload:
      - src: ./
        dst: /tmp/$IMAGE

  deploy:
    commands:
      - prepare
      - upload

What do you think about it?

[eduardonunesp]

Looks good too, we need to mockup a bigger file, to check how that new style could help us

[VojtechVitek]

This would create much more complexity to the code (reading commands vs. targets from YAML) and I don't think it helps Supfile readability much. We made the distinction between commands and targets for reason. Target is just an alias for multiple commands that are run sequentially as opposed to commands. One should not be able to put another "run: " inside of target etc.

Think of:

commands:
  prepare:
    desc: Prepare to upload
    run: npm run build
    network: local

  upload:
    desc: Upload this repository
    upload:
      - src: ./
        dst: /tmp/$IMAGE

  deploy:
    desc: Deploy 
    run: echo "Should this be run? And when?"
    commands: # effectivelly "sub-commands"
      - prepare
      - upload

[pkieltyka]

I kind of like it.. I was thinking the same thing recently. It would take a little bit of work, but not that much since "commands" is its own field, YAML will parse it fine. We could define that the "run" will always execute before all other commands.

[VojtechVitek]

I'm not convinced this is worth the effort. And there are ugly edge-cases like:

commands:
  loop:
    run: "Running loop..."
    commands:
      - loop

Not to mention, this breaks the Supfile API.

[pkieltyka]

I don't think its a rush, but we can leave the ticket open for future ideas. To prevent the loop, we could check that when we build the command tree easily.

It does offer us to have command groups easily. Ie. declare a bunch of single commands, make smaller groups, then "deploy" will call those other groups.. the commands execution tree.

[VojtechVitek]

Ok, cool. I will think of this as part of big refactor for v1.0.

[eduardonunesp]

Sure it can generate some ugly edge-case, as well will take the code to another level of complexity, like adding lots of security checks.

IMHO now the project needs a stable version before adding more features, the community have found some bugs and maybe have a little more, depending of the case of course.

Agree that project needs a refactor before new specs in Supfile, I'd like to help with that refactor.

[VojtechVitek]

@eduardonunesp sure, I'll create a PR for the big refactor once I have more time and it will be open for discussion before we merge anything :) Any help will be appreciated.

No big rush for now, though. I'm glad we're thinking about new features thoroughly.

[lexa-uw]

  deploy:
    desc: Deploy 
    run: echo "Should this be run? And when?"
    commands: # effectivelly "sub-commands"
      - prepare
      - upload

No, run not needs for this type of commands. Only list of commands to running. Like targets alias, but on level commands in config.
For not to be confused in commands on first and second levels in config, I suggest name it targets or queue, maybe any else.

  deploy:
    targets: 
      - prepare
      - upload

Consequently we have in config only 3 entities on first level: env, networks and commands

I will think of this as part of big refactor for v1.0.

👍
But it will be better if the plan for early release for v0.3/v0.4. Before stable v1.0 relese.