-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FAI-14070/FAI-14071: Add use_board_ownership flag to Jira Source #1908
Conversation
…haviour is true (as it was working as today) When flag is set to false: - Board list is populated with project uids - Project-board relation created 1-1 with project uid. - The board_issues stream is removed from list. - Task-board relationship is written on faros_issues stream using project uid.
Hmmm, did we say we wanna re-add this? We had previously explicitly. Also we that other dummy board |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How are sprint report boards being handled, are they all gonna be phantoms. Can we add some tests to validate these mappings
destinations/airbyte-faros-destination/src/converters/jira/faros_issues.ts
Outdated
Show resolved
Hide resolved
Didn't finish that implementation yet. Trying to think the best approach. The impl. on feeds leaves all boards as phantoms, but then they get linked to the project dummy board on the reports. Maybe we could link them directly to the project board on the graph... |
…ecated. Refactor logic and other fixes.
The issue here is that we are using board slices for sprint and sprint reports, to query sprints by board id. But here the board slices will contain the project key... So I'm not sure if we should query sprints for all project's boards all together for this case and if that would be performant also. |
a32b541
to
79b218b
Compare
# Conflicts: # destinations/airbyte-faros-destination/test/__snapshots__/index.test.ts.snap
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments. Can we validate feeds works with current destination
destinations/airbyte-faros-destination/resources/source-specific-configs/jira.json
Show resolved
Hide resolved
- Support Faros Graph inclusion, handling the case where board or excluded boards are provided by mistake.
…se project as boards mode.
- Add missing tms_TaskBoardProjectRelationship
- Re-add comments - Refactor to functions constructor filtering lists logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, see comments.
protected verifyListsWithGraphSelection( | ||
items: ReadonlyArray<string>, | ||
excludedItems: ReadonlyArray<string>, | ||
key: 'boards' | 'projects' = 'boards' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when do we ever fetch projects? We only fetch selected boards from the graph
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't fetch projects. But we fetch boards that are actually projects and that we need to verify against config project list and use as project filter config, when use_projects_as_boards is enabled.
) { | ||
super(config, logger, farosClient); | ||
|
||
const {items: projects, excludedItems: excluded_projects} = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this feels a little more complicated and we can simplify this. I am thinking when
projects_as_boards
is selected, ignore board list completely. filterConfig.projects = projects.projects_as_boards
is selected anduse_faros_graph
, ignore initial projects config too. then filterConfig.projects === boards come from the graph via selected boards
WYDT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not understanding how the simplification would be.
The check inside the constructor would be if use_faros_graph
is enabled, ignore projects and excluded_projects config.
And if use_faros_graph
is not enabled, we need to check that only projects or excluded_projects are defined and not both.
That is basically what is being done inside verifyListsWithGraphSelection function.
|
||
const jira = await Jira.instance(this.config, this.logger); | ||
if (!this.filterConfig.projects?.size) { | ||
const projects = | ||
this.isWebhookSupplementMode() && this.hasFarosClient() | ||
this.isWebhookSupplementMode && this.hasFarosClient() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should prolly move this out too in next PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did this change because if we leave the RunMode enum import from common.ts as it was before, we end up with a circular dependency between imports: project-board-filter -> common -> project-filter -> project-board-filter.
|
||
const jira = await Jira.instance(this.config, this.logger); | ||
|
||
if (!this.filterConfig.projects?.size) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks awry similar to the other method. Okay for now but should look to generalize
destinations/airbyte-faros-destination/test/converters/__snapshots__/jira.test.ts.snap
Outdated
Show resolved
Hide resolved
|
Description
We are adding use_board_ownership flag, like the one we had on the feed, to be able to keep using it with 1 board per project.
Default behavior is use_board_ownership:true, as it was working as today.
When flag is set to false:
TODO
Type of change
Related issues
Migration notes
Extra info