Fancy pants task management (GitLab and Jira) CLI/TUI in Rust
Go to file
Daniel Flanagan e1f83d54fe Moar config stuff 2024-05-29 08:04:33 -05:00
.cargo A good place? 2024-03-19 12:07:37 -05:00
.vscode A good place? 2024-03-19 12:07:37 -05:00
src Moar config stuff 2024-05-29 08:04:33 -05:00
.envrc Initial commit 2024-03-18 22:46:41 -05:00
.gitignore Cleanup some client structure 2024-03-19 16:47:50 -05:00
Cargo.lock WIP tui code re-organization 2024-04-19 18:58:44 -05:00
Cargo.toml WIP tui code re-organization 2024-04-19 18:58:44 -05:00
flake.lock Initial commit 2024-03-18 22:46:41 -05:00
flake.nix Config stuff working 2024-04-19 15:27:16 -05:00
readme.md With 2024-04-20 08:38:47 -05:00

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) with 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.