FHIR Chat · Releases of sample-ig? · IG creation

Stream: IG creation

Topic: Releases of sample-ig?

Josh Mandel (Jan 06 2021 at 17:42):

For https://github.com/fhir/sample-ig @Lloyd McKenzie, would you be OK with using tagged releases? Several tools are grabbing .sh scripts from this repo and running them, but I'd feel a lot more comfortable if I could reference a specific rlease rather than "whatever's on master".

Lloyd McKenzie (Jan 06 2021 at 18:23):

Can you expand on what that would mean? You mean that we would just tag the version we wanted systems to grab rather than bringing down current? In what situations would we not put that tag on current?

Josh Mandel (Jan 06 2021 at 21:15):

Git tags are "sticky" -- once you apply them, you don't move them. Then, a tagged commit can be used to generate a "release" in github, which gets a downloadable structure that folks can refer to. (If every commit you make on master is seeing careful review and can be used/trusted by everyone in the community, then every commit could be tagged with an incremented version and associated with a release.)

Jose Costa Teixeira (Jan 06 2021 at 23:55):

When a user runs the _updatePublisher, should they be asked to point to a specific release?
Or would we have a command line argument?

Josh Mandel (Jan 07 2021 at 00:24):

I think of _updatePublisher just like _genOnce, and so on; users would fetch the "set of scripts" in a versioned release, and update to a newer set when they chose. It gets complicated because some of these scripts update themselves, which is behavior I'd personally not want to opt into.

Jose Costa Teixeira (Jan 07 2021 at 00:28):

I'm trying to figure out the desired behaviour to see if it makes sense.
There should be no issue to point the _updatePublisher to a specific release, but I think we want to support updates, right?
For example if I'm using the scripts v1.0.0, when there's a v1.0.1, do we update?

Josh Mandel (Jan 07 2021 at 00:49):

I'd expect that to be a user's choice, but sure it should be an option.

Josh Mandel (Jan 07 2021 at 00:50):

