Skip to content

updateAutomatedSecurityFixes never called when no other repo settings changed #983

Open

Description

@jimisola

Describe the bug

updateAutomatedSecurityFixes is only called inside the if (changes.hasChanges) branch in lib/plugins/repository.js. When all other repository settings already match the desired state (i.e. changes.hasChanges === false), the else branch is taken — but that branch only calls updateSecurity (vulnerability alerts). updateAutomatedSecurityFixes is never invoked, so enableAutomatedSecurityFixes: false in settings.yml has no effect.

Relevant code (lib/plugins/repository.js ~line 96, version 2.1.18):

if (changes.hasChanges) {
  // ...
  promises.push(updateRepoPromise.then(() => {
    return this.updateSecurity(resp.data, resArray)
  }))
  promises.push(updateRepoPromise.then(() => {
    return this.updateAutomatedSecurityFixes(resp.data, resArray)  // ✓ called
  }))
} else {
  promises.push(this.updateSecurity(resp.data, resArray))
  // ← updateAutomatedSecurityFixes is missing here
}

To reproduce

settings.yml:

repository:
  # ... other settings that already match repo state ...
  security:
    enableAutomatedSecurityFixes: false  # desired: disabled
  1. Ensure all other repository: settings already match the current repo state so changes.hasChanges is false
  2. Run npm run full-sync
  3. Observe: disableAutomatedSecurityFixes is never called; repos retain their current value

Expected behaviour

updateAutomatedSecurityFixes should be called regardless of whether other repo settings changed — the same way updateSecurity is called in both branches.

Suggested fix

} else {
  promises.push(this.updateSecurity(resp.data, resArray))
  promises.push(this.updateAutomatedSecurityFixes(resp.data, resArray))  // add this
}

Environment

  • safe-settings version: 2.1.18
  • Running via npm run full-sync in GitHub Actions

Activity

  1. fbelliardtp commented on Jun 15, 2026

    @fbelliardtp

    Not the exact same problem but an adjacent one related to security settings:
    the security_and_analysis is always ignored when doing the comparison for changes.

    The only chance for it to be applied is to have a "basic" change (like has_wiki or has_issues) that intersects with the obtained filtered current settings and the settings to applied.

    This and the updateAutomatedSecurityFixes problem prevent having a robust solution to set those settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions