Update security_and_analysis settings only when there are changes #2397
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
resourceGithubRepositoryUpdate
function currently passes the current state of security_and_analysis to the PATCH /repo request. If the repo has an enforced security configuration, this can result in the API returning a 422 response because changing security settings is not allowed in this case. Even though the security_and_analysis settings remain the same, and only some other settings are changed, the request will still fail.To avoid the request failing when security_and_analysis remains the same, we will only pass it in the request payload when changes have been made.
Resolves #2383
Before the change?
Currently, if a repository has Secret Scanning enabled. The payload in the PATCH /repository request will include this data, thus attempts to enable Secret Scanning on the repository again. This can happen even with this template that doesn't modify Secret Scanning
After the change?
The request payload for PATCH /repository will only contain the
security_and_analysis
object when security features are being modified. This means that the value for at least one of the features is being updated:advanced_security
,secret_scanning
,secret_scanning_push_protection
,secret_scanning_non_provider_patterns
,secret_scanning_validity_checks
. By doing this, we will only attempt to modify these settings when a change is specified by the template.Pull request checklist
I didn't write an acceptance test for this change because the setup requires applying a security configuration to a repo. I tried the following manual test:
main.tf
that looks liketerraform apply
allow_rebase_merge
fromfalse
totrue
in the templateterraform apply
againignore_vulnerability_alerts_during_read
is set for this test because the terraform state stored locally can be different from the repo's state after a security configuration is applied. This causes the update command to attempt changing Dependabot alerts enablement state, which will fail if the state is enforced by a security configuration.Does this introduce a breaking change?
Please see our docs on breaking changes to help!