FHIR Chat · IG Publisher output · IG creation

Stream: IG creation

Topic: IG Publisher output

Brian Postlethwaite (Oct 05 2019 at 07:45):

Is there a flag that you use on the IG Publisher when generating an official build ready to publish?
(wanting to do it for an internal IG - so it doesn't put the CI warning box in it)

Oliver Egger (Oct 05 2019 at 07:59):

it is a two step process:

1. -publish
2. -publish-update
   I documented it for our publication setup: https://github.com/ahdis/k8s-fhir.ch

Brian Postlethwaite (Oct 05 2019 at 13:01):

Did you end up with any clarity on TODO: not 100% sure what needs to be in -registry and -root parameter

Eric Haas (Oct 05 2019 at 14:51):

I use a site variable in the _config.yml file

Eric Haas (Oct 05 2019 at 14:53):

build: ci # choice of ci|ballot|version

aomng other things this updates the title based on the value of {{site.build}}

Eric Haas (Oct 05 2019 at 14:54):

hope to incorporate this stuff into the standard template

Grahame Grieve (Oct 05 2019 at 19:43):

@Oliver Egger is right - you run the publish update on whole site. It does more than just update the publish box. But there's things I haven't sorted yet for use by hl7.ch - what server software are you using?

Oliver Egger (Oct 06 2019 at 06:35):

Did you end up with any clarity on TODO: not 100% sure what needs to be in -registry and -root parameter

@Brian Postlethwaite sorry no, it worked for my case with the provided parameter

Oliver Egger (Oct 06 2019 at 07:35):

Oliver Egger is right - you run the publish update on whole site. It does more than just update the publish box. But there's things I haven't sorted yet for use by hl7.ch - what server software are you using?

I use nginx in glcoud as a reverse proxy for a google drive, all config is published in this repo. The only thing I noticed, that I had to add to template a specific history.html/js to our ig's instead of the history.cfml and do a rewrite for the history.cfml. Is there anything which would be server specific?

Grahame Grieve (Oct 06 2019 at 09:16):

the redirects are server specific. nginx will use php redirects. Does your server support PHP?

As for the history page, you provide the history.xxx set up for whatever works for the server; the IGpubisher leaves that untouched (just updates package-list.json)

Brian Postlethwaite (Oct 06 2019 at 09:46):

I have a simple folder shared on Azure websites (essentially IIS) but was going to add some code around the outside.
What extra stuff did you have to do with publishing?

Brian Postlethwaite (Oct 06 2019 at 09:46):

@Grahame Grieve i assume you're out of town at the moment.

Brian Postlethwaite (Oct 06 2019 at 09:47):

(planning on publishing the first snapshot this week, so will need to cross these issues off)

Grahame Grieve (Oct 06 2019 at 09:50):

so the basic process goes like this:
- you have a local copy of the web site
- you do your local build with a -web flag which generates some additional stuff
- you copy the output into [ig]/XXXX where [ig] is the root for this ig, and XXXX is your version
- you edit the package-list.json file
- you point the igpublisher at the root directory (usually something that can contain several [ig] directories

It does the following:

• check the package-list.json
• it checks that all the directories are correct
• updates all the publish boxes so that the text is correct, and refers to the latest copy of that page (it there is one)
• it generates all the appropriate redirects
• it creates/updates the entry for the ig in the master ig registry as well

Grahame Grieve (Oct 06 2019 at 09:50):

I am in the air on the way to Bangkok for a HIMSS meeting. Then St Petersberg, Moscow, Miami, Houston and then home

Grahame Grieve (Oct 06 2019 at 09:51):

the IG publisher is only tested to do this correctly for Hl7.org and fhir.org, but it's on my todo list to extend this for other circumstances as required

Grahame Grieve (Oct 06 2019 at 09:52):

and one more thing it will do this week:

• adds the IG to the package feed so that the IG gets picked up by the fhir registry

Grahame Grieve (Oct 06 2019 at 09:52):

(both the package server and the registry itself)

Brian Postlethwaite (Oct 07 2019 at 00:13):

I wouldn't want this internal one sent to the registry...

Grahame Grieve (Oct 07 2019 at 00:16):

then you don't need to commit the changes. I'll make it so that bit can be turned off

Brian Postlethwaite (Oct 07 2019 at 00:16):

How are the redirects generated? (so I can work out if these will apply to the AzureWebSites deploy)

Grahame Grieve (Oct 07 2019 at 00:16):

for IIS, I generate an ASP. For Apache, I generate a PHP. You'll have to figure out, for an AzureWebSites, if there's any way to do media type dependent redirects. I expect that there isn't though

Brian Postlethwaite (Oct 07 2019 at 00:19):

I can probably work out what to do from the ASP. Is that through an output flag, or does it just generate all of them?

Grahame Grieve (Oct 07 2019 at 02:45):

Is that through an output flag, or does it just generate all of them?

I don't know what you are asking

Brian Postlethwaite (Oct 07 2019 at 02:46):

The redirect stuff that you create, does it just output ASP and PHP and you pick what you want. Or is there a flag to choose, or is that done manually.

Grahame Grieve (Oct 07 2019 at 02:47):

at the moment, it's hard coded to know what server is what software

Grahame Grieve (Oct 07 2019 at 14:45):

no. you can specify using -server-type X where X is "ASP" or "Apache".

Grahame Grieve (Oct 07 2019 at 14:45):

it knows some servers so you don't have to specify.

Grahame Grieve (Oct 07 2019 at 14:45):

if you want other software listed, we'll have to work out how to generate the redirects for the server

Brian Postlethwaite (Oct 07 2019 at 18:44):

Thanks, I can take a look in the code for what it does and take a swing at it once I work out what is needed in Azure websites. Probably pretty close to asp I'd guess.

Grahame Grieve (Oct 08 2019 at 00:13):

I'd bet not. I bet you're stuck. These websites are static content only, at least all the ones I've reviewed are

Grahame Grieve (Oct 08 2019 at 00:14):

and I haven't figured out how to pull of a different redirect for different values of the Accept: header without server side active content

Brian Postlethwaite (Oct 08 2019 at 02:59):

I do have room for active content...

Grahame Grieve (Oct 08 2019 at 03:20):

ok what kind? ASP?

Brian Postlethwaite (Oct 08 2019 at 04:02):

I'll be checking what the ASP generates then make up my mind how I do it...
(I may be building some simple server code - for simple auth)

Grahame Grieve (Oct 08 2019 at 04:11):

here's a typical redirect, at http://hl7.org/fhir/StructureDefinition/Account:

<%@ language="javascript"%>

<%
  var s = String(Request.ServerVariables("HTTP_ACCEPT"));
  if (s.indexOf("json") > -1)
    Response.Redirect("http://hl7.org/fhir/account.json");
  else if (s.indexOf("html") > -1)
    Response.Redirect("http://hl7.org/fhir/account.html");
  else
    Response.Redirect("http://hl7.org/fhir/account.xml");

%>

<!DOCTYPE html>
<html>
<body>
You should not be seeing this page. If you do, ASP has failed badly.
</body>
</html>

Brian Postlethwaite (Oct 08 2019 at 04:15):

Is it really just the URL free addresses and versioning URLS and content type negotiations?

Grahame Grieve (Oct 08 2019 at 06:41):

that's all the redirects are.

Brian Postlethwaite (Oct 08 2019 at 08:29):

Cool, no need to generate anything then.
I should be able to create some .net middleware to do it.

Grahame Grieve (Oct 08 2019 at 11:05):

ok. and I changed around the way you invoke it. Now, you need a file publish.ini in the root of your web site. It has the following format:

[website]
style=fhir.layout
url={public url for this folder}
no-registry=1  ; only if the IGs in this directory are not registered in the public IG registry
server={asp | apache}

; both entries are optional, and are the names of files to produce as RSS feeds in the folder
; for people who want to subscribe to any new versions. The FHIR IG registry uses the package
; file if it's registered in the IG feed directory
[feeds]
package={filename}
publication={filename}

Grahame Grieve (Oct 08 2019 at 11:06):

and you invoke it with only 2 parameters -publish-update {folder} -registry {path | n/a}

Brian Postlethwaite (Oct 09 2019 at 05:28):

Is that url the one at the root, or the one inside the version/dev folder?
root/dev
root/0.1.0
root/0.2.0

Brian Postlethwaite (Oct 09 2019 at 05:31):

(and I should imagine this hasn't been pushed yet too)
the {root}/{realm}/{code} was getting me, as the paths we use in our registry won't be 3 deep.

Brian Postlethwaite (Oct 09 2019 at 05:32):

We are planning to use {root}/th-ncsr/dev/index.html
(and then replace dev with the versions of each of the published ones)

Grahame Grieve (Oct 09 2019 at 09:14):

root

Grahame Grieve (Oct 09 2019 at 09:15):

I think you should use current rather than dev. It might not matter, but current and dev are two special package versions - current, the current build. dev, the build you have on your local drive (not yet committed)

Grahame Grieve (Oct 09 2019 at 09:16):

you don't need {realm}, or even {code} but the infrastructure expects you to have {code} for a reason

Brian Postlethwaite (Oct 10 2019 at 03:24):

registry with a path of n/a kinda breaks heaps. Have done some debugging, and some obvious stuff in there which I tried fixing and it gets a lot further, but then there is no IGRegistryMaintainer reg object, so nothing appears to be able to process.
Or am I missing something here, Is this maintaining an external registry outside the folders its processing (i.e. updating the fhir registry or something in build.org etc)

Grahame Grieve (Oct 10 2019 at 04:15):

I haven't finished all this yet

Brian Postlethwaite (Oct 10 2019 at 04:47):

I guesses as much ;)

Michael Lawley (Oct 13 2019 at 23:57):

@Grahame Grieve re the use of RSS for feeds, did you consider ATOM as an alternative, and did you consider adding additional metadata to the feed to allow for entries that contain things other than packages or with a different MIME type/format (e.g., future proofing)? Even knowing (machine readably) what FHIR version the package contents consist of would be useful for automation.

Grahame Grieve (Oct 14 2019 at 08:25):

no because we were working with the RSS format as already used in the NPM community. I expect we can add things to that as long as don't change anything it already has

Grahame Grieve (Oct 14 2019 at 08:25):

but you can get all that from the package, so it's more convenience than anything else

Michael Lawley (Oct 15 2019 at 08:01):

Yes, if you go and get the package, but not great if you want your UI to only display STU3 packages, for example, or other manifest-based filtering.
But I see this is RSS 2.0 so the spec allows for extension elements as long as they are namespaced

Michael Lawley (Oct 15 2019 at 08:22):

npm seems a little more structured in that the <title> elements are essentially the logical identity (I'm reverse engineering this; documentation seems very hard to find)

Grahame Grieve (Oct 15 2019 at 09:26):

hmm. you're right. I'll fix that and extend while I'm at it.

Grahame Grieve (Oct 15 2019 at 09:35):

I am adding the namespace fhir as http://hl7.org/fhir/feed\, with the following elements:

• fhir:version: the version of FHIR the package is for (may repeat in the future)
• fhir:kind: the kind of package

Kind of package:

• fhir.core: a core specification
• fhir.ig: a IG
• fhir.tool: release of a tool (e.g. validator) - none at the moment
• fhir.template: an IG template
• fhir.subset: a subset of an IG for some purpose

Bob Milius (Jun 10 2020 at 15:16):

Grahame Grieve said:

so the basic process goes like this:

• you have a local copy of the web site
• you do your local build with a -web flag which generates some additional stuff

Should I be running -web before/after/same time as the -publish or -publish-update option?

Grahame Grieve said:

• it generates all the appropriate redirects

Is this done with the -web option? or with the -publish, -publish-output parameters? Should I be seeing php code generated in my local site?

Grahame Grieve (Jun 14 2020 at 00:38):

so there's a 2 step process - you generate your IG in whatever directory you cloned the git repo into

Grahame Grieve (Jun 14 2020 at 00:38):

that's when you use -web

Grahame Grieve (Jun 14 2020 at 01:10):

for your final build. it does a few little background things a little different but the output is almost completely the same

Last updated: Apr 12 2022 at 19:14 UTC