[feat-1681][jira]: Collect the epic issue in an issue's epic link#2401
Conversation
eee58cd to
c8bea0c
Compare
273a457 to
004f65b
Compare
e7388bc to
2f4f16d
Compare
150262c to
bcb7b10
Compare
mindlesscloud
left a comment
There was a problem hiding this comment.
it looks like the two new subtasks were not registered into Jira.SubTaskMetas .
| } | ||
| issue.Type = mappings.typeIdMappings[issue.Type] | ||
| issue.StdStoryPoint = int64(issue.StoryPoint) | ||
| issue.StdType = mappings.stdTypeMappings[issue.Type] |
There was a problem hiding this comment.
I think it should be hardcoded as "EPIC"
3d1db13 to
0d14927
Compare
| func CollectEpics(taskCtx core.SubTaskContext) error { | ||
| db := taskCtx.GetDal() | ||
| data := taskCtx.GetData().(*JiraTaskData) | ||
| externalEpicKeys, err := GetEpicKeys(db, data) |
There was a problem hiding this comment.
Loading all epic_keys is fine in most cases, but it could be a problem when the total number of epics grows too big. say 1000? Not sure if Jira API would take that many keys.
Besides, it is pointless to send all the keys every time, since the max records we can get is 100.
I suggest that we create an Iterator as the Input that returns 100 keys max each time.
There was a problem hiding this comment.
Are you saying have a Dal iterator that returns up to 100 rows at a time? I'll have to make a batched iterator version of it, because the existing one gives just 1 row at a time. Also, how will the urlTemplate look like? The jql is a query param, so I dont know what the template syntax is going to become like. I couldnt find existing examples of us doing something like this
There was a problem hiding this comment.
Yes, here is what I think it should be
- The
Iterator.Fetchis returning a value of typeinterface{}, so, we may return[]intorstringthat contains up to 100 epic-keys at a time. - Within
ApiCollector.Querycallback, we can access thoseepic-keysviareqData.Input, and concatenate them to the jql parameter
| @@ -23,8 +23,9 @@ import ( | |||
| ) | |||
There was a problem hiding this comment.
I was using queue iterators before realizing the Dal iterator was what I needed. I did find some issues and incompleteness with the QueueNode code though that I've tried to improve (e.g. being able to access a node's data). @klesh let me know what you think or if you want it reverted.
label(bug, feature etc.)Summary
Does this close any open issues?
Closes #1681
Screenshots
Include any relevant screenshots here.
Other Information
Any other information that is important to this PR.