GitHub configuration with OpenTofu #42
Conversation
There was a problem hiding this comment.
I think this is an awesome submission and I really liked the demo. As long as we address the weeds of what is exactly allowed to be auto-merged and feel comfortable with the configs I love this. This makes it extremely easy to handle the settings across the org and additional repositories added
|
Since Terraform is no longer open source and I work on OpenTofu now, can I suggest using OpenTofu? :D Also, you may find some inspiration here: https://github.com/ContainerSSH/github-terraform |
+1 |
|
We discussed this today in the community meeting, and it is something that we see value in pursuing. Our work on DevOps tasks for the org has been limited recently, so we haven't yet scoped in the work, but the team agrees that we should get this on the backlog even as an internal need. We are relying on the expert opinions of @lmilbaum and @janosdebugs here since we don't otherwise have the Terraform experience, so we trust that OpenTofu may be the best way to go. Can you take the time to update the proposal to reflect this change and any corresponding details? |
lmilbaum
changed the title
lmilbaum
force-pushed
the
github-configuration
branch
from
a9a98fe to
1f33756
Compare
Updated the proposal. I'll also update the code to use OpenTofu as soon as the proposal approved. |
|
After community discussion, I want to re-open voting for this proposal and finalize whether we choose to move forward with OpenTofu. Starting from today, let's make it a 10 workin gday period for voting so that a decision can be discussed in the next community meeting on June 17th. So voting closes on Friday, June 14th. |
There was a problem hiding this comment.
I'm inclined to abstain.
Clearly, manual maintenance of ~60 repositories has been painful, and it's unlikely to get better. And, to the extent that we expect to create additional repositories, applying IaC techniques would be key. But, I have no idea whether OpenTofu is the "best" choice for that.
The best power of IaC is in setting up new infrastructure. However, it seems unlikely that we will ever set up a new Arcalot on GitHub. Far more likely is that we will need to make changes to the existing setup, and the question is, would that be best done through OpenTofu, or should we be looking to GitHub native features for that administration?
At one extreme, the Github Organization serves as a centralized locus of control. For that, we don't need OpenTofu. At the opposite extreme, we will presumably have a need to make changes to single repos. Again, for that we don't need OpenTofu. So, the times when we would need something like OpenTofu are for making changes to non-trivial subsets of our repos, and I'm not sure that that is anything that we will do often enough to justify creating the requisite definitions to use in OpenTofu.
Perhaps I would think differently if I'd seen the demo or if I thought that we would have a repeated need for tweaking large numbers of repos. However, my intuition is that, if the individual repos are set up appropriately, then we should be able to make changes at the organization-level rather than touching the individual repos. The question then becomes, how do we straighten out the repos that we have and ensure that new repos conform to the organization requirements? OpenTofu might be a good answer to that, or it might be a solution in search of a problem.
|
|
||
| Automate and manage GitHub configuration with [OPenTofu][1] |
There was a problem hiding this comment.
Replace P with p in OPenTofu.
There was a problem hiding this comment.
If I may stick my nose into this issue as an outsider/OpenTofu core dev, OpenTofu is not the best choice for this, that would be GitHub Enterprise. AFAIK there are several security settings you can't enforce on repos unless you have enterprise. I wrote a tool a while ago to fill the gap, but haven't continued developing it. As a side note, joining the CNCF would get you access to GitHub Enterprise if I remember correctly.
As far as OpenTofu is concerned, you would need to have make sure no changes are made outside of OpenTofu and/or you'll have to deal with configuration drift.
There was a problem hiding this comment.
Your nose is always welcome. ;)
I'll check with Amye at the CNCF about the GitHub Enterprise question. If that is the case, and if we are ready to put ourselves on the CNCF sandbox track now, then perhaps that is the better approach.
There was a problem hiding this comment.
I'm still waiting on feedback from the CNCF about the use of GitHub enterprise. We obviously aren't banking on joining the Sandbox projects, but an effort now with OpenTofu may end up redundant if we do go that route. I'm also concerned about our ability to provide resources any time soon to implement this change. So for now, I'm voting against this, but I may like to see it revisited in the future.
dustinblack
force-pushed
the
github-configuration
branch
from
1f33756 to
d29e540
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
Just rebased. |
You can do that when the PR is merged out. Given that there are no dependencies between branches in this repo, there's no need to rebase in the middle of a review. |
Changes introduced with this PR
GitHub configuration with OpenTofu
By contributing to this repository, I agree to the contribution guidelines.