chore(deps): bump azure/login from 3.0.0 to 3.0.1

[dependabot]

Bumps azure/login from 3.0.0 to 3.0.1.

Release notes

Sourced from azure/login's releases.

Azure Login Action v3.0.1

What's Changed

• Escape single quotes in PowerShell login script inputs by @​MaddyMicrosoft in Azure/login#599

Full Changelog: https://github.com/Azure/login/commits/v3.0.1

Commits

• f5d393a Merge remote-tracking branch 'origin/master' into releases/v3.0.1
• e8cd11f Replacing hardcoded version v2 with v3 (#603)
• 73730b8 prepare release v3.0.1
• f4dcb80 Escape single quotes in PowerShell login script inputs (#599)
• e82415a Add IDE files to .gitignore (#597)
• a842007 Update CODEOWNERS (#598)
• 9dfca58 use the latest auzre/powershell@v3 (#581)
• See full diff in compare view

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.

[thekaveman]

@dependabot rebase

[jgravois]

I'd like to look into updating azurerm too. I think we're ~20 versions behind...

[thekaveman]

I'd like to look into updating azurerm too. I think we're ~20 versions behind...

Sure, probably a different PR yeah?

Any idea why this plan run is failing though? The error message indicates we don't have the step configured correctly, but of course that is wrong 🤔

[jgravois]

different PR for sure.

this error message is a mystery to me. we're supplying the appropriate input params and the patch release notes don't provide any clues 🤔

[jgravois]

ah, of course. dependabot doesn't have access to repository secrets. i'll create duplicate values that it can access and rerun the failing job.

[thekaveman]

Ah yes 🤦

[github-actions]

CHANGE	RESOURCE
update (2)	module.application.azurerm_container_app.pgadmin
	module.application.azurerm_container_app.web

[jgravois]

i think this one is safe to merge but i'm assigning @lalver1 too so that he can review the terraform plan output and confirm that its safe to deploy the changes it describes to the dev environment.

now that he's load-testing test i think so, but better safe than sorry.

[jgravois]

i'm rescinding @lalver1's review here because merging #3980 deployed the plan i mentioned above to dev.

all good though! 😇

[thekaveman]

merging #3980 deployed the plan i mentioned above to dev.

Interesting. I think this is unexpected at least so far as my PR was concerned -- we didn't get any plan summary comment, so I didn't realize anything was changing (beyond the expected SHA).

Should we change/remove the path filters for plan?

[jgravois]

Should we change/remove the path filters for plan?

personally i don't see what happened here as a bug. the drift on dev was the result of @lalver1's fiddling. not anything to do with your PR.

1. he temporarily allow-listed his own IP (to connect to pgAdmin)
2. he temporarily disabled reCaptcha (by mucking with the secrets loaded in the container app)

[thekaveman]

Agreed not a bug per-se, but it highlights an issue that plan and the summary is supposed to solve for us: We should know for a fact what infra changes will be made when merging any random PR.

It is always possible DevSecOps twiddles some nobs and those changes don't make their way down to our Terraform, or something else (more nefarious maybe??)

I still think over-communication here is better than an apply that (un)does things unexpectedly.

[jgravois]

I still think over-communication here is better than an apply that (un)does things unexpectedly.

i can get behind that, but its worth noting that even time itself (between the last commit pushed and a PRs eventual merge) opens us up to the potential of apply not adhering to the plan.

another cool option might be to consider surfacing terraform apply summaries more prominently. (especially when they do more than rev the Container app's SHA)

https://github.com/cal-itp/benefits/actions/runs/31639968999

[thekaveman]

even time itself (between the last commit pushed and a PRs eventual merge) opens us up to the potential of apply not adhering to the plan.

Fair enough. This all raises a related question for me, that isn't a new issue, but maybe still worth discussing:

How do we know what changes will apply to test or prod without just pushing a tag and watching the Actions output?

I think we can leave it here for now, and maybe revisit all of this in a future Workshop convo.