Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Staging of website #76

Open
lukasmittag opened this issue Mar 19, 2024 · 3 comments
Open

Staging of website #76

lukasmittag opened this issue Mar 19, 2024 · 3 comments
Assignees
Labels
question Further information is requested

Comments

@lukasmittag
Copy link
Contributor

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.

@lukasmittag lukasmittag added the question Further information is requested label Mar 19, 2024
@erikbosch
Copy link
Contributor

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
Copy link
Contributor

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"

@erikbosch
Copy link
Contributor

I added some documentation on how you could use a fork for testing in the wiki at https://github.com/eclipse-kuksa/kuksa-website/wiki/Test-and-Release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants