I believe this discrepancy means that we are not able to build a cohesive backend set of modules.
https://jenkins-aws.indexdata.com/job/Automation/job/folio-testing-backend01/504/ failed overnight, with what appeared to be the following error (I ignore the multiple 404 errors that sometimes appear):
This looked like it might be an transient error, so I kicked off another build to check. https://jenkins-aws.indexdata.com/job/Automation/job/folio-testing-backend01/505 failed the same way.
The error appeared related to either a lookup in the folio-registry for the module or fetching the docker image.
Fetching the module descriptor from the registry seems to work ok (http://folio-registry.aws.indexdata.com/_/proxy/modules/mod-login-saml-1.1.1-SNAPSHOT.26) and the docker image appears to be present (https://hub.docker.com/r/folioci/mod-login-saml/tags/ )
This is the same version of mod-login-saml that was deployed in previous folio-testing builds and is in the folio-snapshot build that succeeded.
Looking at it again, it appears the post to Okapi was the aspect that failed. There doesn’t appear to be an error message.
mod-login-saml relies on the authtoken, configuration and users interfaces. Based upon https://github.com/folio-org/folio-ansible/blob/e65a28f2ab64d95ab952271c993a035af9528bf9/group_vars/testing it looks like `mod-authtoken`, `mod-configuration` and `mod-users` come before it in the list, so should fulfil those requirements.
It turns out that mod-authtoken changed to provide authtoken version 2.0 yesterday (https://github.com/folio-org/mod-authtoken/commit/fdba6e9371618adf1bebf39964127ac3b54787a6).
It looks like this mismatch is what causes the backend build to fail.