refactor: migrate resource_github_issue_label to context-aware CRUD a…#3342
Conversation
|
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with |
|
Please remove the resolves comment, since it adresses the issue only partly. And "resolves" will close the issue |
deiga
left a comment
There was a problem hiding this comment.
LGTM!
Thanks for the contribution!
|
I just removed it from the description |
|
Would you be available to rebase this (possibly multiple times) during the next week? We're going to release 6.13.0 and will try to land some of these open PRs |
There was a problem hiding this comment.
Pull request overview
This PR refactors resource_github_issue_label to use Terraform Plugin SDK v2 context-aware CRUD function signatures and structured logging via tflog, aligning the resource with ongoing provider-wide migrations tracked in #2996 and #3070.
Changes:
- Migrated the resource from legacy
Create/Read/Update/DeletetoCreateContext/ReadContext/UpdateContext/DeleteContext. - Updated CRUD implementations to return
diag.Diagnosticsand wrap errors withdiag.FromErr. - Replaced
log.Printfusage withtflog.Infostructured logging and removedcontext.Background()usage.
|
Yes, I can rebase it during the next week as needed. I’ll rebase now and address the Copilot review comments as well. |
241dc85 to
40c2608
Compare
deiga
left a comment
There was a problem hiding this comment.
@stevehipwell even though there are other parts here that could be refactored, I would suggest we do the minimum here to get this merged.
stevehipwell
left a comment
There was a problem hiding this comment.
For me the bare minimum here would be to separate create & update and remove the call to read from them.
ba9fec5 to
9c162ad
Compare
|
Thanks, I separated the create and update handlers and removed the explicit read call from both paths while keeping the existing idempotent create behavior for default GitHub labels. |
9c162ad to
ad3d0c9
Compare
ad3d0c9 to
43498d3
Compare
stevehipwell
left a comment
There was a problem hiding this comment.
@slymanmrcan this is looking good. There are still a couple of outstanding comments to address and it looks like you haven't run the strict linting for new code?
88958c6 to
3fef38e
Compare
|
Thanks, my mistake. I missed the strict new-code lint locally. |
stevehipwell
left a comment
There was a problem hiding this comment.
Thanks for making the changes, I've added some feedback so you can follow the idiomatic patterns.
88e2360 to
c20bfef
Compare
|
Thanks @slymanmrcan, this looks good. Could you please rebase and let us know if you've run the acceptance tests for the resource locally? |
robert-crandall
left a comment
There was a problem hiding this comment.
Thanks for taking this on - moving to context-aware CRUD and tflog is a nice cleanup, and I appreciate the careful function split. Both questions I left feel like behavior changes worth a second look. Happy to help think through it!
| orgName, repoName, originalName) | ||
| if err != nil && resp.StatusCode != http.StatusNotFound { | ||
| return err | ||
| githubLabel, resp, err := client.Issues.CreateLabel(ctx, orgName, repoName, label) |
There was a problem hiding this comment.
Quick question on intent: the old combined function did a GetLabel first and called EditLabel if the label already existed (the removed comment explained it - new repos ship default labels, and a name clash returns 422). This version calls CreateLabel directly, so a pre-existing label would now 422 instead of being adopted. That may well be the better Terraform behavior (import instead of adopt) - just flagging since the checklist says "no behavior change." Totally fine if intentional.
There was a problem hiding this comment.
I think this should be Terraform based logic, so fail if the label already exists. We have github_issue_labels to act as an authoritative source.
c20bfef to
9da13ec
Compare
|
Thanks for the review! I’ve pushed the fixes now: color/description are set from Read again, and Create preserves the previous GetLabel-then-EditLabel behavior for existing labels. |
| repoName := d.Get("repository").(string) | ||
| name := d.Get("name").(string) | ||
| color := d.Get("color").(string) | ||
| // resourceGithubIssueLabelCreate creates an issue label. |
There was a problem hiding this comment.
Let's not keep comments around if they don't explain something non-obvious
| // resourceGithubIssueLabelCreate creates an issue label. |
| func resourceGithubIssueLabelImport(_ context.Context, d *schema.ResourceData, _ any) ([]*schema.ResourceData, error) { | ||
| repoName, name, err := parseID2(d.Id()) | ||
| if err != nil { | ||
| return nil, err |
There was a problem hiding this comment.
To make the DX nicer, lets add a helpful error message here :)
| return nil, err | |
| return nil, fmt.Errorf("Import failed due to ID format mismatch in %s. Please ensure import ID follows the pattern `<repository name>:<label name>.", d.Id()) |
Addresses parts of #3070
Addresses parts of #2996
Before the change?
resource_github_issue_labeluses legacyCreate/Read/Update/Deleteschema functions and
log.Printffor logging.After the change?
CreateContext/ReadContext/UpdateContext/DeleteContext(ctx context.Context, d *schema.ResourceData, meta any) diag.Diagnosticslog.Printfwithtflog.Infofor structured loggingcontext.Background()callsdiag.FromErr()Pull request checklist
Does this introduce a breaking change?