add cron function to to populate usfm from primary hls #16
Conversation
| let apiBaseUrl = `${WACS_API_URL}/repos`; | ||
|
|
||
| // ie "01-GEN" | ||
| let usfmRegex = /(\d{2})-(\w{3})/i; |
There was a problem hiding this comment.
This admittedly has me a little uneasy- while the filename structure is unlikely to change, is there a better way to get the information here?
There was a problem hiding this comment.
@jsarabia -> Understandable. I had reached for that regex to derive the book/chapter since all these files should be scripture. I think the only other way to derive this data would be too parse the resource container's manifest and see if a file path is included in the "projects" section, and fallback to regex filename and check internally if not.
@PurpleGuitar -> Thoughts?
There was a problem hiding this comment.
Great points. I think we should grab the filename from the manifest if possible rather than assume it. In the future, if we add support Scripture Burritos, we can't depend on standardized naming but we can depend on the manifest to point to the right file.
PurpleGuitar
left a comment
PurpleGuitar
left a comment
There was a problem hiding this comment.
I agree with Joe -- we should pull the file name out of the manifest.
Deploying languageapi with
|
| Latest commit: |
c358f4b
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://517cee8b.languageapi.pages.dev |
| Branch Preview URL: | https://dev.languageapi.pages.dev |
This PR add's support for showing information for getting urls for GL usfm. The rendering pipeline already handles this for HL's, but doesn't process GLs quite the same and was thus missing. Ultimately this is derived info from wacs in a sense. There's a few dep upgrades below, but mostly you can read through controller/src/functions/glUsfmSources.ts. I tried to just comment what's it's doing. But in a two sentences, it's a cron that looks at any existing GL content for which we know wacs info. For that content, reach out over WACS api to get a tree representation, adn for any usfm files in that tree, store the gitea RAW url.
The main thing that was an interpretive question was that I did put some filters on what I was looking for, namely these lines.
prod...dev#diff-0894b29cbfc38881937389e42549c01f14800a61c92dfc8e5a1250120626caf7R123-R134
I only wanted to do at leat "active" cause there's a lot of junk and noise to filter through from Writer GL projects.
Last thing, Dev language api doesn't have anythign that matches this criteria, (i.e. no there's no language metadata in dev passed from port), so I don't have test data in dev to show you, but the end results looks like this (using a local copy of production data).