Stream: IG creation
Topic: package.json wrong version
Brian Reinhold (Oct 24 2018 at 10:58):
Once again I am having issues with the publisher downloading an incorrect version of package.json into the cache. THis causes a re-download every build. The fix is simple, navigate to the file and manually edit the version from 2 to 3. This solves the problem!
Grahame Grieve (Oct 24 2018 at 11:18):
you have a caching problem, I think. but let me check - which package is this?
Rob Hausam (Oct 24 2018 at 11:44):
I'm apparently seeing the same thing, It's re-downloading the package each time.
Rob Hausam (Oct 24 2018 at 11:46):
hl7.fhir.core-current
Rob Hausam (Oct 24 2018 at 11:50):
Fetch hl7.fhir.core-current package from http://build.fhir.org/package.tgz (08.0247sec) Installing hl7.fhir.core#current to the package cache Fetching:............................................................................................................ ...................................................................................................................... ...................................................................................| Analysing............................................................................................................. ...................................................................................................................... .................................................. done. Checking hl7.fhir.core-current currency (00:01:37.0890sec) Updating hl7.fhir.core-3.6.0 package from source (too old - is 2, must be 3 (00:01:37.0891sec) Fetch hl7.fhir.core-current package from http://build.fhir.org/package.tgz (00:01:37.0891sec) Installing hl7.fhir.core#current to the package cache Fetching:............................................................................................................ ...................................................................................................................... ...................................................................................| Analysing............................................................................................................. ...................................................................................................................... .................................................. done. Load hl7.fhir.core-current package from /Users/rhausam/.fhir/packages/hl7.fhir.core#current (00:03:16.0570sec)
Brian Reinhold (Oct 24 2018 at 11:51):
you have a caching problem, I think. but let me check - which package is this?
Package downloaded is 2 but it needs to be 3
So I just edited it to 3 in the cache and it solves the re-download issue. I had the same issue when going from 1 to 2. Editing the package solved that as well. Eventually it got fixed though.
Rob Hausam (Oct 24 2018 at 11:51):
yes
Rob Hausam (Oct 24 2018 at 14:35):
It also looks like it's always re-fetching every time I run the validator. It's obviously doing it across the board, and it adds a considerable amount of time. I'll go ahead and try Brian's workaround for now and hopefully we can fix this soon.
Brian Reinhold (Oct 24 2018 at 14:39):
It also looks like it's always re-fetching every time I run the validator. It's obviously doing it across the board, and it adds a considerable amount of time. I'll go ahead and try Brian's workaround for now and hopefully we can fix this soon.
@Rob Hausam its located here C:\Users\xxxx\.fhir\packages\hl7.fhir.core#current\package\package.json if you are on windows. Just edit the
"tools-version": 3,
as shown.
Grahame Grieve (Oct 24 2018 at 15:07):
it's a challenge for me; as far as I can tell I have built the correct version of the package and put it on the server; the server is serving up a different version - caching on the server, I suppose.
Grahame Grieve (Oct 24 2018 at 15:08):
if you make this hack, you'll be unable to build the main build...
Brian Reinhold (Oct 24 2018 at 15:10):
if you make this hack, you'll be unable to build the main build...
@Grahame Grieve What do you mean by 'main build'? I am just building an IG. For the moment that is local.
Grahame Grieve (Oct 24 2018 at 15:11):
building an IG is not the main build
Brian Reinhold (Oct 24 2018 at 15:12):
building an IG is not the main build
I assumed that. Making this hack just cuts the build time down by quite a bit.
Rob Hausam (Oct 24 2018 at 16:19):
The main build also failed for me due to similar errors in running the AllGuidesTests.
Grahame Grieve (Oct 25 2018 at 07:58):
@Josh Mandel you're a better web hacker than me.... I'm pretty sure that this is a caching problem.... is there any way to solve it?
Rob Hausam (Oct 25 2018 at 13:42):
The main build isn't failing for me now - not quite sure why it did that one time. But the IG Publisher and the validator are still fetching each time.
Josh Mandel (Oct 25 2018 at 17:26):
Can you help me understand what file (full URL) is being cached? Are you saying this is true of http://build.fhir.org/package.tgz ? And that it's the server doing the caching?
Josh Mandel (Oct 25 2018 at 17:28):
If I do
$ curl --head http://build.fhir.org/package.tgz HTTP/1.1 200 OK Server: nginx/1.15.2 Date: Thu, 25 Oct 2018 17:27:22 GMT Content-Type: application/octet-stream Content-Length: 25245955 Last-Modified: Thu, 25 Oct 2018 15:24:56 GMT Connection: keep-alive ETag: "5bd1e048-1813903" Expires: Thu, 25 Oct 2018 17:32:22 GMT Cache-Control: max-age=300 Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type Vary: Accept Accept-Ranges: bytes
... I see a max-age and an expiration time. That would never cause the server to send old versions of the file though. I want to make sure I'm digging into the right question here before I go farther...
Rob Hausam (Oct 25 2018 at 18:45):
This is what's going on (each time) from the log:
Fetch hl7.fhir.core-current package from http://build.fhir.org/package.tgz (04.0378sec) Installing hl7.fhir.core#current to the package cache Fetching:............................................................................................................ ...................................................................................................................... ...................................................................................| Analysing............................................................................................................. ...................................................................................................................... .................................................. done. Checking hl7.fhir.core-current currency (00:01:11.0542sec) Updating hl7.fhir.core-3.6.0 package from source (too old - is 2, must be 3 (00:01:11.0542sec) Fetch hl7.fhir.core-current package from http://build.fhir.org/package.tgz (00:01:11.0543sec) Installing hl7.fhir.core#current to the package cache Fetching:............................................................................................................ ...................................................................................................................... ...................................................................................| Analysing............................................................................................................. ...................................................................................................................... .................................................. done. Load hl7.fhir.core-current package from /Users/rhausam/.fhir/packages/hl7.fhir.core#current (00:02:28.0185sec)
I can try to do some further digging into the details.
Rob Hausam (Oct 25 2018 at 18:50):
Sometimes when I look at .fhir/packages/ I've seen it as hl7.fhir.core#current (as it is for me now), but earlier it was hl7.fhir.core#3.6.0, but I haven't seen both. I'm not completely sure what it's supposed to be, but I don't think the directory name should be changing for what should be the same content.
Rob Hausam (Oct 25 2018 at 19:26):
After running the IG Publisher for the IPS IG just now the hl7.fhir.core#current package has disappeared from the local cache in .fhir/packages/ (and there is no hl7.fhir.core#3.6.0 package, either). I am still running the main build at the same time, though (but it's in the testing phase), so I can't be certain that there is no interaction with that. It does seem to me like it wouldn't be expected behavior, though.
Josh Mandel (Oct 25 2018 at 19:50):
Can someone clue me in (or point me to the docs) on how .fhir works? What is it used for, who populates it, how does it to get updated, Etc.
Lloyd McKenzie (Oct 25 2018 at 20:33):
.fhir is the local cache for NPM files. Both the IGPublisher and the Validator will use it. When they need a particular version of FHIR or an IG, they'll check the cache. If they find it, they'll use it. Otherwise they'll grab the remote one. I think they also check to see if the cache is up to date.
Josh Mandel (Oct 25 2018 at 23:19):
So...is the issue that people are finding the wrong file from the local .fhir cache folder, or that the webcserver is hosting the wrong version of a file?
Brian Reinhold (Oct 25 2018 at 23:23):
So...is the issue that people are finding the wrong file from the local .fhir cache folder, or that the webcserver is hosting the wrong version of a file?
@Josh Mandel What is the case is that every download loads the version 2 into the cache. Don't know if it is wrong on the server. However, everything else seems ok since it works. To avoid the download every build, I hand edit the version to 3 in the .fhir cache. Not the best but it DOES save a great deal of time!
Grahame Grieve (Oct 26 2018 at 13:26):
the pacakage.tgz that the build creates has /package/package.json tools-version= 3
Grahame Grieve (Oct 26 2018 at 13:27):
the file that some poeple are downloading from the http link to it has /package/package.json tools-version= 2
Rob Hausam (Oct 26 2018 at 13:39):
It's what the igpublisher and the validator jars are downloading. They're both doing it each time, even though the cached copy is already there, and they're also not doing the same thing (the igpublisher caches hl7.fhir.core#current and the validator removes that and caches hl7.fhir.core#3.6.0 - and vice versa).
Grahame Grieve (Oct 26 2018 at 13:41):
which one they download depends on how you invoke them, but they both clear both out until your cacing problem is resolved
Rob Hausam (Oct 26 2018 at 13:54):
So what exactly would be "my caching problem"? I'm invoking them the same way as I always have and I didn't have any problem with this in the past. For the publisher I've tried invoking them with both Lloyd's framework script and also directly (i.e. java -jar /Users/rhausam/git-repo/fhir/publish/org.hl7.fhir.igpublisher.jar -ig ig.json) and I get the same behavior. And if I remove the cached copy the problem comes back in the same way. I'm not seeing anything else that is obvious to do, and unless I've overlooked it I haven't seen any clear suggestions in the thread on how to fix it (other than Brian's "hack"). Should I do something else?
Grahame Grieve (Oct 26 2018 at 13:55):
the caching problem is somewhere in the http stack
Grahame Grieve (Oct 26 2018 at 13:55):
client or server
Grahame Grieve (Oct 26 2018 at 13:55):
and I'm at a loss.
Rob Hausam (Oct 26 2018 at 13:55):
OK, right. Whatever it is we haven't figured it out yet. And I think it's everyone's problem.
Brian Reinhold (Oct 26 2018 at 13:59):
the caching problem is somewhere in the http stack
@Grahame Grieve @Rob Hausam I had the same problem going from one to 2. Eventually it got resolved; i could delete the cache and the downloaded package had the correct version in it. Not very helpful because I don't know specifically when it happened. I think I discovered it worked when I started from scratch on a new system.
Grahame Grieve (Oct 26 2018 at 15:15):
ok I've committed a change which is a fairly brutal override of any upstream caching. (add ?nocache={instant} to every request from the local cache manager
Grahame Grieve (Oct 26 2018 at 15:15):
it will be ready to merge after I have boarded my flight, so can one of you merge the PR if it passes, and then test?
Grahame Grieve (Oct 26 2018 at 15:15):
PR 151
Lloyd McKenzie (Oct 26 2018 at 15:28):
Merge and then test when you're on a flight sounds risky...
Lloyd McKenzie (Oct 26 2018 at 15:28):
Is there a way to un-merge if it causes problems?
Rob Hausam (Oct 26 2018 at 15:52):
We can revert the commit (creates a new commit that reverses the changes) - but hopefully that won't be necessary.
Lloyd McKenzie (Oct 26 2018 at 16:59):
Ok, I've done the merge
Grahame Grieve (Oct 27 2018 at 07:49):
did it fix anything?
Rob Hausam (Oct 27 2018 at 08:39):
I don't think so. IG Publisher (v3.6.0-9ef639a3, gen-code v3.6.0 / 3) is still fetching the core-current package, twice, each time I run it. It must be something else.
Lloyd McKenzie (Oct 27 2018 at 14:52):
Same for me
Grahame Grieve (Oct 27 2018 at 16:50):
@Josh Mandel I'm at a loss here; the file I'm getting generated - and that must be generated for the build to succeed - is not what is being downloaded, and I don't know of a more comprehensive way to bust any caches. is it not updating on the build server? can you look directly in package.tgz at /package/package.json and tell us what is in tools-version?
Josh Mandel (Oct 27 2018 at 17:09):
I think I need to sit down with someone who understands how the system is supposed to work, so I can help investigate. Right now I don't really understand what the issue is or how things are supposed to be working.
Josh Mandel (Oct 27 2018 at 17:10):
Everyone sees the same content at http://build.fhir.org/ that I do, right? Is there a problem with this content?
Grahame Grieve (Oct 27 2018 at 17:11):
yes there is
Grahame Grieve (Oct 27 2018 at 17:12):
if you download http://build.fhir.org/package.tgz, you'll get a different file to what you'll get if you build locally.
Grahame Grieve (Oct 27 2018 at 17:12):
somewhere... something is broken... but I can't figure out what because I can't access the actual copies of the file past my local build
Grahame Grieve (Oct 27 2018 at 17:18):
more info:
the build generates the file package.tgz. One of the files in there is package/package.json. There's a json file inside that that will have a property 'tools-version' set to "3" per the constant here: https://github.com/HL7/fhir/blob/master/implementations/java/org.hl7.fhir.utilities/src/org/hl7/fhir/utilities/cache/ToolsVersion.java
Grahame Grieve (Oct 27 2018 at 17:19):
if you run it locally, the value in your package.tgz will be 3
Josh Mandel (Oct 27 2018 at 17:19):
So package.tgz contains another package.tgz?
Grahame Grieve (Oct 27 2018 at 17:19):
if you download what purports to be outcome of the current build for package.tgz,you'll get the value 2
Grahame Grieve (Oct 27 2018 at 17:20):
sorry typo - should be package/package.json inside package.tgz
Josh Mandel (Oct 27 2018 at 17:20):
ahh, yes. And that's "2".
Josh Mandel (Oct 27 2018 at 17:20):
It says inside that json file:
"description": "FHIR Core package - the NPM package that contains all the definitions for the base FHIR specification(built 20181026225400)"
Josh Mandel (Oct 27 2018 at 17:21):
Does that look correct (i.e., up to date)?
Grahame Grieve (Oct 27 2018 at 17:22):
no? comparing with the build notifications, it doesn't seen to match (would be different by being start/end of the build)
Josh Mandel (Oct 27 2018 at 17:23):
Here are the args we build with on the CI server:
NAME="Continuous Integration Build"
SVNREV=$(git rev-parse --short HEAD)
antBuild (){
ant -Dargs="./publish.sh -svn $SVNREV -name \'$NAME\' -url http://build.fhir.org/ -post-pr"
checkStatus
}
... so whatever goes into package.tgz/package/package.json is whatever gets built by this ant command. How is tools-version supposed to be populated by this?
Grahame Grieve (Oct 27 2018 at 17:23):
I'll see if I can add a timezone to that
Grahame Grieve (Oct 27 2018 at 17:24):
it's build by the java code. Its hard coded to that java constant, and populated correctly when I build locally
Josh Mandel (Oct 27 2018 at 17:24):
Huh. Is there any condition in which TOOLS_VERSION can/should ever be "2"?
Grahame Grieve (Oct 27 2018 at 17:25):
no. it's a fixed constant I changed about 4 days ago
Josh Mandel (Oct 27 2018 at 17:25):
Ah, but you changed it from 2 -> 3? So it used to be 2?
Grahame Grieve (Oct 27 2018 at 17:25):
yes
Josh Mandel (Oct 27 2018 at 17:25):
And the new file is definitely being _built_ later than 4 days ago, given the timestamp.
Grahame Grieve (Oct 27 2018 at 17:25):
and this change hasn't arrived into that file and I can't figure out why
Josh Mandel (Oct 27 2018 at 17:25):
But you're thinking that the CI build is somehow happening with some old version of the source (constant definitions) hanging around?
Grahame Grieve (Oct 27 2018 at 17:26):
3 days ago: https://github.com/HL7/fhir/commit/1a950707e40b76fbf5923021a31245a5d23230e5
Josh Mandel (Oct 27 2018 at 17:26):
Let me turn "Clean" on for the CI build; it's been on for PR builds for a while.
Josh Mandel (Oct 27 2018 at 17:27):
OK, done. I'll kick off a new CI build.
Grahame Grieve (Oct 27 2018 at 17:27):
ok thanks
Grahame Grieve (Oct 27 2018 at 17:27):
if that's the problem... it means that the caching was very far upstream ;-)
Josh Mandel (Oct 27 2018 at 17:27):
Sure -- sorry this took so long for me to understand; I was under the impression there was a web hosting kind of caching issue.
Josh Mandel (Oct 27 2018 at 17:27):
Yeah
Josh Mandel (Oct 27 2018 at 17:28):
but given that the package.json file is newly created each time, it _must_ be upstream.
Grahame Grieve (Oct 27 2018 at 17:28):
I didn't think to check the date :-(
Grahame Grieve (Oct 27 2018 at 17:49):
yes that fixed it
Grahame Grieve (Oct 27 2018 at 17:51):
thanks
Grahame Grieve (Oct 27 2018 at 18:14):
on reflection, this is a common problem: ant does not always rebuild all java classes. Hence our immediate response when something doesn't make sense: clean your class files out. I'm not seeing any good information about there about this problem..
Eric Haas (Oct 27 2018 at 21:18):
What folders needs to be deleted and repulled? (Clean out class files)
Eric Haas (Oct 27 2018 at 21:21):
I once tried clean.sh which resulted in scenes of lamentations
Rob Hausam (Oct 27 2018 at 21:47):
Getting this now:
[java] Checking hl7.fhir.core-current currency (02.0940sec)
[java] ... ok: is 3, must be 3 (02.0941sec)
Much better, thanks!
Grahame Grieve (Oct 28 2018 at 00:22):
We’ve fixed clean.sh
Josh Mandel (Oct 29 2018 at 14:15):
Hmm, have we? I don't see any changes at https://github.com/HL7/fhir/commits/master/clean.sh
Last updated: Apr 12 2022 at 19:14 UTC
