Secret Scanning Push Protection

All repositories in the PureStorage-OpenConnect organization have GitHub secret scanning push protection enabled. When you push commits, GitHub scans them for credential patterns (API tokens, cloud provider keys, etc.). If a potential secret is detected, your push will be rejected before it reaches the repository.

What a blocked push looks like

If your push is blocked, git will return an error similar to:

remote: - GITHUB PUSH PROTECTION
remote:   ——————————————————————————————————————————
remote:    Resolve the following violations before pushing again
remote:
remote:    - Push cannot contain secrets
remote:      (?) Learn how to resolve a blocked push
remote:      https://docs.github.com/code-security/secret-scanning/...

This is not a failure of your contribution — it is a safety check, and resolving it is usually quick.

If the detected secret is real

1. Do not bypass the block. Treat the credential as compromised and rotate it immediately (e.g., regenerate the FlashArray/FlashBlade API token, cloud key, or personal access token).

2. Remove the secret from your commit. If it appears only in your most recent commit, amend it:

   git rm --cached <file-with-secret>   # or edit the file to remove it
   git commit --amend
   git push
   

   If the secret appears in an earlier commit on your branch, you will need to rewrite history with an interactive rebase (git rebase -i <commit-before-secret>) before pushing again.

3. Move the credential into an appropriate mechanism instead: environment variables, Ansible Vault, CI secrets, or a local config file listed in .gitignore.

If it is a false positive

Test fixtures and documentation examples should never use strings that match real credential formats. Instead:

• Use clearly fake placeholders that do not match provider token patterns, e.g. api_token: "<your-api-token-here>" rather than a realistic-looking token.
• For unit tests requiring token-shaped values, construct them at test time or use values documented as invalid by the provider.

If you believe the detection is genuinely a false positive and the value cannot reasonably be changed, do not self-bypass — open an issue on the repository or note it in your pull request, and a maintainer will review and handle the bypass if appropriate.

Notes for maintainers and automation

• Pushes from bot accounts and release automation are subject to the same checks and will fail non-interactively. Keep generated files free of token-shaped strings.
• Bypass events are logged and alerted on. Only use a bypass after confirming the value is not a live credential.

Questions? Open an issue in the relevant repository or start a discussion in the organization.