Looking at:

• glab issue create
• gh issue create

We could implement options like:

$ doing issue create --help
# ...
 -a, --assignee login   Assign people by their login. Use "@me" to self-assign.
 -b, --body string      Supply a body. 
 -l, --label name       Add labels (tag) by name. Space separate multiple labels.

Note we'll first have to implement:

• Renaming doing create issue to doing issue create (#27).
• Implementing the @me user alias consistently everywhere (#36).

When adding a --web or -w parameter, we could open in the web browser the corresponding item. It can be added to:

• doing create issue
• doing create pr

Internally, we can do this quite elegantly by calling the function for doing open issue and doing open pr.

Inspiration is a similar flag in github cli (https://cli.github.com/manual/gh_issue_create)

Might lead to breaking changes, but will make doing easier to use for developers that use both CLI's.

https://cli.github.com/

Either/or:

• update the docs showing how to use an alias to set a default reviewer for a set of new issues
• allow users to set a default reviewers to all new issues and/or PRs in the config file

Currently, exotic characters in branch names (in the case I tested specifically, it was parentheses) will cause an error on doing create pr or doing workon in the checkout step, due to the branch name being passed directly rather than between quotes.

That is, it is passed as
git checkout -b branch_name
rather than
git checkout -b "branch_name"

Suggested fix would be to provide the branch name in between quotes as above - this should not cause different edge cases to pop up, but will fix this bug.

Azure devops has different workflow states, depending on the process configured for the project.

See https://docs.microsoft.com/en-us/azure/devops/boards/work-items/workflow-and-state-categories?view=azure-devops&tabs=basic-process#workflow-states

doing list --state open
doing list --state closed
doing list --state all

should work for all processes.

To create a .doing-cli-config.yml file.

Perhaps even doing init from issue #, that way you don't have to manually fill in things like area path, iteration path etc.

A user had the following error on python 3.6:

in .doing-cli-config.yml, you could specify the default issue type (like user story, issue or task). Current default is user story, you cannot change it.

You might make a typo when copy/pasting like the following:

doing create pr #12345
doing open pr !4231

We should allow for that syntax and simply drop the ! or # prefix.

We use text=True but seems we should use universinal_newlines=True instead for python 3.6. Thanks @tijlk for reporting

Now it uses the default (merge (no fast forward)) but we prefer rebase and fast-forward.

Probably the command az repos policy merge-strategy create is needed with the branch name and the parameter --allow-rebase true

My compliments for a great tool! Just what/how I like it!

Support number and url.

See https://cli.github.com/manual/gh_pr_checkout

Basically wrap az repos pr checkout --id

Imagine if I have a long list of contributors or I don't want to set the same default reviewers all the time but I also don't want to type their emails out when declaring the reviewers.

An idea is to allow the user to define a list of contributors on the doing-cli config file, so a keyword (like the first name of the contributor) and its email address:

john: [email protected]
jane: [email protected]

So then I could do doing create pr --reviewers john jane

What do you think? Does it sound useful?

Now, doing --help shows the commands in alphabetical order.

We can instead present them in a more natural order. See the solution here:
pallets/click#513

We need to make sure that this does not apply to doing open, because there alphanum ordering makes sense.

Having a space-separated list of reviewers is not giving me the expected results, instead resulting in errors of the form:

--transition-work-items 'true' --delete-source-branch 'true' --auto-complete 'true' --reviewers '[email protected] [email protected] [email protected]'
b'ERROR: Could not resolve identity: [email protected] [email protected] [email protected]\n' 

entered in the config as aliases, space separated:

default_reviewers: 'Name1 Name2'
user_aliases:
Name1: [email protected]
Name2: [email protected]

Also tried with just having adresses spelled out - this did not work either in version 0.5.3 or version 0.6 (though in the latter I got an unexpected error that aliases were not set, which is what first caused it to fail - which is exactly why I switched to an alias setup).

In addition, I have the following environment variables set:
export DOING_CREATE_PR_CHECKOUT="True"
export DOING_CREATE_ISSUE_MINE="True"

I believe, summarizing, that this is a bug with how (multiple?) reviewers are being parsed.

Not sure how it works, github cli offers a nice starting point:

Completion scripts https://cli.github.com/manual/gh_completion

That will also make it more consistent with github's cli (f.e. https://cli.github.com/manual/gh_pr_list)

doing list would be an alias for doing issue list, click has a way to implement aliases, see https://click.palletsprojects.com/en/7.x/advanced/#command-aliases

We are wrapping the azure devops cli (az devops). In some cases, it would be nice to show the raw commands being issued to the user.

Adding a flag --verbose or -v to every commands seems cumbersome. Either, enable it in the config file, or set an environment variable.

You should be able to overwrite / set config via environment variables. This will enable use cases like:

• Quickly seeing a different backlog (doing-iteration=path=another_path; doing list)
• Changing an iteration without updating the config file
• Setting a verbose mode (doing-verbose-mode=True), see #4
• Creating a bunch of work items in a specific type (doing-default-issue-type=bug; doing create issue 'a bug'), see #2

Furthermore, doing --help is quick bloated, because you can now set variables like project, organization etc via command line as well (f.e. doing list --project='your project'). I don't see basic users using these if they already have the config setup; advanced users will know how to user env vars as well. So, we can remove all parameters that are in the config from the command cli parameters, making the entire thing much more lean (and hopefully easier to learn).

Let's say I'm working on a branch for an issue for a couple hours. After pushing my code, I want to view the matching PR. I could do doing open prs and select the matching PR.

We could also allow for a user to not specify any arguments to doing open pr and then use the current git branch to find the matching PR. These kind of minor tweaks can make doing more useful in the daily development flow.

Getting ready for open-sourcing to github.com/ing-bank, so changing the license:

MIT license

Copyright

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

doing --help is great, but the docs should also provide the full overview.

github cli has a nice structure we could mimic: https://cli.github.com/manual/

instead of .doing-cli-config.yaml. Suggest renaming.

• Wraps az boards work-item update
• Mimics github cli's gh issue edit

Now we have the verb first:

doing create issue
doing create pr
doing close pr
doing close issue
doing list
doing init
doing open issue
doing open pr

Probably a subset of doing users also use / are used to the github cli, which has the other order, f.e.:

gh issue create
gh issue close
gh issue list
gh pr ...

It's a more natural grouping of the commands, and I've notice in using doing that I actually already typed doing issue create once, probably because I first think of the thing I want to manipulate (issue) before what I want to do with it (create). It mainly applies to creating and closing, not so much the others.

Concretely, do:

• Implement doing issue create, doing issue close, doing pr create and doing pr close
• doing create issue, doing close issue, doing create pr and doing close pr
  • Write deprecation messages (print alternative + warn deprecation in v1)
  • Hide those commands from the --help output (https://click.palletsprojects.com/en/7.x/api/#commands)
  • Remove from documentation

Currently, when trying to create PR for a repository to which you do not have contributor rights, we get an empty error message. Took me a little bit of rummaging about on my own before I could find out what the problem was. The azure cli actually does provide a useful error message here (telling us we don't have access), so perhaps a possible solution would be to forward the azure error message if any pop up?

especially while developing, I want to delete the stuff I'm creating :)

The newest version of rich gives a LiveError: Only one live display may be active at once when using doing list.

Temporary workaround is pip install rich==9.10.0.

Reimplement using latest syntax:
https://rich.readthedocs.io/en/latest/live.html

By setting up the long_description as markdown in the setup.py file. See for reference: https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/master/setup.py

A common workflow might be to add tasks (or bugs) to a parent work item. Adding a new parameters to doing to link an item to a parent will enable that workflow.

We would also then document some examples of more advanced workflows scripting doing, like creating aliases for certain tasks:

# Add to .bashrc
alias create_task="doing create issue --type='task' --parent $1 $2"
# use owth 
create_task 1234 "my task"

Not sure if it is a bug or an enhancement, but when doing create pr <issue_id>, doing creates a new branch, even if one already existed.

In my particular case, I had created a branch using the UI, and then it created another with doing create pr -d -c <issue_id>. They have different names. I don't know if the same would have happened if in the UI I had created a branch with exactly the name that doing would have used.

Fails:

$ doing init https://dev.azure.com/MyOrganization/MyProject/_workitems/edit/12345/
$ az boards work-item show --id  --org 'https://dev.azure.com/MyOrganization' --query 'fields.["System.AreaPath","System.IterationPath","System.IterationLevel2"]'
b'ERROR: argument --id: expected one argument\n\nTRY THIS:\nhttps://aka.ms/cli_ref\nRead more about the command in reference docs\n'

Works (removed trailing slash):

$ doing init https://dev.azure.com/MyOrganization/MyProject/_workitems/edit/12345
> Create new .doing-cli-config.yml file
        > Filled in required parameters using reference work item #12345

Print a more explicit 'no issues matching filters' / 'no pull requests matching filters'

Originally discussed in #28 : You can already overwrite defaults of commands using environment variables (see https://timvink.github.io/doing-cli/reference/config_file/), it would make sense to also allow for setting these env vars in the config file, for full flexibility.

Order then should be: explicitly set values > environment variables > config file > the default value.

So basically, I want autocompletion to be OFF - I like having control of when I merge (just in case I catch anything embarrassing myself, and also because that's the only way to choose the opt-in rebase, etc.). However, no matter what I do to DOING_PR_CREATE_AUTO_COMPLETE, I can't get it to behave what I want. Currently, I'm using

export DOING_PR_CREATE_AUTO_COMPLETE="False"

But that for sure isn't achieving it. I've also tried several other configurations, but none of them worked. I'm fairly certain I've at least also tried export DOING_PR_CREATE_NO_AUTO_COMPLETE="True", but it's been a while so I could be misremembering. Regardless, as the docs only mention DOING_PR_CREATE_AUTO_COMPLETE, I felt like setting that false should ideally work as expected....?

Is this a user error on my part, or is this var simply not being read properly?

Currently, we have:

https://github.com/timvink/doing-cli/blob/2dfe61437b6df2909fb179b733d4ec2b045e84fe/setup.py#L7

But we only use the find_dotenv function in 1 place:

https://github.com/timvink/doing-cli/blob/2dfe61437b6df2909fb179b733d4ec2b045e84fe/src/doing/utils.py#L115

find_dotenv recursively moves a directory up from the current working directory until it finds the file, or it raises an error.

We can rewrite this functionality ourselves and make the package slightly more lightweight.

I have a couple of migrations going right now, that are forcing us to (temporarily) work from a different branch than the master branch. This means that we're creating feature branches from another branch (let's call it develop) and are creating pull requests to that develop branch as well, instead of to the default branch (master).

It would be helpful if you could:

• set a source branch in the call to workon, e.g. doing workon "adding feature X" -b develop
• set a specific branch to always use in .doing-cli-config.yml, e.g.: default_branch: develop

Using a valid PR_ID, I used

doing pr checkout PR_ID

which returned the error:

        $ Running command: az repos pr checkout --id ('79276',)`
az repos pr checkout --id ('79276',)
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `az repos pr checkout --id ('79276',)'

Trying the plain az command in my terminal reveals that it looks like az is not expecting the parentheses nor the comma.

Options like --draft should also have a --no-draft to be able change defaults later, and have a consisten interface when a flag default is negative..

See https://click.palletsprojects.com/en/7.x/options/#boolean-flags

And a nice screenshot of doing workon 'issue': https://github.com/cli/cli

We have:

doing create pr WORK_ITEM_ID
doing open ISSUE_ID

Let's use consistent naming.

This is consistent with github's cli.

doing create issue -a @me
doing create pr -r @me
doing list -a @me

Additionally, we should then remove --mine or -m flags.

We could make workon a bit more "universal".

For example, if I want to work on an issue that has already been created, right now the workflow is

doing create pr <issue id>
git checkout <branch name>

What about allowing doing workon <issue> to automatically detect if the <issue> is an existing <issue id> and, if so, to create a PR based on that and checkout that branch?

Instead of

Created issue #146545 'fixing a small typo'

Print

Created issue #146545 'fixing a small typo' (Issue)

That way, when a user does doing create issue --type Bug, there is visual confirmation.

What about having an option on list to only show the X most recent issues/PRs instead of the whole list? And/or allowing to apply some filters, like assignee or type. Something like:

doing list --recent 10
doing list --author "john [email protected]"
doing list --type "task bug"
doing list --status active

The author filter could use the defaults that we will eventually add to the config file.

Some of these options could also be set as defaults on the config file (for example, if I don't want to see User Stories, just Tasks and Bugs; or if I want to include Resolved tasks, which are hidden by default at the moment).