Support alternative way to define command headings so that ancestor commands are not required to be present

[jgroom33]

Current behavior:

## foo

    ```bash
    do something
    ```

mask foo

Desired behavior

## foo

### bar

    ```bash
    do something
    ```

mask foo.bar

[jacobdeichert]

Hey! So nested headings 3+ should already be supported.

See the subcommands section here: https://github.com/jakedeichert/mask#subcommands

Nested command structures can easily be created since they are simply defined by the level of markdown heading. H2 (##) is where you define your top-level commands. Every level after that is a subcommand. The only requirement is that subcommands must have all ancestor commands present in their heading.

Try this:

## foo

Make sure you add "foo" before "bar" since that's the parent command.

### foo bar

```bash
echo "do something"
```

#### foo bar bat

Level 4 should also work.

```bash
echo "do something else"
```

mask foo bar
mask foo bar bat

[jgroom33]

The section naming requirement is too strict.

It would be nice if an existing markdown file could be used (i.e. Readme.md) and any subsection within it could be executed.

This would allow a readme to operate like a makefile.

[jacobdeichert]

@jgroom33 i'll consider this. I kind of like the strict schema for headings right now, but I'm open to changing my mind in the future.

The reason I enforced this constraint is because I personally believe it improves readability when someone is reading a maskfile. Some markdown renderers don't provide enough of a distinction between different levels of headings. And when reading raw markdown source, it's a little easier to know which level of heading you're at when the ancestor commands are present... also making it easier for someone to copy/paste into their terminal.

I actually would like to hold this decision for awhile though. I want to see how mask evolves slowly over the next few months. For me, readability is the largest concern. Though, both patterns can be simultaneously supported.

This would allow a readme to operate like a makefile.

Good news is that #19 will be merged shortly and will allow you to use any markdown file you want :)

Though the requirement ancestor commands present in their heading will still exist for now.

[jgroom33]

@jakedeichert For additional consideration. implementing #17 would alleviate the requirement for this: https://gitlab.com/gitlab-org/gitlab-ce/issues/43289

[jacobdeichert]

I've rethought this and am on board now. Typing out the parent commands each time makes the raw markdown too cluttered which makes it annoying to read.

I think we should support both ways even if they are mixed within the same file.

## build

### build client
~~~bash
echo client
~~~

### build server
~~~bash
echo server
~~~

#### build server production
~~~bash
echo "server for production"
~~~

## build

### client
~~~bash
echo client
~~~

### server
~~~bash
echo server
~~~

#### production
~~~bash
echo "server for production"
~~~

[lsampras]

@jakedeichert I've raised a PR as to what I think might be a solution to this. can you review it ?

[jacobdeichert]

@lsampras I plan to take a look at open PRs today 👍