Temporary suspension of GitLab Runner executors

Orekit development
1

Dear all,

I’m working on deploying a GitLab Runner Kubernetes executor, with the aim of providing the Orekit project with an elastic CI/CD platform (i.e. dynamic provisioning of the necessary resources).

In order to test this executor, I’m going to temporarily suspend the others and manually trigger pipelines on several projects or branches.

Don’t hesitate to get back to me if my tests go wrong and if you want me to reactivate the other executors.

I apologize in advance for any inconvenience caused.

Best regards

2

Is this expected to last long?
I am just finishing a very long (read months long) set of modifications and am pushing everything to the sub-atto-seconds-dates branch (which is a misnomer by the way).

3

Hi Luc,

Feel free to test the Kubernetes runner. Il would be a good test. :wink:

Sébastien

4

The worker seems work now:

I still need to fine-tune its configuration. I’ll continue tomorrow morning. In the meantime, I’ll leave it active and reactivate the other runners.

5

It doesn’t work. I will stop it.

6

Hi,

Some pipelines launched last night failed due to jobs being processed by the Kubernetes runner. The reason for the failure is quite simple: the GitLab timeout (3 minutes) on making the execution container available was reached. Two successful jobs started after 2min56s. :fearful:

On-demand node provisioning on the OVH Kubernetes cluster is slow… I’ll see if I can increase the GitLab timeout.

I also need to adapt the configuration of the Kubernetes executor to delegate cache storage to an S3 bucket.

7

I just increased it (180s => 300s).

B3-32 instances take a long time to become available, but they are fast, almost as fast as Luc’s runner. :slight_smile: