workflow notes about loco

[avdd]

gh create -a @me -t 'title'

NB set EDITOR=vim to use editor for body (defaults to nano which I have uninstalled)

[avdd]

branch=$(gh issue view --json number,title -t '{{.number}}-{{.title}}' 4 | tr \  - |tr A-Z a-z)
git checkout -b $branch

[avdd]

gh issue view N

[avdd]

Run failing test:

instance=$(docker ps --latest --quiet) # FIXME: ensure this is robust
docker exec -it -u vscode -w /tmp $instance python /workspaces/loco/test.py

Use /tmp as working directory to avoid creating crap (geckodriver.log) in workspace.

[avdd]

TODO: ensure test run does not conflict with interactive development:

Address already in use
Port 8000 is in use by another program. Either identify and stop that program, or start the server with a different port.

[avdd]

I tried the --fill option:

gh pr create -d -f

but this created the PR immediately, so no chance to link to the issue #4.

TODO: script this more fully with --title and --body.

[avdd]

PR #5.

[avdd]

gh pr create --fill uses the branch history as the PR comment body somewhat redundantly, so we don't want that.

[avdd]

--draft is good for WIP 👍

[avdd]

TODO: investigate whether I want to action the "Your master branch isn't protected" warning or dismiss

[avdd]

TODO: investigate whether I want to action the "Your master branch isn't protected" warning or dismiss

This is for collaborators and I have none.

[avdd]

TODO: quickly capture these TODOs!

[avdd]

TODO: quickly capture these TODOs!

Use github issues as catch-all, but use a label for triage:

gh issue create --label todo --title "$*" --body "..."

What to put in the body?

[avdd]

set BROWSER=~/.local/bin/wslstart.sh

TODO: document wslstart.sh

[avdd]

TODO: capture dev container workflow in docker wrapper script

[avdd]

Use unittest discovery:

docker exec -it -u vscode -w /workspaces/loco $instance python -m unittest -v

[avdd]

After reorganising files out of top-level, the test command is:

docker exec -it -u vscode -w /workspaces/loco $instance python -m unittest discover -s test

[avdd]

I tried the --fill option:

gh pr create -d -f

but this created the PR immediately, so no chance to link to the issue #4.

TODO: script this more fully with --title and --body.

Mention the issue# in the PR body to link the two, so that merging the PR will close the issue.

gh pr create -d -t '4-summary' -b 'resolves #4'

or after the fact:

gh pr edit -b 'resolves #4' 5

[avdd]

If using a draft PR (not sure about this, seems like pointless overhead if it's only me) set the status:

gh pr ready 5

then merge:

gh pr merge -m -d 5

[avdd]

gh create -a @me -t 'title'

gh issue create -a @me -l 'label' -t 'title'

[avdd]

TODO: ensure test run does not conflict with interactive development:

Address already in use
Port 8000 is in use by another program. Either identify and stop that program, or start the server with a different port.

see #8

[avdd]

I tried the --fill option:

gh pr create -d -f

but this created the PR immediately, so no chance to link to the issue #4.

TODO: script this more fully with --title and --body.

see #9

[avdd]

TODO: quickly capture these TODOs!

Use github issues as catch-all, but use a label for triage:

gh issue create --label todo --title "$*" --body "..."

What to put in the body?

see #9

use TODO for body

[avdd]

set BROWSER=~/.local/bin/wslstart.sh

TODO: document wslstart.sh

see #10

[avdd]

TODO: capture dev container workflow in docker wrapper script

see #6

[avdd]

Note: can't create a PR without new commits on the new branch!

[avdd]

rough workflow probably something like:

gh issue ls
# select issue to work on
N=11
gh issue view $N
gh issue edit --remove-label todo --add-label in-progress $N
branch=$(gh issue view --json number,title -t '{{.number}}-{{.title}}' $N | tr \  - |tr A-Z a-z)
git checkout -b $branch
# some minimal change to start the PR
git commit -av
git push -u origin $branch
gh pr create -a @me -t "$branch" -b "resolve #$N"
# hack further ...
git push
# review work, if ok then:
PR=$(gh pr list -S $branch --json number --jq '.[].number')
gh pr merge -m -d $PR

[avdd]

comment on issue:

gh issue comment -e $N

remove in-progress label:

gh issue edit --remove-label in-progress $N

[avdd]

pull merged master:

git checkout master
git pull -p

clean up branch:

git branch -D $branch
git push -d origin $branch

[avdd]

Latest docker commands

# get the instance id
instance=$(docker ps --latest --quiet)

# run the server
docker exec -it -u vscode -w /tmp $instance python -m loco.main

# run the python tests
docker exec -it -u vscode -w /workspaces/loco $instance python -m unittest discover -s test/server -v

# run the js tests
docker exec -it -u vscode -w /workspaces/loco $instance ./node_modules/.bin/jasmine test/client/test_init.js

[avdd]

rough workflow probably something like:

thinking that there's no point with the PRs -- just use branches and commit with "closes #N"

[avdd]

Consolidating so far (non-PR workflow)

# 1. list issues
gh issue ls

# 2. capture a todo item
gh issue create --label todo --title "blah blah" --body TODO

# 3. view issue
gh issue view $N

# 3a. view on the web
gh issue view -w $N

# TODO: triage todo items?

# 4. edit issue body
tf=$(mktemp -t gh-XXXXXXXX.md)
gh issue view --json body -t '{{.body}}' $N > $tf
vi $tf
gh issue edit -F $tf $N
rm $tf

# 5. add comment
gh issue comment -e $N

# 6. start working on an issue
branch=$(gh issue view --json number,title -t '{{.number}}-{{.title}}' $N | tr \  - |tr A-Z a-z)
git checkout -b $branch
git push -u origin $branch
gh issue edit --remove-label todo --add-label in-progress $N

# 7. first commit on branch
git commit -m 'close #$N' # see notes below
git push

# 7a. iterate
git commit -v #...
git push

# 8. complete (TODO: verify these steps)
git checkout master
# will this fast-forward?
git merge $branch
git -d $branch
git push -d origin $branch
git push master
gh issue edit --remove-label in-progress $N

# 8a. close issue if not linked (see below)
commit=$(git rev-parse HEAD)
gh issue close -c "close in $commit" -r completed $N

So although this workflow avoids unnecessary PRs, I'm still not sure how to reliably automate linking the work to the issue.

This workflow appears to suffer from a similar problem as observed above with the PR workflow, in that a commit must be pushed before the stream of work (branch or PR) can be linked to the issue. With this workflow, the issue can only be linked in a commit and I would have to remember to include the magic keyword in some commit message. The merge step may be an opportunity to do the link, I need to check. But that only happens at the end, so WIP branches would remain unlinked unless linked in some commit.

With the PR workflow, a creating a PR requires a new commit on the branch, meaning I cannot create the PR until I have already done some work, and again the linking is done mid-workflow. However at least with the PR workflow, the PR description is a reliable place to include the linking keyword.

Possibly I could create a PR as part of the completion steps, purely for the purpose of the linking. That seems a bit pointless.

Alternatively I could force an empty commit for the sole purpose of the link, i.e. with git commit --allow-empty, either at the start or the end.

The PR workflow is nicer how it neatly presents the commits on the respective branch though...