Pros and cons of Azure Pipelines compared to CircleCI

Operational management
1

I am looking to see if there are any significant advantages in switching from Azure Pipelines to CircleCI for Continue Testing of dsBase and dsBaseClient.

Do you have any opinions?

Stuart

2

Hi,

Why not just using github actions?

Yannick

3

If you have self-hosted GitLab, it comes with a CI/CD very similar to GitHub Actions: Get started with GitLab CI/CD | GitLab

4

I will have a more detailed GitHub Actions.

Stuart

5

Then you can have a look at these github actions for R

6

I think we did start with circle years ago, but we hit a run-time threshold which is why we ended up moving to the azure pipelines approach. To be fair though, we were doing a full build and test so it was testing the bleeding edge of the full stack. I assume you are looking at more of a container based approach with just the actual tests run?

7

Hi Olly, I remember DataSHIELD using “Travis CI” before “Azure Pipeline”, at the time of switching “Travis CI” was very unreliable, and more likely to fail than the tests.

At the moment the CI process is to long to be practical, at over 2h30m. Being able to cache parts of the process is the aim, but the contains of a new PR could invalidate cached images.

Stuart

8

Yeah, 2.5 hours to too long. Do you have a feel for how long just the test take?

For a given profile/opal container combination I guess we only need to show that it works at the time the container was built. There would probably be a bit of flex around the client side libs affecting a version change (if R changes on my laptop does that break the clinet side libs etc?), but it is probably reasonable to ignore that until problems arise.

Could you have a fairly vanilla rock container that doesn’t have dsbase in it, then just add that a PR time? As long as the target branches get passed env vars it should be possible to align them.

9

At the moment dsBaseClient tests take 1h20m, but that is with the attempted generation of an coverage report, which does add overheads. Also, is only with Opal not including Armadillo. CI is intended to test packages changes which aren’t in existing profiles.