Setup CI/CD for the Pull requests

[jcubic]

It would be nice to have GitHub workflow that will build and upload the file to the server. It will make it easier to manage. When this is done for this repo it could be replicated for different repositories.

This is continuation of discussion in https://github.com/schemedoc/cookbook/pull/43

[jcubic]

How this script know the password and username? I never used rsync to copy to an external server (I only use to backup files locally), but I think to use SSH you need some extra stuff in the command.

<https://github.com/schemedoc/docs.scheme.org/blob/master/scripts/upload.sh>

[lassik]

We don't use passwords; we use SSH key pairs only. GitHub probably has some place for a "deploy key"?

[arthurgleckler]

On Sat, Apr 6, 2024 at 1:05 PM Jakub T. Jankiewicz @.***> wrote:

How this script know the password and username, I never used rsync to copy to external server, but I think to use SSH you need some extra stuff in the command.

< https://github.com/schemedoc/docs.scheme.org/blob/master/scripts/upload.sh

We have our public SSH keys installed on the server so we can use rsync without transmitting passwords.

Message ID: @.***>

[lassik]

You don't need any extra stuff in the command. The SSH client on your computer knows your keypair and uses it.

[lassik]

Documentation on deploy keys

On sexond thought, it might be easier if our server pulls the git repo and starts a Docker container to build the site. The CI action would only have to notify the server via a special HTTP endpoint.

[jcubic]

I use secrets for this. The link you provided is how to set up git locally with SSH.

ALso github actions already use Docker images (at least I think they use docker) but if you want to do this on the server then you will need to setup everything on the server.

To trigger the build you can use web hooks. I have it in one project.

[arthurgleckler]

ALso github actions already use Docker images (at least I think they use docker) but if you want to do this on the server then you will need to setup everything on the server.

We serve the pages from our own server, so we'd have to get the result of any build done on Github to our server, anyway. At that point, doing the build on our server is just fine.

[jcubic]

The problem with building on the server is that we can't test if the build pass and show error if this doesn't happen on GitHub. If we have built that fails, GitHub will send an email and show that there is an error. Also, we can run build without deploy when PR is created. This will make sure that someone didn't put something that break the build (e.g. happen by a typo).

[lassik]

We should gradually reduce the dependency on GitHub, not increase it. Docker is a good tool for this, since the containers work the same way on different GIt hosts and also on a Linux server. I would prefer if each repo has a Containerfile and a build script that runs in that container. If we have that, we can do builds on both GitHub CI and our server as needed.

(Pull requests can be checked by GitHub CI without uploading the build products. Pushes to master can either be rsynced to the server or the server can be notified via HTTP to fetch them.)

[arthurgleckler]

On Mon, Apr 15, 2024, 1:56 PM lassik @.***> wrote:

We should gradually reduce the dependency on GitHub, not increase it. Docker is a good tool for this, since the containers work the same way on different GIt hosts and also on a Linux server. I would prefer if each repo has a Containerfile and a build script that runs in that container. If we have that, we can do builds on both GitHub CI and our server as needed.

I agree. SRFI operates on a long time scale. Who knows what will happen to Github? Some people already want us to switch away from it for political reasons. I haven't been willing to do that because it's so easy to replicate repos. But it's still good to minimize our dependencies.

Thanks very much for the suggestions. Having Github invoke builds on our server is a great compromise.