(I'd expect users to update as an explicit, intentional step.)

Josh Mandel (Jan 07 2021 at 00:50):

(Like updating a template, I guess.)

Lloyd McKenzie (Jan 07 2021 at 02:54):

I think the big question is "what should the review process be for the scripts to be deemed 'trusted'". The tagging question would be secondary. (Though moving the scripts to a stand-alone Git project that could have a formal pull request review process might be a good idea.)

Josh Mandel (Jan 07 2021 at 03:24):

Yes, standalone repo would be nice. That way folks who wanted to could pull it into their IGs as a submodule or subtree (without getting a bunch of sample ig content in the process).

Josh Mandel (Jan 07 2021 at 03:24):

And yeah, the trust is a big deal on these since folks are automatically downloading and executing code in them.

Josh Mandel (Jan 07 2021 at 03:26):

(Would be good to enable master branch protections, require review before merges, prevent force pushes, and limit editors with write permissions.)

Lloyd McKenzie (Jan 07 2021 at 03:33):

How many reviews should there be before a commit can be merged to main, and thoughts on who we might want those folks to be?

Max Masnick (Jan 07 2021 at 13:07):

If you're looking for volunteers to help with this, I'd be glad to help!

John Moehrke (Jan 07 2021 at 14:05):

I think the default should be to use current stable... otherwise we get people who unknowingly get stuck behind. Our hope is to have more than the current 6 people doing Implementation Guide creation, so we need to make it easier, not harder.

Jose Costa Teixeira (Jan 07 2021 at 14:45):

current stable, i think, would be the latest tag

Jose Costa Teixeira (Jan 07 2021 at 14:47):

Josh Mandel said:

Yes, standalone repo would be nice. That way folks who wanted to could pull it into their IGs as a submodule or subtree (without getting a bunch of sample ig content in the process).

I think a standard repo is a good thing.

Jose Costa Teixeira (Jan 07 2021 at 14:47):

For avoiding the sample ig content, I made a barebones github template - only the necessary files for all IGs in an organization. Sort of an "IG content template". This way we can create a full IG repo in a much shorter time, no need to delete any content.

Jose Costa Teixeira (Jan 07 2021 at 14:49):

(if sushi had this function, it would be something like "sushi --init - template=ihe.empty-ig")

Josh Mandel (Jan 07 2021 at 16:16):

How many reviews should there be

Let's start with one?

Lloyd McKenzie (Jan 07 2021 at 16:22):

@Jose Costa Teixeira I think the scripts should be separated from a minimum IG. The level of review we need for IG starter files is different. We can update the scripts for the starter IG by just running the "Update scripts" and then committing them.

Jose Costa Teixeira (Jan 07 2021 at 16:23):

Yes, I'm good with that.

Lloyd McKenzie (Jan 07 2021 at 17:54):

Ok, done. Jose, Josh, initial pull request is here for review. Josh, if you can check that I've got the settings sufficiently tight, that'd be wonderful
https://github.com/HL7/ig-publisher-scripts/pull/1

Chris Moesel (Jan 07 2021 at 17:59):

@Lloyd McKenzie -- I just pulled down your branch on my mac and noted that the *.sh files don't have their executable bit set. Is it possible to chmod 755 those *.sh files and push up another commit?

Jose Costa Teixeira (Jan 07 2021 at 18:08):

i don't know the permissions now but i presume chmod +x is (also) what we need, right?

Max Masnick (Jan 07 2021 at 18:33):

Either chmod 755 or chmod +x should get you to the same place...at least the .sh files in the IGs I work on are set to 755

Jose Costa Teixeira (Jan 07 2021 at 18:45):

I finally could commit. @Lloyd McKenzie care to review?

Jose Costa Teixeira (Jan 07 2021 at 18:52):

Can someone please check if they are executable yet?

Lloyd McKenzie (Jan 07 2021 at 18:59):

Merged

Chris Moesel (Jan 07 2021 at 21:10):

I have confirmed that the .sh scripts _are_ executable in the main branch. Thanks all!

Josh Mandel (Jan 07 2021 at 21:24):

Protection rules look good @Lloyd McKenzie , thanks!

Josh Mandel (Jan 07 2021 at 21:24):

It's also great to have this as a standalone repo.

Chris Moesel (Jan 07 2021 at 21:38):

sushi --init currently downloads the scripts from the sample IG. We'll have to update SUSHI to pull them from here instead. When do you anticipate removing those scripts from sample-ig?

Jose Costa Teixeira (Jan 07 2021 at 21:47):

as soon as we find a good way to handle their replacement. I'm now looking at submodules

Josh Mandel (Jan 07 2021 at 21:49):

I have an example at https://github.com/HL7/smart-app-launch

(but to @Chris Moesel's point, we don't want to break people using an installed version of sushi. Maybe even good to add some "deprecation warning" printouts in the scripts hosted in sample-ig, with a note like "if you're using sushi <= version X, you should update".)

Jose Costa Teixeira (Jan 07 2021 at 21:55):

this is my struggle with submodules - i can add them in a "scripts" folder, but for backwards compatibility i'd need it to be on the root

Josh Mandel (Jan 07 2021 at 21:55):

Don't think you can do that.

Jose Costa Teixeira (Jan 07 2021 at 21:55):

i'm learning that :)

Jose Costa Teixeira (Jan 07 2021 at 21:56):

whatever comes out of this, we will indeed need a tag to signal this change

Jose Costa Teixeira (Jan 07 2021 at 22:11):

Exploring ideas:

1. Just remove the scripts, and update documentation to explain why things are failing.
2. keep the scripts, just have them self-update from the new location
3. replace the script in sample-ig with a simpler one that doesn't do anything except redirect the user to the "proper" ones.

echo "The scripts you need are located here https://.....

Jose Costa Teixeira (Jan 07 2021 at 22:13):

#2 means that everything still works as before, and after running _updatePublisher 1 or 2 times, every ig will be up to date with the proper scripts from the proper location. But this means one more thing to keep in sync, because submodules don't work

Chris Moesel (Jan 08 2021 at 01:15):

I have no idea if this would work (or what it means for Windows), but can you replace the existing scripts with symlinks to the scripts in the submodule?

Lloyd McKenzie (Jan 08 2021 at 02:03):

Don't think you can do that on Windows. They'd also fail if you weren't online, which would suck...

Jose Costa Teixeira (Jan 08 2021 at 08:20):

I tried symlinks on Windows, it kind of works, but it's messy to put in github. Besides, I expect issues when users get it from github (somehow the links become absolute, they should be relative).

Max Masnick (Jan 08 2021 at 11:12):

I would avoid git submodules if possible...I doubt most IG authors are familiar with them, and they add complexity to standard operations. For example git clone git@github.com:HL7/some-ig.git would no longer produce a local clone with the scripts in place. Users would have to add --recursive to the clone command or subsequently run git submodule update --init --recursive.

Jose Costa Teixeira (Jan 08 2021 at 11:38):

Right. I am trying subtree which seems to be working (at least the commits and pushes)

Jose Costa Teixeira (Jan 08 2021 at 11:55):

@Max Masnick do you want to see if it works?

Jose Costa Teixeira (Jan 08 2021 at 11:55):

https://github.com/costateixeira/sample-ig/tree/subtree

Max Masnick (Jan 08 2021 at 11:56):

Sure, one sec...

Jose Costa Teixeira (Jan 08 2021 at 11:56):

this has to work for any git client, OR for downloading the zip file (submodules don't work there)

Jose Costa Teixeira (Jan 08 2021 at 11:57):

the only thing I need to check is whether the scripts will be automatically updated when we update the main repo

Max Masnick (Jan 08 2021 at 11:57):

I don't think I've heard of git subtree before...wonder what else is lurking in git that I should know about :)

Jose Costa Teixeira (Jan 08 2021 at 11:59):

i also hadn't until this morning :)

Max Masnick (Jan 08 2021 at 12:09):

Ok so I did:

$ git clone git@github.com:costateixeira/sample-ig.git
$ git checkout -b subtree origin/subtree

The scripts/ folder appeared and scripts/_updatePublisher.sh and scripts/_genonce.sh both ran (though the IG Publisher crashed at the end, presumably for an unrelated reason).

Max Masnick (Jan 08 2021 at 12:10):

I assume if this was in the main branch, then git clone ... would work just like ↑ but without any additional commands

Max Masnick (Jan 08 2021 at 12:13):

A small request: can you call the sub-folder script/ rather than scripts/? This matches the other folders (input, output, etc.) which are singular.

Max Masnick (Jan 08 2021 at 12:13):

(It also matches my Ruby on Rails muscle-memory for script/generate :grinning: )

Max Masnick (Jan 08 2021 at 12:22):

@Jose Costa Teixeira Are you planning to make the subtree self-updating? (As in automatically pull down changes when HL7/ig-publisher-scripts has a new tagged release?) I've done this before with scripts in a git repo and it works quite nicely, but I've never done it with subtrees.

Jose Costa Teixeira (Jan 08 2021 at 12:27):

the goal is to use ./_genonce, not scripts/_genonce
(i only made that for .bat)

Jose Costa Teixeira (Jan 08 2021 at 12:27):

i can change to script, no issue

Jose Costa Teixeira (Jan 08 2021 at 12:28):

Max Masnick said:

Jose Costa Teixeira Are you planning to make the subtree self-updating? (As in automatically pull down changes when HL7/ig-publisher-scripts has a new tagged release?) I've done this before with scripts in a git repo and it works quite nicely, but I've never done it with subtrees.

that would be good indeed, if I knew how...

Max Masnick (Jan 08 2021 at 12:30):

Jose Costa Teixeira said:

Max Masnick said:

Jose Costa Teixeira Are you planning to make the subtree self-updating? (As in automatically pull down changes when HL7/ig-publisher-scripts has a new tagged release?) I've done this before with scripts in a git repo and it works quite nicely, but I've never done it with subtrees.

that would be good indeed, if I knew how...

Yeah it may be tricky with subtrees because from what I can tell, the commit hashes won't be preserved between ig-publisher-scripts and whatever IG repo the subtree is created in.

Max Masnick (Jan 08 2021 at 12:34):

The simplest thing would be to have a version.json file or something in ig-publisher-scripts, which would get bumped as part of the release process. Then _genonce could check this against the tags on https://github.com/HL7/ig-publisher-scripts. If there's a bigger version number in a tag on main, then that would trigger an update. I think this will work :grinning:

Looking at https://blog.developer.atlassian.com/the-power-of-git-subtree/, it seems like the command for updating the subtree will be something like git subtree pull --prefix script https://github.com/HL7/ig-publisher-scripts.git master --squash, which is probably not something users should ever have to type in themselves...so some sort of updating mechanism seems important from a UX perspective.

Jose Costa Teixeira (Jan 08 2021 at 13:11):

or this
https://github.com/xedi/action-subtree-sync

Max Masnick (Jan 08 2021 at 13:13):

Interesting...so could be set as a hook for every push or something?

Jose Costa Teixeira (Jan 08 2021 at 13:19):

maybe (i'm just learning about this)

Max Masnick (Jan 08 2021 at 13:26):

I think there are a lot of different ways to accomplish this...another would be using local git hooks. I just worry about the usability of anything involving git, especially anything that goes beyond the basics.

Even with git subtree, there may be some sharp edges...what if someone changes a file in script/? Would we want updates to overwrite any local changes automatically? I don't think it's a good idea to put users in the position of dealing with a merge inside the subtree.

Jose Costa Teixeira (Jan 08 2021 at 13:31):

especially when these scripts are just a simple thing to facilitate lanching the publisher.. I would like feedback to see what is the preferred goal here.
My view is that we can do something as long as it's hit and forget. I don't expect the scripts to change often. putting them on a separate repo makes sense, but it should remain simple to use and maintain.

Max Masnick (Jan 08 2021 at 14:18):

I think it would be helpful to do two things:

1. Tell users when there is an update available (same for publisher.jar...it's easy to fall behind the most recent release, especially when working on multiple projects that each have their own publisher.jar)
2. Provide an easy path to doing the update (could be as simple as telling the user to run _updatePublisher, modified to work with the subtree if we go that route)

#1 would have been pretty difficult prior to moving the scripts to https://github.com/HL7/ig-publisher-scripts, and if the scripts have to be modified anyway to work with this new repo, I think this is a good opportunity to do it.

Max Masnick (Jan 08 2021 at 14:20):

I actually wrote a wrapper around _genonce.sh to provide system notifications when an IG build finishes, and I added in update notifications for publisher.jar...the notifications are quite handy in practice, especially when there are frequent publisher.jar updates:

image.png

Max Masnick (Jan 08 2021 at 14:27):

Unless there's a mechanism to prompt users when the build scripts are updated, folks will end up accidentally running old versions of the scripts -- especially if the updates are really infrequent. This will be problematic if there's ever a need for a critical update to fix a bug or security issue.

Jose Costa Teixeira (Jan 08 2021 at 14:30):

we could incorporate those checks in _updatePublisher. And possibly in _genonce.

Max Masnick (Jan 08 2021 at 15:53):

It would be great if they could go in _genonce. I think this is the best path to keeping everything up to date.

Jose Costa Teixeira (Jan 08 2021 at 15:54):

_genOnce could do a check, and call _updatePublisher if needed.

Jose Costa Teixeira (Jan 08 2021 at 15:54):

@Lloyd McKenzie thoughts?

Jose Costa Teixeira (Jan 08 2021 at 15:55):

@Max Masnick how can we implement such check (in windows .bat language)?

Max Masnick (Jan 08 2021 at 15:59):

I don’t know anything about .bat implementation off the top of my head, but I can investigate. I was actually getting set up to work on testing something in .bat for Windows anyway, so I can look at this too if it can wait until next week

Jose Costa Teixeira (Jan 08 2021 at 16:12):

how did you implement this ? I'd presume you get the remote json and somehow parse it. The parsing bit I don't know how to do

Lloyd McKenzie (Jan 08 2021 at 16:42):

The desire is to separate the 'update' step from the 'generate' step. Updating can take a long time and can sometimes grab a copy of the publisher known to be broken. The current design where if you gen with something that's out-of-date you get a warning, but you are in control of if/when updates happen is the preferred approach.

Lloyd McKenzie (Jan 08 2021 at 16:42):

(in my opinion)

Max Masnick (Jan 08 2021 at 18:04):

I agree with Lloyd...having a clear indication of when the scripts need to be updated, but leaving the timing of the update in the user's hands is preferable.

(Real life example: I'm currently a point release behind on publisher.jar because it introduces a bug, but I still want to be reminded of that each time I run _genonce so I can update with the next release.)

Max Masnick (Jan 08 2021 at 18:07):

Jose Costa Teixeira said:

how did you implement this ? I'd presume you get the remote json and somehow parse it. The parsing bit I don't know how to do

There's two parts:

1. Grab the current version data from GitHub: PUBLISHER_VERSION_GITHUB=$(curl -vs "https://api.github.com/repos/HL7/fhir-ig-publisher/releases?per_page=1" 2>&1 | grep '^ "name":' | sed 's/[ \t]*"name": "\(.*\)",/\1/')
2. Get the current version of publisher.jar: PUBLISHER_VERSION_JAR=$((java -jar input-cache/publisher.jar -version || true) 2>&1 | grep "FHIR IG Publisher Version" | sed 's/.*Version \([0-9.]*\).*/\1/') (there's probably a better way to do this, but this was easy and it works)

Jose Costa Teixeira (Jan 08 2021 at 18:08):

I was thinking of a warning at the end of _genOnce - after all is done, we say "this was generated with an old version..."

Jean Duteau (Jan 08 2021 at 18:08):

you don't really need that because the qa.html tells you that

Jose Costa Teixeira (Jan 08 2021 at 18:08):

nice - sed, grep, curl - all things that we don't have

Max Masnick (Jan 08 2021 at 18:08):

Yeah :(

Jose Costa Teixeira (Jan 08 2021 at 18:08):

qa.html tells about the old version of the publisher, not the script

Jose Costa Teixeira (Jan 08 2021 at 18:09):

(not that it matters a lot)

Max Masnick (Jan 08 2021 at 18:10):

And I would argue this belongs in the terminal output if possible -- it should be visible in the interface where the commands are run (the terminal/command prompt) rather than having to go somewhere else

Max Masnick (Jan 08 2021 at 18:12):

Making the update check as part of the script also gives us the opportunity to offer to run the update for the user (or tell them how)...this is more important for the scripts than publisher.jar because it's not as simple as downloading/replacing publisher.jar

Jose Costa Teixeira (Jan 08 2021 at 18:16):

Max Masnick said:

The simplest thing would be to have a version.json file or something in ig-publisher-scripts, which would get bumped as part of the release process. Then _genonce could check this against the tags on https://github.com/HL7/ig-publisher-scripts. If there's a bigger version number in a tag on main, then that would trigger an update. I think this will work :grinning:

if we make that version.txt, we can do something with ms-dos

Jose Costa Teixeira (Jan 08 2021 at 18:19):

(and it would be "if there is a different number", not "there is a bigger number".

Jose Costa Teixeira (Jan 08 2021 at 18:19):

that should be doable.

Jose Costa Teixeira (Jan 08 2021 at 18:20):

So where is this landing? I know a few things we can do, but to change anything we need to settle on what we want to do

Lloyd McKenzie (Jan 08 2021 at 19:25):

Old version of the script generally isn't that big an issue. If it works, it's probably ok

Max Masnick (Jan 08 2021 at 20:00):

Jose Costa Teixeira said:

So where is this landing? I know a few things we can do, but to change anything we need to settle on what we want to do

Since it's probably not too hard to do the version checking as Jose described above, I personally think it's worth putting that in. I'm a big believer in setting up tooling to help users do the right thing, and if the "right thing" is updating these scripts if there are changes, having the update checking built in will help a lot.

For actually updating the scripts, I think continuing to use _updatePublisher as-is may make sense for IG authors. Unless I'm missing something, IG authors won't see any major benefits from using git subtree -- but I could be missing something here.

For the FHIR/sample-ig project, I think git subtree should be used as it will be helpful in updating the included scripts in a consistent way.

Max Masnick (Jan 08 2021 at 20:02):

I more or less have the code for doing the update checking in sh so I'm happy to contribute that part. I can also help on the Windows side but I'm definitely not a batch file expert.

Lloyd McKenzie (Jan 08 2021 at 20:12):

The "are you up to date" checking is built into the base template. I don't see a reason to add a redundant call to put it in the script too.

Jean Duteau (Jan 08 2021 at 20:14):

i already said that and they pooh-poohed me :)

Max Masnick (Jan 08 2021 at 20:15):

For the update checking, I'm talking about checking for updates to the contents of https://github.com/HL7/ig-publisher-scripts, not publisher.jar

Lloyd McKenzie (Jan 08 2021 at 20:17):

We don't really care if the scripts are up-to-date. The scripts don't influence the publication. The only negative consequence of out-of-date scripts is that if something major changes, they start to fail - which itself provides a pretty strong indication you should try updating the scripts :) Also, the publisher changes far more often than the scripts do, so being notified that the publisher has changed is generally enough to trigger someone to update the scripts at the same time.

Max Masnick (Jan 08 2021 at 20:19):

Maybe _updatePublisher could do the update check for the scripts then, and directly warn users if they were out of date.

This wasn't really possible until the scripts were in a separate repo, but now that they are it still seems worth doing to me.

Max Masnick (Jan 08 2021 at 20:20):

Jean Duteau said:

i already said that and they pooh-poohed me :)

I agree there's no point in duplicating the publisher.jar check. I didn't realize the out-of-date publisher warning showed up in qa.txt until now, but since it does that makes it easy to programmatically check for updates.

Jose Costa Teixeira (Jan 08 2021 at 20:26):

There is currently no version control on the scripts. If we want the scripts to have some sort of check, it makes sense only if it is very simple or if it prevents us from having to maintain updates in 2 places

Jose Costa Teixeira (Jan 08 2021 at 20:29):

My concern is about the scripts being on the root folder of sample-ig - and we may need to put it inside a folder if we want to keep only one source.

Lloyd McKenzie (Jan 08 2021 at 20:37):

We want the warning to show up in the qa.html, not elsewhere. The qa.html is part of the publication and it needs to be there for external review purposes. So moving it isn't an option. I don't understand why we'd want to duplicate it.

Lloyd McKenzie (Jan 08 2021 at 20:38):

Note that we don't have to put the scripts in the sample-ig at all if it's too hard. Simply providing guidance in the readme that explains where to download the desired 'upload scripts' script is sufficient if we can't find an automated way to make it work.

Max Masnick (Jan 08 2021 at 20:41):

Lloyd McKenzie said:

We want the warning to show up in the qa.html, not elsewhere. The qa.html is part of the publication and it needs to be there for external review purposes. So moving it isn't an option. I don't understand why we'd want to duplicate it.

You're talking about the publisher.jar version check? I'm not suggesting that should be moved or duplicated

Max Masnick (Jan 08 2021 at 20:43):

I'm talking about a separate version check for the script files in https://github.com/HL7/ig-publisher-scripts, which isn't hard to implement and I think is worthwhile for the reasons I described above. I don't believe this currently exists, but it would make sense with the introduction of tagged releases in https://github.com/HL7/ig-publisher-scripts

Jose Costa Teixeira (Jan 08 2021 at 20:48):

Lloyd McKenzie said:

Note that we don't have to put the scripts in the sample-ig at all if it's too hard. Simply providing guidance in the readme that explains where to download the desired 'upload scripts' script is sufficient if we can't find an automated way to make it work.

the simplest i can think of is to put the _updatePublisher script in the IG root folder. Once people run it, they will get the other scripts, and the _updatePublisher will update itself

Lloyd McKenzie (Jan 08 2021 at 21:07):

We don't really want the _updatePublisher committed in more than one place though. Doing so would eliminate at least some of the benefit of maintaining the scripts only in a tightly controlled repository.

Jose Costa Teixeira (Jan 08 2021 at 21:23):

Just realized that we may need to keep the scripts (or at least _updatePublisher) in the sample IG for a while, because that is where all the _updatePublishers out there will get the scripts from.

Jose Costa Teixeira (Jan 08 2021 at 21:24):

so we need to allow current IGs to update the _updatePublisher from the sampleIG , even if it is just to be able to run it again and get the scripts from the repo

Lloyd McKenzie (Jan 08 2021 at 21:24):

Not really. If we yank them, the update scripts will just stop working. I think we push the current ones for a week or so and tell everyone to update. Those who fail to do so will find that they fail to work and will need to go download.

Jose Costa Teixeira (Jan 08 2021 at 22:19):

2 weeks and a dedicated Zulip stream for the complaints. Deal? :grinning_face_with_smiling_eyes:

Jose Costa Teixeira (Jan 08 2021 at 22:20):

(jk about the zulip stream of course)

John Moehrke (Jan 11 2021 at 13:39):

just document well the very specific error that happens when someone failed to update... (making it easy to search the internet for, start a zulip thread covering it)...

Chris Moesel (Jan 13 2021 at 14:19):

FYI -- there was a bug in the download location in the scripts causing the dynamic script updates to fail. I've submitted a PR. @Lloyd McKenzie / @Jose Costa Teixeira -- can you review? https://github.com/HL7/ig-publisher-scripts/pull/3

Jose Costa Teixeira (Jan 13 2021 at 14:58):

reviewed. Thanks

Chris Moesel (Jan 13 2021 at 15:08):

Cool. So how do we get that merged? We have a ready update for SUSHI that points to the new scripts, but I don't want to release that until the scripts have been fixed here.

Chris Moesel (Jan 13 2021 at 16:42):

@Lloyd McKenzie merged it. Thanks, Lloyd!

Jose Costa Teixeira (Feb 11 2021 at 17:12):

@Lloyd McKenzie https://github.com/FHIR/sample-ig/pull/45
updates the sample script so that all scripts point to the same location

Lloyd McKenzie (Feb 11 2021 at 17:52):

Merged

Last updated: Apr 12 2022 at 19:14 UTC