-
Notifications
You must be signed in to change notification settings - Fork 1
IG build for Publication
This process that works today, might not work tomorrow. History proves this breaks often.
The formal process that HL7 uses will evolve, and that evolution will likely break things
Here is pseudo-code (shell code) for what seems to work
Given you have a target IG named "test-ig", in the XXX IHE domain, and it is at version "0.1.0"
- make local clone of the target github repo (e.g. test-ig)
- if you already have a clone, make sure it is up-to-date (git pull)
- make local clones of the IHE fhir-ig-history-template https://github.com/IHE/fhir-ig-history-template
git clone https://github.com/IHE/fhir-ig-history-template.git
- if you already have a clone, make sure it is up-to-date (git pull)
- make fork of ig-registry and clone that branch locally
$ git clone https://github.com/FHIR/ig-registry.git
- if you already have a clone, make sure it is up-to-date (git pull)
- update the publisher tooling in your target IG clone. Both Sushi and Publisher need to be up-to-date. Update sushi using npm install as shown below. Update the publisher using _updatePublisher and answering "y" (second question you can answer "n")
$ npm install -g fsh-sushi
$ _updatePublisher
- build your target IG as normal
- make sure the version and releaseLabel are correct - sushi-config.yaml
_genonce
- build your IG for publication
_genonce -publish https://profiles.ihe.net/XXX/test-ig/0.1.0
- prepare a folder as if it was your web site
- First time, this is just a folder that is empty
mkdir www
- else, grab everything for your IG as current publications github repo --> https://github.com/IHE/publications
-
copy-recursively the IHE ../fhir-ig-history-template/* www/
-
prepare your package-list.json and put into the website directory (keep revision controlled in root of your github)
- it needs to properly identify your release
- documentation on package-list.json https://confluence.hl7.org/display/FHIR/FHIR+IG+PackageList+doco
- copy package-list.json www
- overwrite the package-list.json that exists
- create publish.ini; (keep revision controlled in root of your github)
[website]
style=fhir.layout
server=apache
url=https://profiles.ihe.net/XXX/test-ig
org=IHE
no-registry=1
[feeds]
package=package-feed.xml
publication=publication-feed.xml
- copy publish.ini www
- copy your build output to the website directory, overwriting
- copy-recursively output/* www/
- make a directory for this version and copy the output there too
- mkdir www/0.1.0
- copy-recursively output/* www/0.1.0/
- do some more publisher magic
java -jar input-cache/publisher.jar -publish-update -folder www -registry ../ig-registry/fhir-ig-list.json
- confirm the build found your IG
- "Y" to continue
- make sure it succeeded. (note there is a known IOException in the dist-hist)
-
copy the whole www website into the proper place in the
publications
repo for the profiles.ihe.net --> the Publications repo https://github.com/IHE/publications -
add your version specific sub-folder to the
robots.txt
at the root ofprofiles.ihe.net
. This prevents searches (e.g., google) from recommending anything other than formal publication folder. --> https://github.com/IHE/publications -
add to the
fhir/package-feed.xml
the\<item\>
from yourwww/package-feed.xml
(the IG build creates this package-feed.xml). This enables simplifier IG registry to detect your new IG content. -
follow the publications process for quality checks and publication. (Any quality check failures, likely require changes to the IG build)
- This must be done in concert with Mary.
-
update appropriate domain
index.html
to reference properly the new release -
Commit all updates back to
publications
repo as necessary. -
When no further changes happen, then Mary will
filezilla
the content over toprofiles.ihe.net
web site -
tag the
publications
repo -
commit IG project changes to the IG project github repo
-
tag the IG project repo with this version details -- https://github.com/IHE/publications/wiki/Revision-Management
-
update the IG project to the next minor version and back to ci-build, and commit that to github. This prepares the ci-build as different than the release.
-
commit the changes to
ig-registry
to your fork and create pull-request to HL7 authorities
This was transcribed from discussion on zulip chat
Alternate script https://confluence.hl7.org/pages/viewpage.action?pageId=104580055