Github Actions setup for Store.X

[Michal Hajas]

Hello all,

We are approaching a state where we will add new store.x implementations (HotRod and JPA) to the Keycloak codebase. With this addition, we would like to include as many tests as possible into Github Actions.

For ConcurrentHashMapStorage that is already present in the upstream, we introduced 3 new actions/stages into our GHA that are testing whole integration-arquillian base testsuite.

Is it feasible to add 3 stages for each storage implementation into GHA or is it too much? 

If it is too much, should we somehow reduce the number of tests running? Should we run the whole testsuite and randomize storage that is used? Or do you have any other ideas how to approach this?

Best regards,

Michal

[Pedro Igor Craveiro e Silva]

I see no issue other than GHA not managing to handle the load.

Some time ago, when trying different approaches to test Dist.X (using matrix for different jdks/jres, mainly) GHA did not work at all and I think it was related to the number of parallel jobs. Not sure you are going to face the same issues as I.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CACv4bCQ7UGUbV-XihdRHSGkzLb3HWZ9wrA1CeokLqPo%3DeoyUsQ%40mail.gmail.com.

[Dominik Guhr]

Don't know if it helps, but w.r.t. the matrix / concurrency limits, FYI: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration this page contains the actual concurrency limits etc. for github actions.

[Hynek Mlnarik]

I'd rather have only one extra run for the full-blown store (Hot Rod + JPA) once the tree storage gets into a usable shape, and ideally consolidate even that somehow with CHM.