bugfix/revised-parent-id-datatype

[fivetran-joemarkiewicz]

PR Overview

This PR will address the following Issue/Feature: Issue #121

This PR will result in the following new package version: v0.16.0

The changing datatype of the revised_parent_issue_id field from int to string will result in a breaking change. There is no impact on incremental models, so no full refresh is required. But we should categorize this as a breaking change.

Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:

🚨 Breaking Changes: Bug Fixes 🚨

• The following fields in the below mentioned models have been converted to a string datatype (previously integer) to ensure classic Jira projects may link issues to epics. If you are referencing these fields downstream, be sure to make any changes to account for the new datatype.
  • revised_parent_issue_id field within the int_jira__issue_type_parents model
  • parent_issue_id field within the jira__issue_enhanced model

Under the Hood

• Included auto-releaser GitHub Actions workflow to automate future releases.
• Updated the maintainer PR template to resemble the most up to date format.
• Updated field and issue_field_history seed files to ensure we have an updated test case to capture the epic-link scenario for classic Jira environments.

PR Checklist

Basic Validation

Please acknowledge that you have successfully performed the following commands locally:

• dbt run –full-refresh && dbt test
• dbt run (if incremental models are present) && dbt test

Before marking this PR as "ready for review" the following have been applied:

• The appropriate issue has been linked, tagged, and properly assigned
• All necessary documentation and version upgrades have been applied
• docs were regenerated (unless this PR does not include any code or yml updates)
• BuildKite integration tests are passing
• Detailed validation steps have been provided below

Detailed Validation

Please share any and all of your validation steps:

Please see the corresponding Height ticket for a link to the Hex validation doc.

If you had to summarize this PR in an emoji, which would it be?

🧶

[fivetran-catfritz]

@fivetran-joemarkiewicz This generally looks good! I was able to reproduce the error with the seeds from this PR and then resolve it with the new branch.

My remaining question is that in other packages, we preferred to cast in the source package rather than in the downstream joins, so we only had to cast once. Do we not do this in this case because the intermediate models get a bit complicated and this was more straightforward or another reason?

[fivetran-catfritz]

It might help to add a line explaining how the classic projects were formatted, or why this benefits the classic projects.

[fivetran-joemarkiewicz]

Yeah I think that would be helpful. Just added a sentence explaining this a bit more.

[fivetran-catfritz]

Super helpful!

[fivetran-joemarkiewicz]

My remaining question is that in other packages, we preferred to cast in the source package rather than in the downstream joins, so we only had to cast once. Do we not do this in this case because the intermediate models get a bit complicated and this was more straightforward or another reason?

Great question @fivetran-catfritz! You are correct that I would prefer we typically cast the fields as string in the staging models. However, I did not take the approach here as it was a more straightforward approach and when exploring casting the upstream fields as strings I found that this PR would have quite a larger fingerprint and cause significantly more breaking changes (with little to no value). Because of this I decided taking the direct approach was the more efficient way to go about addressing this issue for both us and the end user. In this case the end user only has to be concerned about the revised_parent_issue_id being changed to a string datatype. If we were to cast the fields (particularly the issue_id field) upstream it would involve more models and fields that would be breaking.

Let me know if you have any other questions!

[fivetran-catfritz]

@fivetran-joemarkiewicz thanks for the explanation--makes perfect sense. Approved!

[fivetran-reneeli]

I don't see parent_issue_id in the jira__issue_enhanced. Did you mean issue_id? Or did you mean to mention a different model, int_jira__issue_users?

Also, if you're mentioning int_jira__issue_type_parents, should you mention the changes in int_jira__issue_epic and int_jira__issue_users too?

[fivetran-joemarkiewicz]

I don't see parent_issue_id in the jira__issue_enhanced. Did you mean issue_id? Or did you mean to mention a different model, int_jira__issue_users?

parent_issue_id is included in the jira__issue_enhanced model. It is not included in the code due to it being brought in via the *.

Also, if you're mentioning int_jira__issue_type_parents, should you mention the changes in int_jira__issue_epic and int_jira__issue_users too?

These are both ephemeral models which which will not result in any destination changes on the customers side. This is why they were not listed.

[fivetran-reneeli]

Got it, thanks for clarifying, looks good!

[fivetran-reneeli]

Just had a question about the changelog!

[fivetran-reneeli]

looks good