What pipeline for Orekit website?

Website & collaborative platform
1

In order to bring Orekit one step more in the CI/CD process, I’m looking into the building process of the Orekit’s website.

Currently, there are 2 sites:

So,the question is: when to deploy in one site or in the other. I think there are two main strategies: GitOps or environement promotion.

In GitOps philosophy, the only interface for the developer is the Git repository. All CI/CD actions are consecutive to a git operation (commit, merge on a given branch…). Following this concepts, we can imagine:

On the opposite, the promotion environment states that the pipeline can support manual operation, and this is strictly the same content that is deployed on staging environment and then production environment.
Following such idea, we can imagine a single pipeline, with a single main master branch (a Github flow):

  • when commit/merge on master, the site is deployed in test.orekit.org
  • following that action, the next one is controlled by a manual action (fully supported by Jenkins or GitLab-CI),
  • when activated, the site is then deployed in the www.orekit.org

Any comments?

I suspect that the first one is simpler for the web site as the target of the deployment must be set when compiling the site. A simple promotion will not succeed.

2

Hi @gbonnefille !

Is there any complicated process involved in the generation of the website ? Something that could potentially go wrong without being noticed by the CI/CD process ? If so, I suspect the ‘environment promotion’ philosophy would be better, because it would allow for a manual inspection before the ‘official’ deployment.

In all other cases, I would agree with you and have a preference for the gitOps approach. If the CI/CD process is reliable, I think this approach is indeed simpler

3

Not at all. The static website is generated by Jekyll and then pushed through a scp command. The only parameter that can vary is the target (test.orekit.org or www.orekit.org), defined in the _config.yml file.

4

I already have a solution for that: it is possible to overwrite _config.yml parameters by giving many config files. I have a running example.

5

I would be happy with a fully automated solution, so the gitOps approach is more appealing to me.

6

Here is it: the website publishing is now automated. :robot:

A (minimal) description of the workflow is documented.

Updating the website is now more easier than ever and accessible to anybody.

1 Like
7

Great job @gbonnefille! This automation is going to facilitate review and publication of proposed changes.