Replies: 4 comments 4 replies
-
I made a conscious effort to make everything as optional, without changing the original default behaviour, but I agree that it is still a bit unwieldy for my liking. Open to suggestions to make the optional pieces more separated, and even if they should remain optional.
Yes, please. Thoughts below, to add context for my choices and help with further discussion, ordered with increasing level of opinionation:
My main thoughts when making improvements is to think of them as something being used by others rather than myself (although prioritising personal ease of use always bleeds in). If you think, some of the changes dont belong to the repo / main branch etc. please do provide suggestions on how best we go about it. I've made main / prod pickup from prod, staging from staging and all other branches default to dev env, so may be prod branch can be your working copy, if you want some code to be separated? Or have them in my repo? (although I'd prefer the former, if at all). Whatever it is, I think we should separate our own current use cases and keep main branch to be the best use code in general, if we keep the spirit of OSS and want people to use this repo directly with minimal changes, instead of forking and going off on their own tangent. I feel this is one of the most readable, understandable and usable repos for setting up a homelab (despite it missing some features compared to other repos). Some of these are just my opinions, happy to discuss alternatives (after all, most choices depend on the goal/usecase and have their pros/cons😌) Cheers. |
Beta Was this translation helpful? Give feedback.
-
@karteekiitg I'm finally able to sit down and read through your contributions. I'm looking through the devcontainers part now and it seems you've thought about a lot of edge cases with a lot of error handling. Personally I wouldn't care about handling the potential errors before they become an issue or nuisance. On one hand I appreciate your thoroughness, but on the other I worry about readability and maintenance in the long run. An approximately 1 400 lines long Python script to clean up GHCR images seems a bit excessive and I kind of hope you didn't write it exclusively for this repo. I assume you got some help from statistical language models? I tried amending your contribution on the karteekiitg-feature/devcontainer branch and opened a PR back to your repo, though I think that's a dead-end. I've opened PR #334 with my own take on a devcontainer, keeping the Infisical out of the mix. I've tried to use the ready-made devcontainers/ci for building the image instead as I feel this is much cleaner. I also don't mind not cleaning up the registry as it should be too cluttered anyway. I also think there's something wrong with your tofu fmt workflow as I tried running edit: I'm talking about the Infisical mentions in the devcontainer PR. I'm looking into PR #303 separately. |
Beta Was this translation helpful? Give feedback.
-
I've started digging into the GCS-state bucket on the karteekiitg-feature/gcs_bucket branch. I'd like to modularise the approach in order to better understand how each part is working together. I'm thinking about moving all of the the Infisical parts into a separate Tofu project altogether, but not sure how yet. |
Beta Was this translation helpful? Give feedback.
-
@vehagn Add a few more changes to existing PRs (cloudflare r2 state, email alias, cloudflare account tokens, etc). Thoughts / suggestions are welcome :) Edit: I think a short call would be much quicker to resolve / understand things than hashing out asynchronously? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
@karteekiitg Has done a lot of work to enable DevContainers, remote state saving and infisical integration as well as some Cloudflare DNS Ad-blocking in PRs #301, #302, #303 and #306.
I really appreciate his work and therefore want to have an open discussion about how to proceed with them. I haven't had the time to properly look at them and test them, so I can't verify them that quickly. On one hand it's a great piece of work and seems properly good documented, but on the other hand it adds complexity which I'm not using myself (at least not at the moment).
From the preliminary changes I've seen, it should be possible to keep the additions separate from the "core-functionality" without adding another layer of complexity/confusion.
The PRs look sort-of related, so I'll try to review them in numeric order. Does that sound like a good idea, @karteekiitg?
Beta Was this translation helpful? Give feedback.
All reactions