husterknupp / jubilant-todo-tribble Goto Github PK

• find not too excessive way to iterate trough file tree
• printout number of files included in the repo
• find all todos

store:

• each todo line number
• literal code line of todo
• 7 lines of context (if given) up and 7 lines down
• email + user name of committer (for now project creator see #3)

Read codebase of arbitrary repo and walk path

• arbitrary gitlab repo:
• find a way to get all files and folders in a repo
• find gitlab endpoint url for a file
• auth needed for read access?
• printout single line to see that the reading works

• For a particular line of code find out who committed that line
• Find the project owner name

We do not really want to use one standard component in all Jira issues. Thats why we want to be able to select a component that already exists or create a new component.

• implement a frontend component that enables component selection
• enable component creation

• create empty method for later implementation
• add implementation to the method
• double check todo counting

• todo moves line up, text doesn't change -> changed todo (consider context change?)
• todo moves line down, text doesn't change -> changed todo (consider context change?)
• todo stays in the same line, text changes -> new todo/changed todo (levenstein distance?)
• todo has same text as another todo in the same file at another line -> new todo
• todo stays the same, all together -> no change

case 1,2 (consider context change) / 3 (word difference) should be done in another issue

• create notifications on slack next to the mail notifications

• make buttons (wow)
• make everything else
• make make more subtasks

Should have

• permanent internet and cpu access
• access to gitlab and jira

Out of scope: easy deployment process. Building on whatever server and restarting should suffice for the start.

• create develop branch

mvn clean package -U should lead to

• no maven dependency errors and
• ideally a BUILD SUCCESS maven output

Please provide a console output with details for a broken build.

• how to detect changes
• where to remember the found todos?
• implementation

Programmatically create an issue

• find jira endpoint url/method for creating new issues
• how to do auth?
• don't put Jira url or any credentials in code base
• use dev project (get id)
• use issue engineering issue type (get id)
• define assignee
• define issue title
• define issue description
• implement the connection
• log that new issue has been created

Java?
Kotlin?

Dunno if we need it or want it. Just in case, I found this one might be interesting to try out.
Structurizr http://flip.it/V5x8WX

on GET /stats show me

• what repo(s) are being scanned?
• how many todos have been found?
• when was the last scan?
• was there an error?

Currently one can specify only one component to scan. It makes sense to enable more than one repo.

• Let's make arbitrarily many different gitlab repos configurable in the yaml
• How to persist todos?
• Map from repoId to todo list?

• make linux build great again

Currently git does not ignore the credentials class which is pretty annoying for every commit

Let's read a Credentials file or our already exisiting application.yaml even for the tests.

.. rather than scanning the whole file tree over and over again

• GitHub commit model (see patch) https://api.github.com/repos/Husterknupp/jubilant-todo-tribble/commits/30fd93abf61d32ae9132def3f01c67aa76dc4da2
• Gitlab commit model https://docs.gitlab.com/ce/api/commits.html#get-a-single-commit
• Jgit Java library for instance https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/patch/Patch.java#L136

• Put todos in ticket description
• Currently we talk only to Jira. So having one configurable Jira issue id should be enough to track the progress there via API calls.
• Also the already tracked todos should not be removed when a new one comes. But new ones should be added at the end

Format should look like this
( ) Todo in ${repoId} (branch ${branchName}) - ${fileUrl} Line ${lineNumber}

.. and not create tokens with every new request. Avoid being the session creation leader

Travis should be good for the job

• https://docs.travis-ci.com/user/languages/java/#Projects-Using-Maven

• build on every commit

• build on develop branch

• build on master branch

• notify committer on error

• do not forget fancy badge in README ;-)

• [-] test if commit on change from failure to success works - Currently there is no mail on build change from failure to success. Because this is not that important. Thats why this ticket will be closed.

• document how to compile and start the application
• create skeleton method where later the scanning will be triggered. No implementation yet

read this and do it: https://docs.travis-ci.com/user/deployment

It would be nice if todos would be added to a ticket that I'm anyway working on so that I can make the progress of an issue more transparent

Either by looking in the commit message or by parsing the todo itself

format could be like
for Jira

• commit message [DEV-123] comited some code
• todo string: // todo something needs to be done (DEV-123)

and this for github

• commit message #20 comited some code
• // todo something needs to be done (20)