Display task summary

[jaedle]

Adding a --summary flag for task to get more a summary of the task

See #107

New field in task called summary

version: '2'
tasks:
  release:
    deps: [build]
    summary: |
      Release your project to github

      It will build your project before starting the release it.
      Please make sure that you have set GITHUB_TOKEN before starting.
    cmds:
      - your-release-tool
  build:
    cmds:
      - your-build-tool

Output for task --summary release:

task: release

Release your project to github

It will build your project before starting the release it.
Please make sure that you have set GITHUB_TOKEN before starting.

dependencies:
 - build

commands:
 - your-release-tool

Behaviour:

• --summary will not execute the task
• --summary will display the summary of a task (see above)
• --summary will use description as fallback, if summary does not exist
• --summary will output a warning (or information), if no description/summary is present
• --summary will output the dependencies if there are any
• --summary will output the commands if there are any

Tests:

• Because there are a lot of edge-cases I decided to extract out a package (summary), which is completly unit tested with above named edge cases.
• There is an integration like test in task_test.go

Documentation is present for that feature

[jaedle]

Usage:
task --details some-task

There are still some questions to me:
What should happen, if there is no detailed description for this task?

• Outputting an error message makes perfect sense for me.
• Should there be a non-zero exit value? I would guess no..

What should happen, if there are given multiple tasks?
Actually it shows just the description for the first one..

[tonobo]

Wouldn't it be cooler to have kind of inspect/describe command, which shows long description and the whole command specification?

[jaedle]

Wouldn't it be cooler to have kind of inspect/describe command, which shows long description and the whole command specification?

I think there is a difference. Sometimes it makes sense, if you have preconditions or something like that, to document it. I think for that a details section makes perfect sense.
For other purposes I think your suggestion is also very good - but maybe in a different use case.

[tonobo]

I meant this in addition to your newly introduced keyword, it's pretty cool to give tasks a more detailed description. But the details context could print also the whole task in detail.

[jaedle]

Could you propose a sample output for this?

[tonobo]

I don't know maybe something like this ?

task: build

Pretty long description comes here Lorem ipsum dolor sit amet, 
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut 
labore et dolore magna aliqua.

Dependencies:
  - lint
  - format

Commands:
  - sh -c "go build ..."

[andreynering]

Hey @jaedle, great work with the code, tests and documentation! 👏 👏👏

Thanks for spending the time on work on this. I did just a few comments, but once addresses this is good to go.

[jaedle]

Hey @jaedle, great work with the code, tests and documentation! 👏 👏👏

Thanks for spending the time on work on this. I did just a few comments, but once addresses this is good to go.

Hey @andreynering,

thanks for the review. I‘m quite new to golang, so I really appreciate it! Fixes are comming next week 😊

[jaedle]

I've been thinking hard how to do this.
I think the task component (high level abstraction, only delegates to other components) should not care about a low level detail like spacing for the output of the summary.
To fix this, I added a PrintTasks Method for the summary-package, which deals with it and is unit-tested.

[jaedle]

I really hope this is good to go! :)

[andreynering]

@jaedle Thanks again!

If I can give you a friendly tip, next time try keeping a smaller number of commits.

[jaedle]

@jaedle Thanks again!

If I can give you a friendly tip, next time try keeping a smaller number of commits.

Thanks for the recommandation. I usally tend to squash merge, if you don‘t, I will squash the branch before raising the PR.