fix(repository-webhook): preserve write-only config.secret - #159
fix(repository-webhook): preserve write-only config.secret#159trent-hord wants to merge 1 commit into
Conversation
|
Hi @trent-hord, thank you very much for your valuable contribution! This is a good catch indeed - thanks for identifying the root cause and for providing a fix! The code looks solid, I'm happy to merge it. I do, however, have one concern: feel free to use any tools you like for creating/generating the code - but as the author, you are responsible for understanding every change. Please list yourself (name & email) as the commit author, not your AI tooling. (thanks for disclosing the tools in the description!) |
acch
left a comment
acch
left a comment
There was a problem hiding this comment.
Please list yourself (name & email) as the commit author, not your AI tooling.
|
FYI: I've added some AI Guidance to the contributing docs... |
|
@trent-hord I'm happy to merge this, once you list yourself (name & email) as the commit author... |
The webhook `secret` is supplied inside the `config` map but Forgejo, like Gitea, treats it as write-only: it is accepted on create/update but never returned by the API. The provider previously rebuilt `config` wholesale from the API response in `from()`, dropping the `secret` key. The planned `config` therefore differed from the applied `config`, failing Terraform's post-apply consistency check with "Provider produced inconsistent result after apply ... inconsistent values for sensitive attribute". Mirror the existing write-only handling (`authorization_header`, `branch_filter`) by carrying known write-only config keys over from the prior plan/state value when mapping the API response into state.
13894c2 to
9d62dbb
Compare
|
Made the changes requested. Ready for review. |
|
Thank you very much @trent-hord! The code looks good, I'll make a few minor edits before merging it... |
2 participants
The webhook
secretis supplied inside theconfigmap but Forgejo, like Gitea, treats it as write-only: it is accepted on create/update but never returned by the API. The provider previously rebuiltconfigwholesale from the API response infrom(), dropping thesecretkey. The plannedconfigtherefore differed from the appliedconfig, failing Terraform's post-apply consistency check with "Provider produced inconsistent result after apply ... inconsistent values for sensitive attribute".Mirror the existing write-only handling (
authorization_header,branch_filter) by carrying known write-only config keys over from the prior plan/state value when mapping the API response into state.Fixes #158
This PR was written in part with the assistance of generative AI