feat: Add support for multi var/envvars in repos

[bradam12]

Resolves #2526

---

Before the change?

N/A (new feature)

After the change?

• Able to manage repo variables and repo environment variables in a single resource.

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[bradam12]

@kfcampbell @nickfloyd for your review!

[deiga]

Hey @bradam12 👋

Thank you for your contribution! Could you describe your need here in more detail?
Since each variable will need to have it's own API call, what is the benefit using this versus github_actions_variable with a for_each loop?

[bradam12]

Hey @bradam12 👋

Thank you for your contribution! Could you describe your need here in more detail? Since each variable will need to have it's own API call, what is the benefit using this versus github_actions_variable with a for_each loop?

It's fairly documented in #2526. Reads can be done in one API call (per 100 variables), so future plans are much quicker and burn less API calls. Applys still write one at a time.

[deiga]

Hmm, I see.

I understand that the read can be quite consuming of the API rate.

The implementation you proposed here has me worried that failures in one API call will leave the resource in an wonky state.

[deiga]

While this might reduce the amount of API calls in some situations, the implementation is not something that the provider can support.
Having an "unlimited" number of "sub-resources" that each require it's own API calls would make this resource incredibly brittle to weird state issues due to network flukes or rate limit throttling.

Thanks for the contribution!