[chennes]

Migrate from our current staging-only workflow to one that includes production deployment. Note that this is currently safe to test in either mode since the production server isn't active in the nginx configuration yet.

[marcuspollio]

Hi @chennes
Thanks for the PR and adding the vars/secrets!

Some questions to be sure I understand what is going on:

1. The script in tools/workflows/deploy-website.sh does not need any change as it is the same used for both staging and production deployments, and the one is the repo is 100% the same as the one on the FreeCAD server/containers. If yes, we could just tweak its top comment so it refers to both staging and production.
2. The deploy workflow added by this PR allows to trigger both staging or production deployment manually. In other words, contributors/maintainers who want to launch these workflows are expected to know the order in which to run them and what to check. Not sure if we should add a condition to the workflow for the production environment case to ensure that the deployment to staging with the same git HEAD was successful. But in any case, I suppose we need to document this in some way. Is the Dev Handbook the appropriate place? Do you have any other suggestions?
3. Once this PR is merged and it works, should the previous STAGING_ keys be removed?
4. Could you clarify what "safe to test since the production server isn't active in the nginx configuration yet" means? What should happen if say, I were to test this workflow in the production mode? Should the workflow simply fail?

[chennes]

1. The script in `tools/workflows/deploy-website.sh` does not need any change as it is the same used for both staging and production deployments, and the one is the repo is 100% the same as the one on the FreeCAD server/containers. If yes, we could just tweak its top comment so it refers to both staging and production.

Yes, that's correct.

2. The `deploy` workflow added by this PR allows to trigger both staging or production deployment manually. In other words, contributors/maintainers who want to launch these workflows are expected to know the order in which to run them and what to check. Not sure if we should add a condition to the workflow for the production environment case to ensure that the deployment to staging with the same git HEAD was successful. But in any case, I suppose we need to document this in some way. Is the Dev Handbook the appropriate place? Do you have any other suggestions?

Yes - I think it's reasonable to expect project maintainers to know the process, but we also have some protections. Because the two paths use different environments, I have them set up slightly differently. Maintainers are allowed to override the "second set of eyes" check on Staging, but not on Production. Someone other than the action's original runner must approve the run to Production, and you can only deploy to Production from main, not from any other branch. But yes, documenting all of this someplace, and making sure everyone on the project knows how it works, is an important step here.

3. Once this PR is merged and it works, should the previous `STAGING_` keys be removed?

Yes, both from the actions and from the on-server authorized-keys file.

4. Could you clarify what "safe to test since the production server isn't active in the nginx configuration yet" means? What should happen if say, I were to test this workflow in the production mode? Should the workflow simply fail?

It won't fail, it will actually appear to work perfectly, but only someone with direct server access will be able to see that anything changed. This server exists and is ready to go, it's simply that "freecad.org" is not being fed from it, at the nginx sites-available level. So deploy to Production all you want for the time being, no one can see it.

[marcuspollio]

Thanks for the detailed reply!