taskr/readme.md

# taskr

A workflow-specific tool for managing tasks at my current job which integrates
with GitLab and Jira.

# But... why?

Mainly as a way to learn _more_ Rust to do a few things better:

- Async with `tokio`
- Command-line interfaces (CLIs) with `clap` and `cliclack`
- Terminal user interfaces (TUIs) `ratatui`
- Configuration with `config` and `keyring`
- Lazy-loading with `std::sync::OnceLock`
- User-facing error handling with `color_eyre`
- Logging with `tracing` and friends
- HTTP clients with `reqwest` and friends

I expect to do many of these things wrong over the life of this project, which
will hopefully help me do it more-right next time.

I co-maintain a Rust CLI at my current job, so these are all things I'm familiar
with, but always wanting to improve and try other ways of doing things to see
how they compare.

## But... why?

Deja-vu!

Yes, most companies would just setup the GitLab and Jira integration and call it
a day. Everything would work nicely.

But we self-host GitLab behind many layers of security that make it inaccessible
from Jira, which is hosted and managed by Atlassian and for whatever reason do
not have access to those integrations anymore.

Plus I like the idea of owning more of "my" data. Yes, it's work's data, but
it would be neat to have a record of stuff I did, even if just at a high-level.
It would enable me to build more automation around it, possibly integrate with
notes, and other potentially-neat applications.

But mostly it's the first reason. Rust is fun! Learning it is fun! It feels
good.

# Original High-Level Plan & Ideas

Currently, at my job, I have a number of layers of red tape to work through just
to actually make commits.

- I must have a Jira ticket to work against. This is almost never provided to
  me and is something I make myself.
- I must have a GitLab branch name that matches the Jira ticket.
- I must progress the Jira ticket separately from the GitLab branch.

My goal is to unify these without having to page through these applications
which often breaks flow. Here's how I'm hoping to structure this:

- I run a command indicating a new task that I am working on.
  - Something like `task new 'fix slack token being logged'`
  - Perhaps also prompts me with a fuzzy finder for a project as well?
- This gives me a ticket ID
  - If I provided a project as well, it should checkout a new branch with the
    correct branch name for that project branching off the latest default branch
    from the origin
  - Perhaps it also moves my current working directory into the project
  - Perhaps it even further opens my text editor
- I make commits and push them up
  - Each project needs to have hooks setup in the git config with GitLab that
    create a draft MR
- I need those commits to be reviewed, so I need a way to ask for reviews
  - Something like `task request-review $ID`?
  - Marks the review as "ready" (not a "draft")
  - This then has different flows depending on the project, but primarily would
    mean sending a message in Slack with the format `!review $LINK_TO_MR -
    $SUMMARY_OF_CHANGE`
- Once the MR is ready to merge, I need to be notified as I want to merge and
  deploy it
  - The code review bot does notify in the review thread. Perhaps I can listen
    for this?
  - I need to merge the MR
  - If the project requires it, I need to manually confirm that I want to deploy
    to production
  - Once my change has been deployed, I need to close the related Jira ticket

My goal is to codify this process as generically as possible and make way for
project-specific details as well so that I can minimize my personal overhead as
I go through this process and possibly even across the organization.

It would also be nice to manage tasks across the team, dumping the state of my
Jira board and diffing that over intervals of time would be useful to see how
tasks progress over time.