Skip to content
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

Merged
merged 25 commits into from
Feb 26, 2025

Conversation

matiaslcoulougian
Copy link
Contributor

@matiaslcoulougian matiaslcoulougian commented Feb 4, 2025

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:

  • Board list is populated with project uids
  • Project-board relation created 1-1 with project uid.
  • The board and board_issues streams are removed from list.
  • Task-board relationship is written on faros_issues stream using project uid.
  • Sprints and sprint history records are associated to the project board. If the same sprint is in more than one Jira Board, it will override it with the last one fetched.

TODO

  • Add more tests
  • Refactor to reduce duplication

Type of change

  • Bug fix
  • New feature
  • Breaking change

Related issues

Fix #1

Migration notes

Describe migration notes if any

Extra info

Add any additional information

…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.
@chalenge
Copy link
Contributor

chalenge commented Feb 4, 2025

Hmmm, did we say we wanna re-add this? We had previously explicitly. Also we that other dummy board

Copy link
Contributor

@chalenge chalenge left a 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

@matiaslcoulougian
Copy link
Contributor Author

matiaslcoulougian commented Feb 6, 2025

How are sprint report boards being handled, are they all gonna be phantoms. Can we add some tests to validate these mappings

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...
And we would write only one board sprint per project, hoping they don't differ that much.

@matiaslcoulougian
Copy link
Contributor Author

How are sprint report boards being handled, are they all gonna be phantoms. Can we add some tests to validate these mappings

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... And we would write only one board sprint per project, hoping they don't differ that much.

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.

@matiaslcoulougian matiaslcoulougian force-pushed the mc/jira-use-board-ownership branch from a32b541 to 79b218b Compare February 18, 2025 14:41
Copy link
Contributor

@chalenge chalenge left a 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

- Support Faros Graph inclusion, handling the case where board or excluded boards are provided by mistake.
- Add missing tms_TaskBoardProjectRelationship
- Re-add comments
- Refactor to functions constructor
filtering lists logic
Copy link
Contributor

@chalenge chalenge left a 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'
Copy link
Contributor

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

Copy link
Contributor Author

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} =
Copy link
Contributor

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

  1. projects_as_boards is selected, ignore board list completely. filterConfig.projects = projects.
  2. projects_as_boards is selected and use_faros_graph, ignore initial projects config too. then filterConfig.projects === boards come from the graph via selected boards
    WYDT?

Copy link
Contributor Author

@matiaslcoulougian matiaslcoulougian Feb 25, 2025

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()
Copy link
Contributor

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

Copy link
Contributor Author

@matiaslcoulougian matiaslcoulougian Feb 25, 2025

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) {
Copy link
Contributor

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

@matiaslcoulougian matiaslcoulougian merged commit 70cb986 into main Feb 26, 2025
8 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Feb 26, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants