Staging of website

[lukasmittag]

This ticket is about how to handle staging and testing in the future. Since locally testing the website does not guarantee that it works in the designated github page. What we did in the past we had a staging CI that was a bit different to the one in this repository. Once you've created a PR to boschglobal/master it would build the website for boschglobal and you could check if everything works. Such a staging step is needed for bigger changes. For minors we should be able to merge just by looking at code.

[erikbosch]

I see the value, but the problem by using "boschglobal" is that only Bosch employees can use it. If nothing else we should better document what you need to do to test github staging in "your own staging environment", where "your own staging environment" can be either a Github organization (like boschglobal) or your personal github account (if possible). Something like "search for boschglobal and replace with your own orga".

What we possible should discuss is if we want to use boschglobal as default staging name, or rather something generic like my-organization.

[SebastianSchildt]

What you as an comitter can always do - if there is an external PR - push it to Boschglobal yourself for testing. If I were an external I would anyway likely give my chances blindly OR test it in local hugo. Even with instructions, I would probably not try to deploy in my own fork.

WHAT I still remember about the old/current way: maybe it needs to be documented more clearly for US what is build and where on bsochglobal. and an issue was always, that in the end there was always the issue that the fork was not really synced, as some CI scripts where different than master/main here. That was always confusing, but I am not sure if it can be fixed. Although I think it would be ok the have hardocded "if run on boschglobal do this, else that" kind of logic in the CI. Because I can't see a reason why anyone would want to fork this to use "productively"