Stream: IG creation
Topic: New IGPublisher release
Grahame Grieve (Jul 01 2020 at 02:33):
@Mark Iantorno has just released a new version of the IG Publisher using the new release framework.
The new version is 1.1.0. From now on, we'll be releasing through github releases, and the URL for the latest publisher will be https://github.com/HL7/fhir-ig-publisher/releases/latest/download/publisher.jar. Please update any links you have for the old publisher to this new address
We are changing the release again because now we have the release process we want in place working. You might recall that we were forced to make a change a few weeks ago because the old release process collapsed before we got this one in place. We expect this change to be permanent now.
@Josh Mandel please advise when the build process is pointing to the new location - thanks
Rob Hausam (Jul 01 2020 at 02:40):
Does _updatePublisher handle it?
Grahame Grieve (Jul 01 2020 at 02:40):
for now, I have uploaded a copy to the address of the old release, but this is probably the last time I'll do that. I'll be deleting that version soon
Grahame Grieve (Jul 01 2020 at 02:40):
not yet. it'll need to be changed
Rob Hausam (Jul 01 2020 at 02:41):
yes - not quite so urgent if the old way still works for now
Jose Costa Teixeira (Jul 01 2020 at 03:00):
_updatePublisher scripts have been updated (PR needs to be merged by Lloyd or Grahame)
Josh Mandel (Jul 01 2020 at 03:24):
Should be set, re: automated IG-build process --https://github.com/FHIR/auto-ig-builder/commit/d198646c2abc0164dd38422ea5bb2bc63f907d4e#diff-5a49469b71b1f5300cf144dc9c92a008R49
Chris Moesel (Jul 01 2020 at 12:07):
Love that the new releases come with a change log. Thank you, @Mark Iantorno and @Grahame Grieve ! image.png
Mark Iantorno (Jul 01 2020 at 13:32):
If anyone is interested in what is going on behind the scenes to make this happen, all the repos now have full CI/CD pipelines implemented through Azure DevOps, and they can be viewed here: https://dev.azure.com/fhir-pipelines/
Jose Costa Teixeira (Jul 01 2020 at 13:40):
Mark Iantorno said:
If anyone is interested in what is going on behind the scenes to make this happen, all the repos now have full CI/CD pipelines implemented through Azure DevOps, and they can be viewed here: https://dev.azure.com/fhir-pipelines/
lovely idea. I have no access though.. :(
Lloyd McKenzie (Jul 01 2020 at 14:41):
_updatePublisher PR now merged
Mark Iantorno (Jul 01 2020 at 18:21):
That's so weird, you can't access the base project, but all the sub projects are open:
Mark Iantorno (Jul 01 2020 at 18:21):
https://dev.azure.com/fhir-pipelines/fhir-core-library/
Mark Iantorno (Jul 01 2020 at 18:21):
https://dev.azure.com/fhir-pipelines/fhir-test-cases
Mark Iantorno (Jul 01 2020 at 18:21):
https://dev.azure.com/fhir-pipelines/ig-publisher
Mark Iantorno (Jul 01 2020 at 18:22):
https://dev.azure.com/fhir-pipelines/ig-registry
Jose Costa Teixeira (Jul 01 2020 at 20:00):
these I can open, thanks
Grahame Grieve (Jul 01 2020 at 20:08):
Love that the new releases come with a change log
well, we have been doing this for a while now. What this change allows us to do is put it in the release page
Jean Duteau (Jul 02 2020 at 16:25):
deleted
John Moehrke (Jul 22 2020 at 16:57):
can we get _updatePublisher to also update sushi? sushi changes about as often, but I often forget.
Jose Costa Teixeira (Jul 22 2020 at 17:17):
We could do something like this:
- check if node is available
- if so, check if sushi is installed
- if so, update
Jose Costa Teixeira (Jul 22 2020 at 17:17):
then we have a .bat file that gets sushi, and sushi that gets the .bat files :)
Jose Costa Teixeira (Jul 22 2020 at 17:18):
is that something that everyone would want - or better, is anyone going to have issues with that? I think if we have a prompt Y/N, this should be safe
David Pyke (Jul 22 2020 at 17:22):
We're making the bold assumption that enough people who use publisher use sushi and won't find that a pain to say no to all the time.
David Pyke (Jul 22 2020 at 17:24):
however, a command line flag to include sushi is less intrusive for those that don't use it.
Gino Canessa (Jul 22 2020 at 17:25):
I would (personally) prefer that _updatePublisher updates everything it needs. Ideally, it would do so locally instead of globally though (so that updating a single IG on my machine doesn't partially update others).
Jose Costa Teixeira (Jul 22 2020 at 17:25):
command line flag would mean bye bye to double click
Jose Costa Teixeira (Jul 22 2020 at 17:27):
Gino Canessa said:
I would (personally) prefer that _updatePublisher updates everything it needs. Ideally, it would do so locally instead of globally though (so that updating a single IG on my machine doesn't partially update others).
that is kind of what it does now: it updates your IG's scripts and your IG's publisher. If your IG does not have its own publisher, it updates your publisher in the parent folder which is used across other IGs
David Pyke (Jul 22 2020 at 17:27):
@Gino Canessa so, check if sushi is installed and update it if it is?
Jose Costa Teixeira (Jul 22 2020 at 17:27):
well, it doesn't know if sushi is needed for that IG...
Jose Costa Teixeira (Jul 22 2020 at 17:28):
besides, do we do npm install or npm install -g ?
Gino Canessa (Jul 22 2020 at 17:36):
@David Pyke that makes sense to me.
@Jose Costa Teixeira I would vote npm install so that it's local. If I have another IG that I haven't updated I don't want a partial update to blow up my build.
I would argue the same behavior for the parent folder - if you have one that is what you want updated (does not mean you don't have another root path that has a different version).
Jose Costa Teixeira (Jul 22 2020 at 17:37):
I'm just exploring. if we do npm install, that means my IG folder will get a brand new sushi install in it?
Jose Costa Teixeira (Jul 22 2020 at 17:38):
If so, I don't think we want to force that on users.
David Pyke (Jul 22 2020 at 17:39):
that's why we have to check to see if it exists before any update or prompt
Jose Costa Teixeira (Jul 22 2020 at 17:39):
i don't know if we can see from a command line if sushi is installed locally or globally.
Jose Costa Teixeira (Jul 22 2020 at 17:39):
if I have it globally, i do not want it installed locally
Jose Costa Teixeira (Jul 22 2020 at 17:41):
an alternative - can sushi update itself when it's being called?
Jose Costa Teixeira (Jul 22 2020 at 17:41):
i.e. only for those IGs that actually have sushi
David Pyke (Jul 22 2020 at 17:45):
I'd prefer that sushi handled it's own update either directly or by saying "New version available" when run
Jean Duteau (Jul 22 2020 at 17:59):
the shell script can't update sushi on many Macs because it needs to be installed with sudo.
John Moehrke (Jul 22 2020 at 18:15):
can sushi itself tell that it is not the most current?
Jose Costa Teixeira (Jul 22 2020 at 18:21):
John Moehrke said:
can sushi itself tell that it is not the most current?
If any program can, it's sushi itself
Jose Costa Teixeira (Jul 22 2020 at 18:23):
i'd prefer that, i think:
_updatePublisher does not touch sushi.
Sushi checks itself for possible updates, and if so, asks the user if they want to update . Sushi then sees if it's running locally or globally, and does install or install -g accordingly.
If sushi is running in a CI build or called by the publisher, it will not prompt, it will just warn.
John Moehrke (Jul 22 2020 at 18:32):
I realize that eventually sushi and build will stop being a daily update. explaining how to do this daily to new users is frustrating.
Gino Canessa (Jul 22 2020 at 18:32):
CI build installs each run, so it cannot be out of date
John Moehrke (Jul 22 2020 at 18:38):
that is my current recommendation to new people.. that is to NOT try to locally build, just use the CI build. The only drawback is that you checkin code often, and thus following the #committers/notification stream will see that it took you 5 tries to get the build to work. Which I then tell them that no one inspects each line in that stream
Jose Costa Teixeira (Jul 22 2020 at 18:40):
ok, updated:
Sushi checks itself for possible updates, and if so, asks the user if they want to update.
Sushi then sees if it's installed locally or globally, and does install or install -g accordingly.
If sushi is being called by the publisher, it will not prompt, it will just warn.
Jose Costa Teixeira (Jul 22 2020 at 18:56):
...right?
Chris Moesel (Jul 22 2020 at 19:19):
the shell script can't update sushi on many Macs because it needs to be installed with sudo
On mine I don't need sudo to do npm installs or updates. Is that an option people intentionally choose for security reasons?
Jean Duteau (Jul 22 2020 at 19:25):
yes, my /usr/local doesn't have wide-open privileges. So only administrators can install stuff (like npm and npm modules) there
Chris Moesel (Jul 22 2020 at 19:26):
Also, just catching up on this thread now. Almost missed it... We could potentially have SUSHI report when it knows it is out of date. This will require a network connection though. Currently, as long as you've run SUSHI once on your project (to download any dependencies) a network connection is not needed.
I'm not sure I'd want SUSHI to update itself. I certainly wouldn't want that to happen automatically. But I'm also not sure I want to issue a prompt, as that complicates shell scripts and CI. I suppose we could also introduce a flag to suppress the prompt and force y or n -- if this is something users really want. Do you really want SUSHI to offer to update itself when it is out of date? Or do you just want SUSHI to tell you when it is out of date?
Chris Moesel (Jul 22 2020 at 19:28):
@Jean Duteau -- my /usr/local is also restricted, but my /usr/local/lib/node_modules is owned by my standard user account, so I can add global node_modules without needing sudo.
Last updated: Apr 12 2022 at 19:14 UTC
