can integration tests follow things through to earthworks?

[jmartin-sul]

This came up in post-standup discussion related to https://github.com/sul-dlss/argo/issues/4057

I think the verdict was that we can't do this, but there was a lot of discussion, and I was a little unsure my notes were 100% correct. Here's what I have:

• @ndushay : can integration tests follow things through to earthworks?
  • @andrewjbtw : purl fetcher pushes things to earthworks? same process as how stuff gets into searchworks?
  • and we don't have searchworks stage, so that process isn't running in stage, so we can't test this in stage using infra integration tests?

But I must've gotten that at least partially wrong, because there is https://searchworks-stage.stanford.edu/ and there's https://earthworks-geoserver-stage-b.stanford.edu/

Could someone close this ticket if it is indeed not actionable, or point me in the right direction for amending it if it is?

[andrewjbtw]

I checked on the connection in stage and it looks like we actually can push SDR-stage to earthworks-stage. We can't remove from earthworks-stage but new items do appear to show up there. So we could test this as long as each item we test is new (since old items will always be there regardless of whether things are working).

It's searchworks in stage where connections remain unclear. There is a searchworks-stage, the question is how things get into that searchworks-stage.

[andrewjbtw]

Example:

• earthworks-stage
• same item in argo-stage

[mjgiarlo]

@andrewjbtw If memory serves, this is the instance of SW we integrated with SDR stage: https://searchworks-preview-stage.stanford.edu/ I'm not sure how integrated it is, or if QA stuff also flows to this instance at the moment.

Here's the same example geo object in that env: https://searchworks-preview-stage.stanford.edu/view/bd704cc3792

[andrewjbtw]

Right, the system exists but it's unclear to me if we can expect releases to show up there in a reasonable amount of time.

[andrewjbtw]

Also, searchworks-preview only gets druids released that don't have MARC records. If they have MARC records, release follows a different route via FOLIO and probably shows up in the SW instance connected to that, which may or may not also get non-MARC releases from SDR stage.

I'll back away from the pegboard full of index cards and photos now.

[mjgiarlo]

@andrewjbtw Not sure if this is interesting or not, but I deposited a test object in H2-stage, then went to Argo and manually released it to SW, and this showed up ~5 minutes after: https://searchworks-preview-stage.stanford.edu/view/vt712gh3683

[andrewjbtw]

It's definitely interesting. I've never seen stage release happen that fast. Maybe it's always supposed to work but sometimes purl-fetcher-stage isn't operating properly. I don't generally report stage issues to the Access team if they're not working in an SDR-related environment at the time.

So we could integration test all the way through to SW release in the future with the understanding that if the SW release part doesn't work, someone will have to determine which part of the release process is implicated.

My understanding has been that as long as

1. this XML goes out in the public XML

   <releaseData>
   <release to="Searchworks">true</release>
   <release to="Earthworks">true</release>
   </releaseData>

2. The rest of the XML is parseable
3. The item/collection does not have a MARC record

then that's as far as SDR infrastructure goes and the item should get picked up by purl-fetcher

[edsu]

This can be closed once we create a ticket for writing an integration test, since the answer seems to be Yes.

[mjgiarlo]

We can now close this.