Sharpen distinction between public and internal deployments

[hlgr360]

I just went through our Github repo to trigger the clean up some dormant repo’s according to our Open Source policy.
I suggest that if you just want the source files to be referenced in the blog you use gist instead of a full blown repo. In this way we are not cluttering our public github presence.

https://gist.github.com

If they are part of the bigger project you mentioned to me regarding open sourcing parts of our delivery infrastructure, then by all means use a repo. Please do note that a repo needs steady maintenance as described in our OSS policy (https://github.com/Haufe-Lexware/open-source)

Regarding docker hub I suggest you follow Martins lead and publish it under the haufelexware org
https://hub.docker.com/r/haufelexware/wicked.portal/

Please note to use our public build chain to push from github to docker hub. Please do not use github as repo for internal deployments. Please maintain a so called ‘airgap’ between our public repos and public artifacts and internal repos and internal deployments. If you want to use the same code for the internal infrastructure (like we do for Wicked) please mirror the github repo to an internal repo (like bitbucket, or vice versa) and use the internal build chain for internal prod deployments.

(which reminds me that I probably should spell that out more clearly in the OSS guidelines)

Internal deployments are build internally using an internal repo
External OSS is build externally using Github.