Stream: committers
Topic: Build Problem
Grahame Grieve (Aug 14 2019 at 23:19):
@Josh Mandel see https://build.fhir.org/ig/HL7/UTG/ - this failed to build - but it's not listed in https://fhir.github.io/auto-ig-builder/builds.html
Josh Mandel (Aug 14 2019 at 23:29):
Did it trigger a notification here?
Grahame Grieve (Aug 14 2019 at 23:34):
looks like no
Grahame Grieve (Aug 14 2019 at 23:36):
it does have a webhook for https://us-central1-fhir-org-starter-project.cloudfunctions.net/ig-commit-trigger (push)
Josh Mandel (Aug 14 2019 at 23:49):
Okay -- there are certainly some failure states that might prevent a message from coming through. I will plan to take a look at this tomorrow unless there is urgency?
Josh Mandel (Aug 15 2019 at 00:06):
(in any it looks like the build was triggered and it failed because the publish-box was missing.)
Grahame Grieve (Aug 15 2019 at 02:10):
yes that will be why. But it should go into the list of IGs, right?
Josh Mandel (Aug 15 2019 at 18:16):
Yes -- actually UTG was showing up as failed in https://fhir.github.io/auto-ig-builder/builds.html but it was put at the bottom as "unknown date of failure". There are two issues: first is that no qa.json file is generated; and second is my logic for parsing dates out of build.log was wrong. I fixed the date parsing there, so UTG appears in the right spot. (I'm still unclear on why no qa.json is generated though.)
Grahame Grieve (Aug 15 2019 at 18:40):
thx. I'll investigate the qa.json issue
Rob Hausam (Aug 15 2019 at 18:48):
As far as I can see, this is the issue with the UTG build:
Exception in thread "main" java.lang.Error: The auto-build infrastructure does not publish IGs that contain HTML pages without the publish-box present. For further information, see note at http://wiki.hl7.org/index.php?title=FHIR_Implementation_Guide_Publishing_Requirements#HL7_HTML_Standards_considerations
Ted and I discussed this yesterday. Does UTG need to somehow be an exception to the publish box requirement, as it's not a typical IG? Or does that need to be updated in UTG? @Grahame Grieve
Grahame Grieve (Aug 15 2019 at 18:59):
no it's very much not an exception to the version handling requirement
Grahame Grieve (Aug 15 2019 at 18:59):
I committed a fix for this
Grahame Grieve (Aug 15 2019 at 18:59):
(to UTG)
Rob Hausam (Aug 15 2019 at 19:11):
sounds good
Grahame Grieve (Feb 06 2020 at 22:13):
@Josh Mandel the current failing build is caused by a change in https://build.fhir.org/ig/qas.json:
it used to say
"repo": "nrdavis1/HSPCFHIRtest"
But it's changed to
"repo": "nrdavis1/HSPCFHIRtest/branches/master/demo/qa.json"
Grahame Grieve (Feb 06 2020 at 22:13):
at least, i think that's what it used to say
Josh Mandel (Feb 06 2020 at 22:14):
Ooh, indeed. So, this is a change I made to support branches other than master -- didn't realize you have a dependency on qas.json!
Josh Mandel (Feb 06 2020 at 22:15):
So: I can change this back, or we can update the build. I'd prefer to keep the full paths, because it opens up the possibiliy for doing more downstream. But let me know.
Grahame Grieve (Feb 06 2020 at 22:15):
hmm
Grahame Grieve (Feb 06 2020 at 22:16):
can you explain how it supports branches other than master?
Grahame Grieve (Feb 06 2020 at 22:16):
it's the 'qa.json' bit that's the real problem.
Josh Mandel (Feb 06 2020 at 22:16):
The idea is that each qa.json file identifies which org, repo, and branch it's associated with.
Josh Mandel (Feb 06 2020 at 22:17):
Like, you'd be okay with "nrdavis1/HSPCFHIRtest/branches/master/demo" or "nrdavis1/HSPCFHIRtest/branches/master/" ?
Grahame Grieve (Feb 06 2020 at 22:17):
hmm. ok. so in that URL there, what does 'demo' mean?
Grahame Grieve (Feb 06 2020 at 22:17):
I'd be ok with anything if I know what it means and how I have to process it
Josh Mandel (Feb 06 2020 at 22:17):
Um, I'm not sure. demo is a directory inside the output, where qa.json resides.
Grahame Grieve (Feb 06 2020 at 22:18):
but I've been ignoring the whole branching thing when processing the list... I'm not sure what the right behavior is
Josh Mandel (Feb 06 2020 at 22:18):
Looks like maybe a mistake: https://github.com/nrdavis1/HSPCFHIRtest/blob/master/demo/qa.json is checked into github!
Josh Mandel (Feb 06 2020 at 22:19):
So, this gets at the question of how qas.json is created in the first place: by scanning the directory tree for any qa.json files. But I can filter that further, to make sure I only look at qa.json files in the root of the output of a successful build.
Grahame Grieve (Feb 06 2020 at 22:19):
so you're just finding a qa.json somewhere ? the other ones:
cqframework/opioid-cds-r4/branches/Recommendations_Test/qa.json
that makes sense
Grahame Grieve (Feb 06 2020 at 22:19):
qa.json that I produce will always and only be in output
Josh Mandel (Feb 06 2020 at 22:20):
Right, that one in cqframework is fine. OK. so two follow-ups:
1) I'll update my find command to be more specific, and
2) Maybe the author of https://github.com/nrdavis1/HSPCFHIRtest/blob/master/demo/qa.json wants to clean up that repo (@Nathan Davis I think) -- but obviously we should be robust to stuff like this.
Josh Mandel (Feb 06 2020 at 22:26):
On (1), deploying a fix now. Will then trigger a rebuild of qas.json
Josh Mandel (Feb 06 2020 at 22:31):
OK, done.
Josh Mandel (Feb 06 2020 at 22:32):
So you'll still see outputs like "repo": "HL7/cimi-vital-signs/branches/master/qa.json", but never to sub-paths like demo.
Josh Mandel (Feb 06 2020 at 22:32):
If you'd like, I can also strip the final path segment off of the output.
Grahame Grieve (Feb 06 2020 at 22:36):
no it's fine. I'm doing a release shortly that fixes it
Josh Mandel (Feb 06 2020 at 22:39):
Thanks, and sorry for the change without notice! (These paths were previosuly all kinds of broken, with random truncations on branches other than master.)
Chris Moesel (Feb 06 2020 at 22:59):
@Josh Mandel and @Grahame Grieve -- I haven't looked into it yet, so feel free to disregard if you'd like. But... SUSHI's ability to resolve #current versions of IGs just broke. And I think it resolves from the build server. So I'm guessing that maybe some of those layout changes affected our IG resolution code for #current versions. And I expect that if others (Forge?) had similar code, it might affect them too.
Chris Moesel (Feb 06 2020 at 22:59):
But right now that is a hypothesis. I can let you know when I've looked into it and have some proof one way or another.
Josh Mandel (Feb 06 2020 at 23:11):
Thanks for the heads up -- please let me know what you find. The joys of iteratively discovering that an initially single-purpose file (designed to fuel the build dashboard) has become a dependency for a bunch of other tools ;-)
Josh Mandel (Feb 06 2020 at 23:11):
Sorry for any trouble with this.
Grahame Grieve (Feb 06 2020 at 23:32):
SUSHI's ability to resolve #current versions of IGs just broke
I expect that's what we're talking about in this thread
Grahame Grieve (Feb 07 2020 at 01:45):
@Josh Mandel hate to bug you, but this thread was kicked off when @Peter Williams snomed ig didn't build... but it is not listed in the IG page at all right now.
Chris Moesel (Feb 07 2020 at 02:25):
OK, so I can confirm that it is the change to the repo property in the qas.json that is causing the issue for SUSHI. We're actually following the exact formula that Grahame gave us for locating the current package, so it's no wonder we both were affected. ;-)
how it works is that you access https://build.fhir.org/ig/qas.json. then, you sort that by date, and then iterate that json array from most recent to oldest to find either the package-id or canonical url that you are looking for the #current package for, and then fetch the package from https://build.fhir.org/ig/[repo]/package.tgz
https://chat.fhir.org/#narrow/stream/179239-tooling/topic/NPM.20package.20system/near/183582585
Chris Moesel (Feb 07 2020 at 02:30):
So I assume the fix is just to replace the trailing /qa.json with /package.tgz... Should be easy enough.
Grahame Grieve (Feb 07 2020 at 03:20):
well.... I changed my pproach to just use the first 2 folders - org/repo, and drop all the branch information - I'm not sure when/whether I want the branch or the root. For the moment, I'm using the root only
Chris Moesel (Feb 07 2020 at 03:27):
Ah, OK. Then we'll match your approach. It probably wouldn't be good if we used a different approach than the publisher. Thanks for the heads up. But in that case, sorting by date probably doesn't matter, right? I mean, I expect the the first two folders (org/repo) will probably be the same for all of them? We'll still do the sort just in case though.
Grahame Grieve (Feb 07 2020 at 03:31):
yes I still sort by date too
Ward Weistra (Feb 07 2020 at 04:16):
@Chris Moesel Thanks for the Forge ping, but we haven't built in logic yet that would try to find (#dev or) #current packages on the build server. We'll likely expose those versions from Simplifier too, so we'll need to think about generalizing that package logic anyway.
Josh Mandel (Feb 07 2020 at 12:12):
Josh Mandel hate to bug you, but this thread was kicked off when Peter Williams snomed ig didn't build... but it is not listed in the IG page at all right now.
No bother, but I do see it there now. In a success state from 10 hours ago. Is the issue that it is was not showing up when it fails?
Grahame Grieve (Feb 07 2020 at 21:20):
I think so
Josh Mandel (Feb 07 2020 at 21:25):
hmm, OK. Right now I see other failed builds, so it must be something specific to the snomed IG. Maybe save a copy of qas.json and builds.json if this happens again?
Grahame Grieve (Feb 07 2020 at 21:27):
ok
Nathan Davis (Feb 10 2020 at 21:28):
I've cleaned up (deleted actually) my repo that was mentioned last Friday. (https://github/nrdavis1/HSPCFHIRtest). I have a question tho. Why was this repo part of whatever process you were running that flagged it as an issue? It wasn't an HL7 official repo.
Grahame Grieve (Feb 10 2020 at 22:40):
we were doing maintenance on the ci-build subsystem, and yours uses the ci-build.
Grahame Grieve (Feb 10 2020 at 22:44):
(as it should)
Last updated: Apr 12 2022 at 19:14 UTC
