Should we discontinue the Jenkins integration tests?

[AaronSpieler]

I think we should remove the Jenkins integration tests , if they don't serve any explicit purpose.

#661, but in particular #602 have revealed that the build were out of sync with the dependencies as specified per requirements.txt of gluonts. This going unnoticed thus far raises the question of whether we should continue to use them, and what exact purpose they serve.

I would like your feedback.

[jaheba]

Yes, I agree that we should move entirely from Jenkins. However, I think Jenkins currently covers some areas, we don't with GitHub Actions:

• GPUs (?)
• mxnet-mkl
• doc-builds

[AaronSpieler]

Regarding mxnet-mkl: its just mxnet with an Intel CPU hardware acceleration library together (https://software.intel.com/en-us/articles/getting-started-with-intel-optimization-for-mxnet). I don't think we need it unless we want to specifically test mkl support, which is not the main purpose of the Jenkins build if I'm not mistaken.

Regarding the GPU support: can't we create some GitHub Actions that test the same?

Regarding the doc-builds: isn't that covered by the GitHub integration test called: "Doc Build / build (pull_request)"? Or what are the differences?

[jaheba]

Regarding the doc-builds: isn't that covered by the GitHub integration test called: "Doc Build / build (pull_request)"? Or what are the differences?

There is another build which actually uploads the docs to s3.

[AaronSpieler]

@jaheba Whats the status on this?

[jaheba]

I've disabled them some time ago and no one seems to have noticed or complained about it :)

[AaronSpieler]

I've disabled them some time ago and no one seems to have noticed or complained about it :)

So should we also remove the ./ci folder, or is that unrelated?

[jaheba]

No, not yet.