Stream: committers
Topic: ig-build notifications
Grahame Grieve (May 18 2020 at 23:24):
hey @Josh Mandel all the ig-build notifications on the #committers/notification channel are saying that errs = 0, irrespective of how many errors they actually have. Where do you get that value from?
Tim Blake (May 18 2020 at 23:46):
This has been the case for the last week or so. No errors showing in qa.html either.
Josh Mandel (May 19 2020 at 01:24):
If qa.html is wrong, there's probably a deeper cause. But the Zulip notification is built like https://github.com/FHIR/auto-ig-builder/blob/3a616d751efcd3caf7d7849143f8caf423ac8995/images/ig-build/builder/builder.py#L24 (basically, parsing out a comment from qa.html).
Grahame Grieve (May 19 2020 at 05:37):
@Tim Blake I don't know what this means:
No errors showing in qa.html either.
I get errors in qa.html.
Grahame Grieve (May 19 2020 at 05:38):
e.g. https://build.fhir.org/ig/Healthedata1/sample-ig/branches/master/qa.html
Tim Blake (May 19 2020 at 05:43):
I don't - http://build.fhir.org/ig/timblake78/nsw-health-itoc/branches/master/qa.html
Grahame Grieve (May 19 2020 at 05:44):
I'm not sure what you mean. you don't have any errors?
Rob Eastwood (May 19 2020 at 05:45):
The qa.html linked above (for Healthedata1) that does have errors is using IG Publisher Version: v1.0.89-SNAPSHOT.
I think the 0 errors started occurring after v1.0.90
Grahame Grieve (May 19 2020 at 05:46):
what errors do you think should show?
Tim Blake (May 19 2020 at 05:59):
I can't remember what they were, but I know that there were about 12 of them prior to a few IG publisher builds ago
Rob Eastwood (May 19 2020 at 22:51):
As a demonstration, I created a simple Patient instance with this structure; note the clearly out of place elements:
<?xml version="1.0" encoding="UTF-8"?>
<Patient xmlns="http://hl7.org/fhir">
<id value="example-fail-01"/>
<name>
<use value="usual"/>
<family value="Smith"/>
<given value="Jack"/>
</name>
<!-- these elements are clearly out of place and should invoke errors -->
<something value="else"/>
<meta>
<something value="other"/>
</meta>
<name>
<use value="official"/>
<family value="Smith"/>
<given value="John"/>
<given value="Jacob"/>
<given value="Jingleheimer"/>
<period>
<end value="2001-01-01"/>
</period>
</name>
<gender value="male"/>
<birthDate value="1955-05-30"/>
</Patient>
Using IGP v1.0.94, there are no errors on the command line; viz:
onGenerate:
Generating Summary Outputs (00:27.0979)
Sending Usage Stats to Server (00:36.0653)
Jekyll: Source: C:/work/git/fhir-ig-experiment-01/temp/pages (00:44.0766)
Jekyll: Generating... (00:44.0766)
Jekyll: done in 1.839 seconds. (00:46.0605)
Installing fhir.ig.experiment.01#dev to the package cache
Fetching:
Installing: done.
Checking Output HTML (00:47.0106)
found 476 files (00:47.0125)
... 476 html files, 0 pages invalid xhtml (0%) (00:48.0030)
... 20143 links, 0 broken links (0%) (00:48.0030)
Build final .zip (00:48.0030)
Final .zip built (00:48.0454)
Finished. 00:27.0647. Validation output in C:\work\git\fhir-ig-experiment-01\output\qa.html
Errors: 0 Warnings: 0 Info: 0 (00:48.0876)
Done
And the QA report displays:
image.png
Using IGP v1.0.89, the command line indicates 3 errors:
...
Build final .zip (00:51.0223)
Final .zip built (00:51.0654)
Finished. 00:27.0781. Validation output in C:\work\git\fhir-ig-experiment-01\output\qa.html
Errors: 3 Warnings: 0 Info: 0 (00:52.0080)
Done
And the QA report displays this:
image.png
Richard Townley-O'Neill (May 22 2020 at 06:51):
@Grahame Grieve
ig publisher (v95) still ignores all errors when doing a local build. It does report warnings and information.
Rob Hausam (May 23 2020 at 14:43):
@Grahame Grieve Yes, I'm seeing the same thing. After reading this I decided to recheck our newly published IPS IG by building with 1.0.89 instead of 1.0.95 - and 5 errors showed up (compared to 0 with 1.0.95). Two of the errors were straightforward and quite egregious (apparently due to a copy-paste issue). When a constraint for Observation.specimen was added to two of our Observation result profiles, the constraint was specified as a reference to the IPS Specimen profile but with a type of CodeableConcept (instead of Reference) - and the version 1.0.95 Publisher and qa.html didn't report the error :( The other three errors are less obvious, showing up only on the example bundle as "illegal use of resolve() in discriminator - Multiple possible target type profiles on Composition.section:sectionResults.entry:results-observation" - but still they are not being reported with the 1.0.95 Publisher.
Rob Hausam (May 23 2020 at 14:50):
I had seen the "illegal use of resolve() in discriminator" errors before, and when they went away I thought that either our changes to the slicing had fixed the issue or that the slicing was now being handled more robustly by the Publisher/Validator (or both), so either way it was good now - but instead, apparently the issue was just being masked. :(
Richard Townley-O'Neill (May 26 2020 at 05:37):
@Grahame Grieve any news?
Rob Hausam (May 27 2020 at 21:02):
I'm still seeing this in 1.0.97. IPS has no errors reported, but this [profile] (http://build.fhir.org/ig/HL7/fhir-ips/branches/master/StructureDefinition-Observation-results-laboratory-uv-ips.html) contains this obviously incorrect code:
{
"id" : "Observation.specimen",
"path" : "Observation.specimen",
"type" : [
{
"code" : "CodeableConcept",
"profile" : [
"http://hl7.org/fhir/uv/ips/StructureDefinition/Specimen-uv-ips"
]
}
],
"mustSupport" : true
},
I'm planning to commit a technical correction for it (and the same issue in results-pathology) soon - but the error isn't being flagged.
Grahame Grieve (May 28 2020 at 08:19):
that's a nasty thing to do. I can't make a nice graceful error for that. Next IG publisher will halt with the error:
Grahame Grieve (May 28 2020 at 08:19):
Type mismatch processing profile http://hl7.org/fhir/uv/ips/StructureDefinition/Specimen-uv-ips at path Observation.specimen: The element type is CodeableConcept, but the profile http://hl7.org/fhir/uv/ips/StructureDefinition/Specimen-uv-ips is for a different type Specimen
Rob Hausam (May 28 2020 at 11:31):
Yes, precisely! That's obviously why you don't want it reporting "Errors: 0" regardless - it's easy for even stuff like that coming from copy/paste and an incomplete update to slip right through because it says everything is good. :(
Grahame Grieve (May 28 2020 at 12:50):
that one was never picked up as an error at all in the code
Grahame Grieve (May 28 2020 at 12:50):
that's why you were getting errors : 0.
Grahame Grieve (May 28 2020 at 12:50):
it took me 8 hours to nail this down :-(
Rob Hausam (May 28 2020 at 13:16):
@Grahame Grieve I'm really sorry about that. This was a relatively late addition and it didn't affect (because it wasn't even there) anything else that we have dealt with along the way. And what you just said doesn't quite match with what I saw, because when I went back to building the IG with Publisher v1.0.89, the error was picked up and appropriately reported by the code. So this really couldn't be why we were getting "Errors: 0", because we didn't get that with 1.0.89 (and presumably that would also have been true with many of the prior versions?), plus we and others also have seen the issue completely independently of whether this particular error is present or not.
Grahame Grieve (May 28 2020 at 19:09):
what was the exact error message in 1.0.89 then?
Grahame Grieve (May 29 2020 at 06:37):
I still can't reproduce this. I've run a bunch of IGs with both .89 and the current version, and I consistently don't see any errors reported by .89 not reported by the current IG publisher
Rob Hausam (May 29 2020 at 11:25):
Sorry - had to sleep. :) I'm working on getting the details for you.
Richard Townley-O'Neill (Jun 01 2020 at 05:07):
V98 reports the errors I was expecting. :tada: :grinning_face_with_smiling_eyes:
Richard Townley-O'Neill (Jun 01 2020 at 05:08):
Many thanks @Grahame Grieve
Grahame Grieve (Jun 01 2020 at 09:29):
you'll have to check again with 99
Rob Eastwood (Jun 01 2020 at 22:42):
Grahame Grieve said:
you'll have to check again with 99
Expected errors are displaying on QA report with v99 - thanks very much @Grahame Grieve
Rob Hausam (Jun 02 2020 at 03:09):
@Grahame Grieve Looks like you did indeed reproduce it. With 1.0.99 I'm now seeing the expected errors with IPS, too.
Ted Klein (Sep 10 2020 at 15:33):
After being fixed for quite a while, now the 1.1.20 of the Publisher is failing on the UTG ci build - this version works OK on my local machine environment with the git content. Error log does not show anything beyond "Generating Summary Outputs (06:40.0695)
Sending Usage Stats to Server (09:02.0275)
Jekyll: Source: /scratch/ig-build-temp-U51D5N/repo/temp/pages (09:05.0710)
Jekyll: Generating... (09:05.0710)" but the build does not go to completion. @Grahame Grieve @Josh Mandel I have no idea where to begin looking for the reason here. Jekyll does not seem to complete.
Josh Mandel (Sep 10 2020 at 15:41):
This IG has always been a bit of a special case -- in the past, has been a resource allocation issue. We're giving it 15Gi RAM currently; does it need more than this? Looking now...
Ted Klein (Sep 10 2020 at 15:59):
not sure. I give it 16G when I run it locally: java -Xmx16G -Xss1G -jar /Users/...
Ted Klein (Sep 10 2020 at 15:59):
it keeps growing as well - more resources added to it bit by bit every few days...
Grahame Grieve (Sep 10 2020 at 17:19):
Does Jekyll need more?
Ted Klein (Sep 10 2020 at 17:37):
finally the last bit of the log showed up: (09:01.0203)
Jekyll has failed. Complete output from running Jekyll: (09:37.0730)
Note: Check that Jekyll is installed correctly (09:37.0731)
Publishing Content Failed: Process exited with an error: 137 (Exit value: 137) (09:37.0731)
(09:37.0731)
Use -? to get command line help (09:37.0731)
(09:37.0731)
Stack Dump (for debugging): (09:37.0731)
org.apache.commons.exec.ExecuteException: Process exited with an error: 137 (Exit value: 137)
at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:153)
at org.hl7.fhir.igtools.publisher.Publisher.runJekyll(Publisher.java:5508)
at org.hl7.fhir.igtools.publisher.Publisher.runTool(Publisher.java:5412)
at org.hl7.fhir.igtools.publisher.Publisher.generate(Publisher.java:4878)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:848)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:694)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:8075)
Ted Klein (Sep 10 2020 at 17:38):
no idea what error 137 is
Jean Duteau (Sep 10 2020 at 17:39):
error 137 is "out of memory" :)
Ted Klein (Sep 10 2020 at 17:40):
ah well then there we have it
Ted Klein (Sep 10 2020 at 17:40):
my local build this morning:
Ted Klein (Sep 10 2020 at 17:40):
Validation Results for HL7Terminology
Generated Thu Sep 10 08:46:16 MDT 2020, FHIR version 4.0.1 for hl7.terminology# (canonical = http://terminology.hl7.org (history)). See Errors Only
Quality Checks
Publisher Version: IG Publisher Version: v1.1.20
Supressed Messages: 24 Suppressed Issues
Dependency Checks:
Package Version FHIR Release Canonical Web Base Comment
.. hl7.terminology 1.0.39 4.0.1 http://terminology.hl7.org HL7 Packages must have an id that starts with hl7.fhir.
HL7 Publication Rules:
package-list.json: No category entry for the registry category (talk to FHIR product director on #IG Creation for assistance). Note: existing IGs already have a category in the existing package-list.json - update your package-list.json from there
package-list.json: No entry found for version
HTA Analysis: UTG is exempt from terminology dependency analysis
Realm rules:
n/a
Previous Version Comparison: Unable to compare with previous version: Unable to find version history at http://terminology.hl7.org (Problem #1 with package-list.json at http://terminology.hl7.org: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 2 column 2 path $)
Summary: broken links = 0, errors = 494, warn = 1636, info = 43
Ted Klein (Sep 10 2020 at 17:40):
I am using 16G in my java call.
Josh Mandel (Sep 10 2020 at 18:25):
16Gb seems to work for the java build but not for Jekyll. That's alarming. @Ted Klein how much RAM is Jekyll using in your system, or how much do you have ovearll?
David Pyke (Sep 10 2020 at 18:26):
Th 16GB allocation might be blocking too much memory that jekyll is being starved
Ted Klein (Sep 10 2020 at 18:51):
I have 32G in this laptop I am running the build on
Ted Klein (Sep 10 2020 at 18:59):
Josh I am not sure how to even check that; Jekyll is launched from within publisher.jar, and I do not know if there are parameter settings for it somewhere
Josh Mandel (Sep 10 2020 at 19:02):
OK -- your OS probably provides some profiling (e..g, Windows task manager, or top in linux). I'm just going to crank things up across the board in our auto-build cluster (bigger machines, bigger limits)
Ted Klein (Sep 10 2020 at 19:03):
OK I'll have to look into it; running OSX on a MacBook Pro 2018 vintage here, v 10.14.6; there may be some environment settings in the bash terminal shell I am running java in.
Josh Mandel (Sep 10 2020 at 19:26):
BTW how long does a full build take for you Ted? With memory cranked up... right now the auto-builder has been cranking for 25 min, Java using >16GB RAM, 100% CPU). It's going to hit our 30min limit shortly ;-)
Ted Klein (Sep 10 2020 at 19:38):
wow. didn't think my MacBook Pro was THAT good...(18:40.0207). So under 20 minutes. On a laptop. While on a zoom call and recording the session LOL.
Josh Mandel (Sep 10 2020 at 19:55):
Well, the good news is the deadline is actually a full hour, as configured -- the bad news is it's still going to fail.
Josh Mandel (Sep 10 2020 at 19:56):
I'll give this a shot locally to compare...
Vassil Peytchev (Sep 10 2020 at 19:57):
Wait, 100% CPU? There is that much concurrent execution?
Josh Mandel (Sep 10 2020 at 19:59):
It's 100% of a core
Josh Mandel (Sep 10 2020 at 20:00):
Thank you for clarifying. (Which is to say, not much in the way of concurrent execution.)
Ted Klein (Sep 10 2020 at 20:04):
in the meantime I am editing some resources and just kicked off another local build and it is running...
Josh Mandel (Sep 10 2020 at 20:06):
Yeah, I was going to say that building https://github.com/hl7/utg fails for me locally with:
Stack Dump (for debugging): (03:52.0477)
/home/publisher/ig/template/scripts/ant-utg.xml:72: Unable to create javax script engine for javascript
at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:145)
at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:82)
at org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:348)
at org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:52)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at jdk.internal.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
at org.apache.tools.ant.Project.executeTarget(Project.java:1361)
at org.hl7.fhir.igtools.templates.Template.runScriptTarget(Template.java:185)
at org.hl7.fhir.igtools.templates.Template.beforeGenerateEvent(Template.java:342)
at org.hl7.fhir.igtools.publisher.Publisher.templateBeforeGenerate(Publisher.java:3262)
at org.hl7.fhir.igtools.publisher.Publisher.generate(Publisher.java:4821)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:848)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:694)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:8075)
Ted Klein (Sep 10 2020 at 20:19):
wow. mine is nearly complete here. I'll commit and push my changes to make sure what you see ih Git is what I just built OK here. I am 14 minutes in here...
Ted Klein (Sep 10 2020 at 20:21):
Final .zip built (17:49.0004)
Finished. Times: loading: 02:09.0204, generate: 14:34.0839, narrative generation: 01:25.0311, realm-rules: 00:00.0014, previous-version: 00:00.0002, jekyll: 03:25.0698, validation: 00:54.0300 (#3843), template: 00:29.0161 (#3) (17:49.0565)
Ted Klein (Sep 10 2020 at 20:27):
committed and pushed; utg ig version 1.0.40 builds fine with IGP 1.1.20 on my local system, rendered IG looks good.
Ted Klein (Sep 11 2020 at 22:33):
@Josh Mandel have you made any headway on this? it looks like UTG still will not build - works ok for me locally. @Rob Hausam tried it locally but his machine runs out of heap space and memory. Any prognosis?
Josh Mandel (Sep 12 2020 at 03:48):
I tried building yesterday and failed locally. I updated the RAM available in the cloud VM, doubling the size of the VM node where these jobs launch. It still seems to be getting stuck. I'd like to make sure I can get it to build locally...
Ted Klein (Sep 12 2020 at 13:04):
Ugh. What a mystery. Well I am building as normal here locally, if there is anything I can do to help you run this to ground I'm happy to try to help.
Josh Mandel (Sep 15 2020 at 18:00):
I'd like to make progress here -- I've updated limits in auto-builder to allocated 19G RAM for Java and 22G RAM for the overall build container. But meanwhile I still can't complete a build locally; failure stacktrace captured here.
Grahame Grieve (Sep 15 2020 at 19:56):
that's a java set up issue.
Vassil Peytchev (Sep 15 2020 at 20:05):
Or Ant? I found this reference to adding class-path to (in this case) ant-utg.xml, but I don't know if it's relevant...
Josh Mandel (Sep 15 2020 at 20:20):
The java setup in my Docker container comes from the open jdk base (https://github.com/FHIR/auto-ig-builder/blob/master/images/ig-publisher-base/Dockerfile#L1)
Josh Mandel (Sep 15 2020 at 20:21):
Is there some additional dependency?
Chris Moesel (Sep 15 2020 at 20:32):
Not sure if it's related, but I see you're using OpenJDK 16, and it appears they removed the Nashorn JavaScript Engine in OpenJDK 15. See: https://openjdk.java.net/jeps/372
Perhaps you need to add a jar that provides a JavaScript engine implementation? (only a guess based on the error message)
Vassil Peytchev (Sep 15 2020 at 20:46):
Not sure if it's related, but I see you're using OpenJDK 16
I thought we were aiming to support only LTS versions of OpenJDK (where OpenJDK 11 is the latest, to last until 2022)
Is that not the case?
Josh Mandel (Sep 15 2020 at 20:50):
Interesting! I'll update to use whatever is the "right" version. (In general I'd assumed we wanted to keep things working with the latest.)
Josh Mandel (Sep 15 2020 at 20:52):
(The auto-builder has been on OpenJDK 15 for 6 months (before that OpenJDK 12 for 16 months, and before that OpenJDK 8)
Josh Mandel (Sep 15 2020 at 20:54):
I'll update the "ig-publisher-base" to try OpenJDK 15 to start (i.e., to match the auto builder, which was the goal all along) -- good lead @Chris Moesel.
Chris Moesel (Sep 15 2020 at 20:56):
Well, my lead suggests it was removed in 15, so if things actually work in 15, then... ¯\_(ツ)_/¯
Josh Mandel (Sep 15 2020 at 21:23):
Nope, confirmed broken in 15 too -- so that's one reason the auto-build is failing (though in practice I don't think it's getting far enough to fail on this?)
Josh Mandel (Sep 15 2020 at 21:23):
Trying now in 14...
Josh Mandel (Sep 15 2020 at 21:27):
In related news, even though I can't build UTG locally, it does appear to have built today in the auto-build, once the extra memory was provided. So much for creating consistent environments for local testing and the auto-build cluster...
Josh Mandel (Sep 15 2020 at 21:29):
FYI @Ted Klein
Ted Klein (Sep 15 2020 at 21:56):
Yes apparently the ci build worked I see the current UTG version 1.0.40 is built with publisher 1.1.21, albeit with some funny display things that are different now (dunno if bugs or intended). Thank heavens as a new Change Proposal was submitted and I have to build the branch to be pushed to consensus review...
Grahame Grieve (Sep 15 2020 at 22:22):
@Ted Klein what is different?
Ted Klein (Sep 16 2020 at 01:00):
a couple of things. the rendering of the <name> element in code systems is strange with included double quotes and it looks like <title> is being combined
Ted Klein (Sep 16 2020 at 01:01):
but a bigger problem just cropped up just this minute - in building the branch UP-99 for a proposal that was submitted earlier today, I get the error:
Ted Klein (Sep 16 2020 at 01:01):
onGenerate:
Exception in thread "main" java.lang.Error: The resource type "NamingSystem" does not implement the property "experimental"
at org.hl7.fhir.r5.model.NamingSystem.getExperimental(NamingSystem.java:1665)
at org.hl7.fhir.igtools.renderers.CanonicalRenderer.describeStatus(CanonicalRenderer.java:122)
at org.hl7.fhir.igtools.renderers.CanonicalRenderer.genSummaryCore1(CanonicalRenderer.java:77)
at org.hl7.fhir.igtools.renderers.CanonicalRenderer.summaryTable(CanonicalRenderer.java:61)
at org.hl7.fhir.igtools.publisher.Publisher.generateOutputsCanonical(Publisher.java:7681)
at org.hl7.fhir.igtools.publisher.Publisher.generateResourceHtml(Publisher.java:6632)
at org.hl7.fhir.igtools.publisher.Publisher.generateHtmlOutputs(Publisher.java:6564)
at org.hl7.fhir.igtools.publisher.Publisher.generate(Publisher.java:4849)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:871)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:717)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:8276)
Ted Klein (Sep 16 2020 at 01:02):
we do not use 'experimental' in any of our NamingSystem resources. wtf? @Grahame Grieve this did not show up the the build of master branch a few hours ago.
Ted Klein (Sep 16 2020 at 01:02):
this is being rendered on the main build for all code system resources: Name: EventExpected"eventExpected"
Ted Klein (Sep 16 2020 at 20:28):
so seems to be dead once again; the java parameter for the timeout is STILL too small for this beast of an IG (UTG). Maybe we can boost the timeout value a bit? Here is the tail end of the error log:
Ted Klein (Sep 16 2020 at 20:28):
DEBUG:root:Time to deadline 3473.041943 seconds
DEBUG:root:
*** Timeout -- deadline reached
DEBUG:root:running: java -Xms19000m -Xmx19000m -jar ../publisher.jar -ig ig.json -auto-ig-build -target https://build.fhir.org/ig/HL7/UTG/ -out /scratch/ig-build-temp-TEKD4P/repo
DEBUG:root:Time to deadline -0.011687 seconds
DEBUG:root:
*** Timeout -- deadline reached
Josh Mandel (Sep 16 2020 at 20:51):
OK, setting the timeout from 1h to 2h :/
Josh Mandel (Sep 16 2020 at 20:51):
Though I don't understand why it should take this long; I can't reproduce this slow behavior locally
Ted Klein (Sep 16 2020 at 21:52):
Maybe something to do with rebuild of the cache files? Thing took 18.5 minutes to build on my laptop.
Grahame Grieve (Sep 16 2020 at 22:51):
@Josh Mandel I don't understand that output - it doesn't have any information from the IG publisher itself?
Ted Klein (Sep 16 2020 at 22:54):
So if you look at the bot generated log file you can see the whole thing. Something very mysterious is going on.
Grahame Grieve (Sep 16 2020 at 22:55):
where?
Ted Klein (Sep 16 2020 at 22:57):
on this stream up a dozen entries or so last branch UP-99 build
Grahame Grieve (Sep 16 2020 at 22:58):
that didn't help me
Josh Mandel (Sep 17 2020 at 02:25):
http://build.fhir.org/ig/HL7/UTG/branches/UP-99-change-meta-data-and-url-for-icd-10-ca-and-cci-codesystems-and-namingsystems/failure/build.log doesn't have publisher output -- that's the question right?
Grahame Grieve (Sep 17 2020 at 02:25):
yes.
Grahame Grieve (Sep 17 2020 at 02:26):
it logs that it started the publisher, and then that it killed it, but there's no output from the publisher itself
Josh Mandel (Sep 17 2020 at 02:34):
Yeah, I'm really not sure why that's happening. I'll investigate this tomorrow locally.
Grahame Grieve (Sep 17 2020 at 02:58):
thanks. The fact that ci-build for UTG is not working is creating real stress in the community
Josh Mandel (Sep 17 2020 at 03:04):
Appreciate the context -- I've been looking just now. The "good news" is that when I kick off a build for the UP-99-change-meta-data-and-url-for-icd-10-ca-and-cci-codesystems-and-namingsystems in the auto-builder, I see more in the build log than the snipped from the previous build:
INFO:root:about to clone!
DEBUG:root:running: git clone --recursive https://github.com/HL7/UTG --branch UP-99-change-meta-data-and-url-for-icd-10-ca-and-cci-codesystems-and-namingsystems repo
DEBUG:root:Time to deadline 3479.99728 seconds
Cloning into 'repo'...
DEBUG:root:running: wget -q https://github.com/HL7/fhir-ig-publisher/releases/latest/download/publisher.jar -O publisher.jar
DEBUG:root:Time to deadline 3474.512956 seconds
DEBUG:root:running: npm -g install fsh-sushi
DEBUG:root:Time to deadline 3473.041943 seconds
DEBUG:root:
*** Timeout -- deadline reached
... which snippet is consistent with, um, the behavior you'd expect if the npm command just hung for an hour.
Josh Mandel (Sep 17 2020 at 03:05):
When I re-triggered it just, it at least appears to be logging / chugging away as expected.
...
Load Package hl7.fhir.xver-extensions#0.0.4
Initialization complete (00:18.0806)
Fetch http://terminology.hl7.org/package-list.json for version check (00:18.0807)
Load Content (00:18.0918)
Processing Conformance Resources (02:36.0432)
Generating Snapshots (02:50.0709)
Generating Narratives (02:50.0928)
Grahame Grieve (Sep 17 2020 at 03:22):
npm?
Josh Mandel (Sep 17 2020 at 03:25):
I dunno, npm was the last command run before an hour ticked by on the clock
Grahame Grieve (Sep 17 2020 at 03:29):
plenty of stack overflow posts about npm hanging
Grahame Grieve (Sep 17 2020 at 03:39):
if it continues to be a problem, we decide whether we need npm or not
Josh Mandel (Sep 17 2020 at 03:40):
Sure -- we can also add --verbose to track down what's happening.
Josh Mandel (Sep 17 2020 at 03:40):
This might have been a connectivity blip that npm didn't recover gracefully from.
Josh Mandel (Sep 17 2020 at 03:41):
http://build.fhir.org/ig/HL7/UTG/branches/UP-99-change-meta-data-and-url-for-icd-10-ca-and-cci-codesystems-and-namingsystems/index.html looks like it worked. Let me know if anything fails again. (Please do @-mention me with any notes.)
Last updated: Apr 12 2022 at 19:14 UTC
