fix!: Add support for missing attributes in ProjectsV2 API #3888
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3888 +/- ##
==========================================
- Coverage 92.54% 92.53% -0.01%
==========================================
Files 200 200
Lines 14679 14709 +30
==========================================
+ Hits 13584 13611 +27
- Misses 895 897 +2
- Partials 200 201 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
gmlewis
left a comment
There was a problem hiding this comment.
I'm wondering if we need a brand new "...WithContent" type here?
Since this PR is breaking the API anyway, can't you just do all the unmarshaling into the original "ProjectV2Item" struct?
It seems odd to me to continue to have both a "ProjectV2Item" and a "ProjectV2ItemWithContent" (and the extra maintenance burden that causes) if we can avoid it.
Thoughts?
@gmlewis I had actually considered that and talked myself out of it, somehow. I'll push up some updates to consolidate these. |
gmlewis
left a comment
There was a problem hiding this comment.
OK, I'm liking this much better... thank you, @tmelliottjr!
I would like to get some feedback from the developers who recently put in a good deal of work on ProjectV2 to make sure they are OK with these changes...
and then we will need a second LGTM+Approval from any other contributor to this repo before merging.
cc: @stephenotalora - @stevehipwell - @alexandear - @zyfy29
|
@tmelliottjr - as for the code coverage, if you could please try to add tests that cover these two lines, that would be a nice little bonus. The first one should be trivial... the second one might be trickier... and if it is too much of a pain, don't worry about it. Thank you! |
gmlewis
left a comment
There was a problem hiding this comment.
Thank you, @tmelliottjr!
LGTM.
Awaiting second LGTM+Approval from any other contributor to this repo before merging.
|
Thank you, @stephenotalora! |
|
@gmlewis I am working on at least one other PR that may involve breaking changes. There are some updates to an existing endpoint and the addition of a new one that I'd like to add support for. Those PRs are waiting for descriptions to be published, so they're not quite ready. I'm curious what the release cadence looks like to better coordinate the changes? |
We are a bit Generally, we shoot for one release per month, but sometimes we exceed that and sometimes it takes longer. |
|
Wonderful! Thanks for the info. |
This PR addresses a few gaps found between the current implementation and GitHub's ProjectsV2 OpenAPI spec:
ProjectV2ItemContentandProjectV2ItemWithContentstructs, along with a customUnmarshalJSONimplementation to inspect thecontent_typereturned by the API and automatically unmarshall the item's content (Issue|PullRequest|DraftIssue) into the correct struct.ProjectV2,ProjectV2DraftIssue,ProjectV2ItemContent,ProjectV2ItemWithContent, andProjectV2StatusUpdatestructs.ContentTypefield onProjectV2Itemfrom*stringto a dedicated*ProjectV2ItemContentTypetype for improved type safety.IsTemplateandLatestStatusUpdateto the existingProjectV2struct.