92 lines
3.8 KiB
Markdown
92 lines
3.8 KiB
Markdown
# 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.
|