Synicix
commented
3 years ago Typically I make it private, but there was serveral concerns with me actually deploying my github crendentials to AWS cloud along as I have serveral respository under my account that can't be leaked. I was planning to create a github account to act as a service account where it only granted access to this repo, so if that get comprised only this repo get screwed over. Traditionally I have the github crendentials as a K8 secret to deal with private repo.
On the subject of exposing AWS keys, I am well aware of this hence why all the speical keys and stuff are always set through enviorment variables via K8 secrets which are not published here.
Also fair point on the org repo, I just wanted to speed up some final changes so I just commit directly for now. Now that it is mostly stable I go the fork route.
Usually, you should work under a repo within your own user space until it is ready to introduce to an org repo; signalling that it is ready for collaboration. Public status should be consulted/reviewed beforehand to make sure we are not exposing any sensitive data or proprietary data. For example, exposing AWS keys can have costly consequences. However for this case, this has not been exposed and we are fine here but do keep this in mind for the future. Once introduced as an org repo, you should fork and only introduce new changes via PR's since we can now all collaborate. If you fork this repo, I can go ahead and close this issue as resolved.