Docs: Add verdi process status command to tutorial

[mbercx]

Fixes #4505

Currently the verdi process status command is only mentioned once in the documentation (in topics/processes/usage ). Since this command is both useful for getting a nice succinct overview of a work chain and debugging, it deserves a mention in the basic tutorial.

This PR adds the command just before generating the final provenance graph.

[sphuber]

Thanks @mbercx . Have two comments

[ltalirz]

thanks @mbercx - looks good to me.

don't know whether you want to wait for more input before merging

[mbercx]

Thanks @ltalirz! Will still give @sphuber a chance to comment before merging.

[csadorf]

LGTM.

[sphuber]

All good for me. I was just wondering if we should add that it is recursive, meaning that if one of the called processes itself also calls subprocesses, those will also be shown recursively. This might not be obvious since the example only has a single level

[mbercx]

All good for me. I was just wondering if we should add that it is recursive, meaning that if one of the called processes itself also calls subprocesses, those will also be shown recursively. This might not be obvious since the example only has a single level

I think it's ok to leave it as it is. As you said, the example doesn't demonstrate the recursion, and I think it will be clear if they use this command on a work chain where one of the processes also calls subprocesses.

[sphuber]

Good to go

[mbercx]

Had to rebase to develop, which dismissed the reviews. I always do this by rebasing on my work station and force-pushing to my repo branch. Is that the recommended approach?

[sphuber]

Had to rebase to develop, which dismissed the reviews. I always do this by rebasing on my work station and force-pushing to my repo branch. Is that the recommended approach?

If the commits of the PR will be squashed anyway, then this is not necessary. You can simply use the "Update branch" button of Github to merge develop into the branch. That will not dismiss the reviews, and so is the preferred option. For PRs that contain multiple commits that have to be kept, and so either merge-commit or rebase-merge strategy will be used, in that case one has to rebase locally and force push. The PR will have to be reaccepted in this case, but that is actually a good thing, since it will have to check the rebase was done correctly

[mbercx]

Right, we weren't running all the checks for the documentation PR's. How do I get GitHub to run all the checks so I can merge the PR?

[sphuber]

We cannot, because the checks re explicitly skipped, so we can only merge with admin rights, bypassing the checks. This is not ideal. If you could look, maybe with @chrisjsewell , how the skipping can be done within the action, such that it still runs, but it just shortcuts if the unit tests don't actually have to run. This would be the better solution, because then the PRs will also not show up as "still running" with the yellow circle but will get the green checkmark