ci: Create dependabot.yml for dependency maintenance

[Carus11]

To assist in keeping dependencies up to date, this is a sample dependabot.yml configuration file which will seach the terraform modules, docker, and github actions, for external dependencies and open pull requests with those dependencies bumped.
This could be taken further to then run some tests in github actions as part of these pull requests which would automatically test the project with the new dependency version.

To avoid overwhelming the maintainers, the number of pull requests opened each run can be limited, as I have shown in the code with a current limit of 5 for each scope.

[dhoucgitter]

To avoid overwhelming the maintainers, the number of pull requests opened each run can be limited, as I have shown in the code with a current limit of 5 for each scope.

Definitely appreciate the suggestion on how to limit the number of opened PRs per run since if I calculate correctly, this configuration could be as high 15 new PRs weekly. I'd suggest we reduce both the frequency and limit since we can always increase those values once we gauge how well this is working.

Also, could you adjust the branch target on your PRs from sassoftware:main to sassoftware:staging.

Could you add an example of a test like this if you have an idea for it?

This could be taken further to then run some tests in github actions as part of these pull requests which would automatically test the project with the new dependency version.

We want to move toward PRs including their own tests as part of acceptance where that's possible. GitHub workflows that run terraform test or terratest are two possibilities we're hoping to leverage.

[Carus11]

Reference:
https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#target-branch-

[Carus11]

I am unsure of the final behaviour when targeting another branch as I have only ever done it on main, but it has this note:

Options defined for this package-ecosystem no longer apply to security updates because security updates always use the default branch for the repository.

[Carus11]

Updated to two PR's open at a time per scope, and changed target branch to staging

[dhoucgitter]

I am unsure of the final behaviour when targeting another branch as I have only ever done it on main, but it has this note:

Hi @Carus11, updating the GitHub workflows to target the staging branch as you did makes sense since we want the PRs dependabot opens to target the staging branch for the project instead of main. I would also ask that the PRs you submit target the staging branch instead of main. You can change the branch your PR targets to the staging branch from main using the edit button that you should see at the top of each PR screen.

[Carus11]

Done,
I think despite the dependabot.yml saying to work on the staging branch, any security issues opened by dependabot may open against the main branch as it is the primary branch in this repo. I think that is a github behaviour.

[Carus11]

@dhoucgitter

We want to move toward PRs including their own tests as part of acceptance where that's possible. GitHub workflows that run terraform test or terratest are two possibilities we're hoping to leverage.

Do you want to build infrastructure with every PR? or run a terraform plan as a check to validate something would indeed potentially build as expected?

Is it worth it to do on every PR, or would you rather want to split out:

Inidividual PRs:

• Lint
• Format
• Security best practice scan (kicx from checkmarx or something similar)
• Terraform Plan

As part of the steps leading up to release:

• Build new infra
• Apply to existing

I'll admit im not that familiar with terratest, can it mock the azure api fully? or will it build the infra for real?

[dhoucgitter]

@Carus11

Do you want to build infrastructure with every PR? or run a terraform plan as a check to validate something would indeed potentially build as expected?

We are not intending to build infrastructure in github workflows for cost and speed reasons, but do intend to use terraform plan, potentially with each PR to validate inputs, scripts and where possible validate expected values where that can be accomplished.

Don't believe there is any built-in capacity to mock cloud apis, terratest is able to run terraform plan or apply to stand up and then tear down infrastructure.

[Carus11]

but do intend to use terraform plan, potentially with each PR to validate inputs, scripts and where possible validate expected values where that can be accomplished.

I would urge some caution, terraform plan needs a target to plan against, and so I would suspect that means putting secrets into the github project configuration page. I could potentially output those secrets even though github tries to obscure them if I simply base64 them. If this was run automatically without I could potentially swipe cloud credentials before a reviewer would notice.