Stream: IG creation
Topic: build with hl7.fhir.template
Brett Esler (Aug 03 2021 at 23:17):
hi would anyone know what has happended around use of hl7.fhir.template in IG build? is causing errors now such as:
See examples: http://build.fhir.org/ig/HL7/fhir-eyecare-ig/branches/master/failure/build.log http://build.fhir.org/ig/HL7/carin-bb/branches/master/failure/build.log and http://build.fhir.org/ig/HL7/fhir-ipa/branches/master/failure/build.log - failing now with
Publishing Content Failed: 'version' must be defined in ig.ini. e.g. '2.0'
last two were rebuilds of IGs building okay
Brett Esler (Aug 03 2021 at 23:18):
fhir.base.template is working fine...
Lloyd McKenzie (Aug 03 2021 at 23:30):
I have no idea. The HL7 template shows as having been rebuilt an hour ago, but there's been no commits to it since June...
Corey Spears (Aug 03 2021 at 23:43):
Everything since the FHIR/hl7-if-template rebuild is failing.
Lloyd McKenzie (Aug 04 2021 at 03:49):
I'm working on it, but totally confused at the moment...
Lloyd McKenzie (Aug 04 2021 at 04:31):
@Mark Iantorno I think something is hosed with the package server. It's serving up an ancient version of the base template as 'current' - even though I've pushed the new version a couple of times, including incrementing the package identifier once. I have no idea what caused the problem. (Even more bizarre is that the hl7 template was built earlier today even though there were no commits for it. That seems to be what triggered the change. I've pushed updates to the HL7 template, but that hasn't helped. Not sure what to do to fix this. (But given that ballot is opening soon, fixing is pretty urgent...)
Mark Iantorno (Aug 04 2021 at 11:46):
Please try clearing your local package cache first, and seeing if that makes a difference. If not, I may have to publish another package to make it trigger as new.
Rob Hausam (Aug 04 2021 at 12:04):
@Mark Iantorno @Lloyd McKenzie Clearing the package cache didn't make any difference. I'm still seeing the same 'version' must be defined in ig.ini. e.g. '2.0' as before.
Mark Iantorno (Aug 04 2021 at 12:05):
hrm, no good. @Lloyd McKenzie have any changes to packages been made recently? I have not touched them
Max Masnick (Aug 04 2021 at 13:34):
This is breaking the build for the SMART Health Card IG. I removed ~/.fhir and input-cache/, which didn't help.
Mark Iantorno (Aug 04 2021 at 13:39):
@Ward Weistra any idea why this might be happening on the package server?
Ward Weistra (Aug 04 2021 at 13:56):
@Mark Iantorno I don't think the template is served by the package registry. (And I'm personally happy about that, because it's really meant for FHIR packages, not a general purpose file sharing system). Only thing template related is a Swiss one: https://simplifier.net/packages?Text=template / https://registry.fhir.org/results?query=%22template%22
It doesn't seem to come from the backup packages server either: http://packages2.fhir.org/packages/catalog?op=find&name=template
Perhaps it's somewhere in the IG Publisher's code where it gets those templates from? https://github.com/HL7/fhir-ig-publisher/search?q=template :shrug:
Lloyd McKenzie (Aug 04 2021 at 14:08):
The package ends up in the cache, and it depends on the notion of referencing 'current' vs. a specific version, so I don't know how it could not depend on the package registry. Changes to templates are shared when they get pushed to the master branch and trigger the CI-build hook, which also says that it's leveraging the package infrastructure.
The issue triggered when something caused the HL7 template to build on the CI build server. That build was not triggered by a commit. (The most recent commit on that template was from June and the problem didn't manifest until late yesterday.) I've since tried a couple of commits to try to force an update to the package, but no dice so far. I know I didn't manually trigger the build that made it fail.
Mark Iantorno (Aug 04 2021 at 14:09):
@Lloyd McKenzie can you link the build to me please
Mark Iantorno (Aug 04 2021 at 14:09):
the one that caused this
Lloyd McKenzie (Aug 04 2021 at 14:13):
I don't know how to see historical builds. The link I use to see things (https://fhir.github.io/auto-ig-builder/builds.html) only shows the most recent and, as best I can tell, new builds wipe old ones.
Mark Iantorno (Aug 04 2021 at 14:14):
and this one "HL7 / ig-template-hl7" is the one that is causing this error?
Ward Weistra (Aug 04 2021 at 14:15):
@Lloyd McKenzie The registry currently also has no notion of current versions. That's currently something only implemented in the IG publisher to get IGs from the build server (and, it seems, templates).
Lloyd McKenzie (Aug 04 2021 at 14:17):
The symptom is that new builds using the HL7 template (not the base template) are inheriting an ancient version of the base template. Because the issue triggered when the HL7 template built, I presume the problem is there, but rebuilding the HL7 template didn't fix the problem.
Mark Iantorno (Aug 04 2021 at 14:18):
Let me check if it is still marked as "current" in the repo
Lloyd McKenzie (Aug 04 2021 at 14:19):
@Ward Weistra - the 'current' versions certainly show up in the package cache:
image.png
Lloyd McKenzie (Aug 04 2021 at 14:20):
Are the registry and the package server the same thing? I thought they were different...
Mark Iantorno (Aug 04 2021 at 14:20):
Okay, but this started happening when?
Mark Iantorno (Aug 04 2021 at 14:20):
Like the last couple days right?
Max Masnick (Aug 04 2021 at 14:21):
I was able to build our IG successfully this time yesterday
Mark Iantorno (Aug 04 2021 at 14:21):
If it just started happening, then we can rule out the IG-Publisher being the issue, because it was last published 16 days ago, by me...and that was just a versioning update to align with the code.
Ward Weistra (Aug 04 2021 at 14:22):
@Lloyd McKenzie Depends on how you name it, but registry.fhir.org (which calls itself the FHIR Package Registry) is the UI on top of the FHIR Package API (packages.fhir.org).
And indeed, the IG Publisher is storing the current and dev versions in the same package cache. But it's not getting them from packages.fhir.org.
Mark Iantorno (Aug 04 2021 at 14:23):
So, the version is set to null for "HL7 / ig-template-hl7"
Mark Iantorno (Aug 04 2021 at 14:23):
and "HL7 / ig-template-base"
Mark Iantorno (Aug 04 2021 at 14:23):
I can see that here: https://fhir.github.io/auto-ig-builder/builds.html
Mark Iantorno (Aug 04 2021 at 14:23):
by hovering my mouse over the build link
Mark Iantorno (Aug 04 2021 at 14:24):
This might be the source of the issue
Lloyd McKenzie (Aug 04 2021 at 14:25):
It's possible that a semi-recent change to the publisher is causing the version to not get set properly and when someone somehow triggered a rebuild of the template, the version got wiped - and subsequent builds aren't fixing it because they're using the new version of the publisher?
Mark Iantorno (Aug 04 2021 at 14:26):
That's an easy test
Mark Iantorno (Aug 04 2021 at 14:26):
try it with an old publisher version
Mark Iantorno (Aug 04 2021 at 14:26):
Can you please try https://github.com/HL7/fhir-ig-publisher/releases/tag/1.1.76
Lloyd McKenzie (Aug 04 2021 at 14:31):
How do I trigger a CI-build using an old publisher?
Mark Iantorno (Aug 04 2021 at 14:32):
You would have to do this locally
Mark Iantorno (Aug 04 2021 at 14:32):
Is that not possible?
Corey Spears (Aug 04 2021 at 14:32):
I tried that locally yesterday without success. I just tried with 1.1.75 and still getting the error. (Even after clearing template folder)
Lloyd McKenzie (Aug 04 2021 at 14:33):
I don't have a problem locally, though I could try wiping my cache
Mark Iantorno (Aug 04 2021 at 14:33):
Please try building locally @Lloyd McKenzie with both versions
Lloyd McKenzie (Aug 04 2021 at 14:33):
@Corey Spears This would be building the template, not the IG
Lloyd McKenzie (Aug 04 2021 at 14:33):
The thing is, building locally will give me a #dev version, not a #current version
Lloyd McKenzie (Aug 04 2021 at 14:35):
Also, templates don't really 'build'. The CI-build process just sort of magically packages them. I don't think that bit runs locally.
Mark Iantorno (Aug 04 2021 at 14:35):
@Josh Mandel You set up this CI for building the IGs, can you assist?
Corey Spears (Aug 04 2021 at 14:36):
I am getting the error when building an IG locally.
Load Template from hl7.fhir.template#current (00:05.0194)
Pre-Process: /Users/cspears/dev/fhir/fsh/PACIO/pacio-adi/input/pagecontent = _includes | null
onLoad.setup:
Publishing Content Failed: 'version' must be defined in ig.ini. e.g. '2.0' (00:07.0896)
Lloyd McKenzie (Aug 04 2021 at 14:38):
@Josh Mandel I think the ask is to be able to pass a parameter in the hook URL that would indicate the version of the publisher to download
Mark Iantorno (Aug 04 2021 at 14:38):
First I would like to know what changed.
Mark Iantorno (Aug 04 2021 at 14:39):
Templates are unchanged. Publisher is unchanged.
Mark Iantorno (Aug 04 2021 at 14:39):
Something has changed that is now causing the dependency not to resolve correctly.
Mark Iantorno (Aug 04 2021 at 14:40):
I know that this affects people's current work, but we need to understand what changed to cause this before we start putting in any quick fixes to get it to work.
Mark Iantorno (Aug 04 2021 at 14:43):
If we can't get this resolved by 4-5 EST, I will call Grahame.
Corey Spears (Aug 04 2021 at 14:43):
Not sure if this is useful, but the template build (FHIR/hl7-ig-template: master rebuilt) that the trouble started happening was at 10:00pm UTC on Tuesday 2021-08-03.
Mark Iantorno (Aug 04 2021 at 14:45):
Which, again, is strange because that package hasn't been updated since Sept 2019.
AbdulMalik Shakir (Aug 04 2021 at 15:20):
The build log for my IG (VRDR) fails at a point marked as "onLoad.r5-schemas:". Is the on loading of R5 schemas a new step in the build logic? Is it a necessary step for IGs still on R4 and not pre-adopting features of R5? Please excuse me if this is unrelated. I am grasping for straws. The ballot content deadline in looming and I can't move forward until this issue is resolved. Thanks for understanding.
David Pyke (Aug 04 2021 at 15:27):
YOur build is trying to fetch https://build.fhir.org/ig/HL7/vrdr/fhir-single.xsd when it should be looking for https://build.fhir.org/fhir-single.xsd. Something has been set that's overriding the location of that file.
AbdulMalik Shakir (Aug 04 2021 at 15:34):
Thank you @David Pyke for clarifying the issue. Is there anything that I can do about it?
David Pyke (Aug 04 2021 at 15:36):
I'm not sure. @Mark Iantorno ?
Mark Iantorno (Aug 04 2021 at 15:37):
No clue, but this is a different issue, so can we move the discussion to a separate thread please.
Max Masnick (Aug 04 2021 at 15:51):
In case it helps diagnose what's going on, switching from hl7.fhir.template#current to hl7.base.template#current allows my local build to successfully complete
Lloyd McKenzie (Aug 04 2021 at 16:02):
The version of the template that it's running is ancient - which is why the locations are wrong and why it's yelling about something not being in the ig.ini that we haven't expected to be in the ig.ini for over a year.
Josh Mandel (Aug 04 2021 at 16:13):
@Josh Mandel I think the ask is to be able to pass a parameter in the hook URL that would indicate the version of the publisher to download
Is there a list of allowed values? Otherwise that's totally unsafe.
Josh Mandel (Aug 04 2021 at 16:13):
Is the wrong default being chosen or is the problem that different projects need different defaults?
Josh Mandel (Aug 04 2021 at 16:15):
And just to be clear, this isn't an issue specific to the auto-build pipeline right? (I made some updates a couple of weeks ago to the terminology server URL and then reverted and I'm pretty sure that wouldn't have been able to mess anything up, but if the auto-build is having new issues, I'll review that more carefully.)
Mark Iantorno (Aug 04 2021 at 16:37):
Thanks Josh
Lloyd McKenzie (Aug 04 2021 at 16:38):
We don't actually know what's causing the issue. The desire is to be able to pass in the version to retrieve, not allow execution of any publisher whatsoever. So the risk should be relatively low
Josh Mandel (Aug 04 2021 at 16:49):
Passing in a version of the publisher... the publisher is a .jar file that the auto-build pipeline executes, right? Like https://github.com/FHIR/auto-ig-builder/blob/master/triggers/ig-commit-trigger/index.js#L47-L50 is how this is controlled today -- hard-coded in the auto-build trigger. The build environment then downloads and runs this file.
Lloyd McKenzie (Aug 04 2021 at 16:50):
So you're saying we can just put the version on the end now and it'll work?
Josh Mandel (Aug 04 2021 at 16:53):
Not at all. I'm saying the current trigger has a hard-coded value that caller's can't affect.
Josh Mandel (Aug 04 2021 at 16:54):
And that's very much intentional, because anyone in the world can trigger a build.
Josh Mandel (Aug 04 2021 at 16:54):
If https://github.com/HL7/fhir-ig-publisher/releases/latest/download/publisher.jar isn't the right value to use for the publisher JAR, I can update this or I can create a small set of "allowed" values that the caller could choose among.
Corey Spears (Aug 04 2021 at 17:26):
We obviously don't want to retrieve and execute any ol' jar, but the potential values will be continuing to change as more profile releases are made. Would it be possible to restrict it to a base url https://github.com/HL7/fhir-ig-publisher/releases/, since that is controlled? Or perhaps you could work some magic to enable the last X versions.
Max Masnick (Aug 04 2021 at 17:53):
For anyone who needs a local build to work with the correct template, the following work-around works for me:
- Download https://github.com/HL7/ig-template-fhir/archive/master.zip and unzip
- Rename unzipped folder to
hl7.fhir.template#0.3.2 - Place in
~/.fhir/packages - Change IG to use
"hl7.fhir.template": "0.3.2"rather than"hl7.fhir.template": "current"
Lloyd McKenzie (Aug 04 2021 at 17:54):
Ok, I've figured out at least part of the cause. The https://build.fhir.org/ig/qas.json maintained by the CI-build process has three entries for id hl7.fhir.template:
{
"url": "http://github.com/FHIR/hl7-ig-template",
"package-id": "hl7.fhir.template",
"ig-ver": "0.0.2",
"date": "Thu, 17 Oct, 2019 01:27:56 +0000",
"version": "4.1.0",
"tool": "4.1.0 (3)",
"repo": "FHIR/hl7-ig-template/branches/healthedata1-test-pr/qa.json"
},
{
"url": "http://github.com/FHIR/hl7-ig-template",
"package-id": "hl7.fhir.template",
"ig-ver": "0.0.2",
"date": "Thu, 17 Oct, 2019 01:27:56 +0000",
"version": "4.1.0",
"tool": "4.1.0 (3)",
"repo": "FHIR/hl7-ig-template/branches/healthedata1-test-pr/qa.json"
},
{
"url": "http://github.com/FHIR/hl7-ig-template",
"package-id": "hl7.fhir.template",
"ig-ver": "0.0.2",
"date": "Tue, 03 Aug, 2021 21:59:55 +0000",
"version": "4.6.0",
"tool": "4.6.0 (3)",
"repo": "FHIR/hl7-ig-template/branches/master/qa.json"
},
It's that last one that I think triggered the problem. I had thought we had code that hard-coded what repositories 'trusted' templates were allowed to be loaded from. (We certainly need to have that.) However, I haven't found where that code is or figured out why it didn't keep a build fired against the wrong template repository from updating our official template.
Lloyd McKenzie (Aug 04 2021 at 17:55):
Correcting the issue should just be a matter of pushing a new update to the 'official' template, but I'm holding off on doing that in case there's any more diagnostic information we want to grab before doing so
Lloyd McKenzie (Aug 04 2021 at 17:55):
@Mark Iantorno ?
Lloyd McKenzie (Aug 04 2021 at 17:56):
@Josh Mandel - I think this means we don't need to change the CI build process, at least not urgently.
Mark Iantorno (Aug 04 2021 at 17:57):
I can do a publish for templates...however
Mark Iantorno (Aug 04 2021 at 17:57):
when was this changed? Why is it only causing an issue now
Lloyd McKenzie (Aug 04 2021 at 18:05):
Well, the last entry was created yesterday afternoon (around 5 Eastern). How that build got triggered, I don't know. There was no new commit on the http://github.com/FHIR/hl7-ig-template project. Last commit was actually Sept. 2019.
Mark Iantorno (Aug 04 2021 at 18:07):
So, what I'm trying to figure out is if this is actually caused by the fact there are three entries for id hhl7.fhir.template? Where can I see a changelog for that file? Who/what edits it?
John Moehrke (Aug 04 2021 at 18:08):
does @Eric Haas know? It seems to have some linkage to his fork.
John Moehrke (Aug 04 2021 at 18:16):
is there any audit on the IG dashboard? someone might have used that to kick a build?
Lloyd McKenzie (Aug 04 2021 at 18:30):
His fork was from 2 years ago. The recent build - the one yesterday - was against the master branch of the old repo. I don't know how it got triggered though
John Moehrke (Aug 04 2021 at 18:33):
yup, I looked at his repo and it had not changed either. hence why I wondered about the IG build dashboard
Jean Duteau (Aug 04 2021 at 18:33):
can we trigger a build from the new build? would that "fix" the problem? and then we can try and figure out how the old repo had a build triggered?
Josh Mandel (Aug 04 2021 at 18:33):
can we trigger a build from the new build? would that "fix" the problem?
Anyone can re-trigger a build; this is by design. If the system can break when old content is re-built, it will be unreliable.
Josh Mandel (Aug 04 2021 at 18:34):
@Jean Duteau that seems worth poking at.
Lloyd McKenzie (Aug 04 2021 at 18:34):
Yes, I can. I'm holding off to see if @Mark Iantorno wants to grab any further information before I do so.
Lloyd McKenzie (Aug 04 2021 at 18:34):
I can also remove the old project so it can't be build anymore
Mark Iantorno (Aug 04 2021 at 18:34):
I say go ahead @Lloyd McKenzie , if it fixes the problem, then it's fine. If not...well then we have to dive deeper
Lloyd McKenzie (Aug 04 2021 at 18:35):
Though actually I want the publisher to ignore 'trusted' template builds from any repository other than the trusted repository
John Moehrke (Aug 04 2021 at 18:35):
trusted but NOT!
Lloyd McKenzie (Aug 04 2021 at 18:37):
Running. @Josh Mandel, the rebuild of the old template didn't show up here: https://fhir.github.io/auto-ig-builder/builds.html. Any thoughts on how a build could have been triggered that wouldn't show up there?
Josh Mandel (Aug 04 2021 at 18:39):
Let's back up a bit -- can someone point me to the docs for how auto-ig-builds (are intended to) impact the package registry?
Josh Mandel (Aug 04 2021 at 18:39):
anyone can trigger a build of any branch of any IG at any time -- but the only consequence of triggering a build (to my knowledge/expectations) should be new content (i.e., new build results or error logs) appearing at https://build.fhir.org/ig/:org/:repo/branches/:branch
Josh Mandel (Aug 04 2021 at 18:40):
If something other than that outcome is ever expected/desired, I'd like to be clear on when/how/why.
Mark Iantorno (Aug 04 2021 at 18:48):
I really am curious as to why it stopped working, when none of the core pieces should have changed?
John Moehrke (Aug 04 2021 at 18:48):
yup, retriggering should result in no actual difference.
Mark Iantorno (Aug 04 2021 at 18:53):
I suspect that those three entries for hl7.fhir.template, while not correct, have been working and stable for a while, no?
Mark Iantorno (Aug 04 2021 at 18:58):
@Grahame Grieve Your assistance is required on this when you have the opportunity. Sorry to bother you on vacation.
Lloyd McKenzie (Aug 04 2021 at 19:03):
Re-triggering was a problem because there were two different IGs with the same package id. When the old one was triggered, 'current' suddenly became really old. The real risk is that anyone could create a git project, define a template containing whatever they wanted, link it to the CI build and suddenly anyone who runs their build locally or on the CI build would download that template and run those scripts. I thought we had processes in place to keep that from happening. So I'm going to keep the old project around so we can test and figure out why that protection isn't functioning
Lloyd McKenzie (Aug 04 2021 at 19:04):
Who retrigged and how (and why) is also an open question.
Mark Iantorno (Aug 04 2021 at 19:07):
So, did you remove the 2/3 entries in the list?
Mark Iantorno (Aug 04 2021 at 19:07):
before retriggering the build?
Josh Mandel (Aug 04 2021 at 19:20):
Ok, I've figured out at least part of the cause. The https://build.fhir.org/ig/qas.json maintained by the CI-build process has three entries for id hl7.fhir.template:
WAIT. Is https://build.fhir.org/ig/qas.json used as part of any automated resolution process?
Josh Mandel (Aug 04 2021 at 19:21):
The array you pasted above, Lloyd, was just showing 3 branches of a single repo. It shoudn't have any implications outside of making branch builds appear at http://build.fhir.org/ig/FHIR/hl7-ig-template/branches/
Josh Mandel (Aug 04 2021 at 19:28):
Lloyd, are the issues with projects using unpublished templates? Or are there issues with projects using release versions of templates?
Josh Mandel (Aug 04 2021 at 19:29):
(Trying to see if https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/Dependencies/near/248396516 could be relevant.)
Max Masnick (Aug 04 2021 at 19:46):
I'm curious where the outdated version of the template is actually being downloaded by the IG publisher. It's not packages.fhir.org or packages2.fhir.org -- hl7.fhir.template doesn't exist there.
Max Masnick (Aug 04 2021 at 19:47):
Maybe this is the relevant code in the IG publisher? https://github.com/HL7/fhir-ig-publisher/blob/master/org.hl7.fhir.publisher.core/src/main/java/org/hl7/fhir/igtools/templates/TemplateManager.java
Josh Mandel (Aug 04 2021 at 19:53):
https://github.com/FHIR/sushi/blob/836ab56d73c51dd6bda4a14b51363a2228db7d9f/src/fhirdefs/load.ts#L70-L75 seems to be a potential culprit -- it's looking through any QA builds on the CI server and selecing by date, irrespctive of branch -- so I can create a branch of a template called testing-dont-use, and if it's the newest thing in the qas.json file, it'll get picked up by sushi and used (i.e., I assume: stuck into a user's cache and in turn used by the publisher?)
Josh Mandel (Aug 04 2021 at 19:59):
H/T @Gino Canessa the same logic bug exists in the publisher at https://github.com/hapifhir/org.hl7.fhir.core/blob/bb3b01fd1f3f697645e4b49219b7f7112388d156/org.hl7.fhir.utilities/src/main/java/org/hl7/fhir/utilities/npm/FilesystemPackageCacheManager.java#L650-L665
Josh Mandel (Aug 04 2021 at 19:59):
Is there a documented algorithm for resolution that sushi and org.hl7.fhir.utiltities are both following, or is this convergent evolution?
Josh Mandel (Aug 04 2021 at 20:08):
I think we want to do three things:
-
Document the algorithm for package resolution, including all the inputs
-
Discourage anyone from referring to
#currenttemplates ever, and forbid anyone from referring to#currentin a published build (if that's even possible today) -
Update resolution logic for
#currentto only consider QA builds from a "real" branch (e.g., "main" or "master" or whatever the default branch for a given project might be)
Corey Spears (Aug 04 2021 at 21:28):
Thanks to the Team for getting this working again. :heart:
Josh Mandel (Aug 04 2021 at 21:32):
From FMG discussion, I think the suggestions above are definitely worth pursuing, with (2) being most urgent. Specifically on this point, the important thing is to bind the resolution logic to a specific branch or set of branches in a specific GH repo. So if I say "Please resolve https://whatever#current", the algorithm needs to:
-
2.1. Know the official GH repo + branch where this "https://whatever" dependency can be found. This can be known either a) directly through a content-addressing scheme, where the URL matches some specified pattern like a github URL or any precise enough convention we choose -- e.g., instead of "https://whatever" we might have "https://packages.hl7.org/:service/:org/:repo/:branch", where {service: github, org: jmandel, repo: mytemplate, branch: master} would tell me what GH (or gitlab, or whatever) location is authoriative, or 2) via lookup, if some version of the "https://whatever" package has been previously published in a package server, by looking up something like a "gitUrlForCurrentSources" property in package.json
-
2.2. Filter
qas.jsonbased on this branch + repo, so the resolution algorithm will only consider valid sources for this dependency -- it would be invalid to resolve a dependency to the wrong project or the wrong branch within a project.
Lloyd McKenzie (Aug 04 2021 at 21:36):
Templates are identified by package id, not by Git URL. What we could possibly do is prevent projects from being built if they are not the same Git source as the initial build for that package. (We'd need a formal way to allow projects to move though as templates may shift Git projects from time to time.)
Lloyd McKenzie (Aug 04 2021 at 21:37):
We also need to ensure that our rules around "trusted template source" are in fact being adhered to so that untrusted templates can't run on the CI-build if they contain active content.
Josh Mandel (Aug 04 2021 at 21:37):
I'm saying: for consistent and correct "#current" resolution, there needs to be a deterministic mapping from package ID to git URL. I've proposed two approaches to defining this kind of mapping above (convention-based, or lookup-based -- and these can be combined). Others are possible. We just want to specify something and stick to it.
Josh Mandel (Aug 04 2021 at 21:38):
We also need to ensure that our rules around "trusted template source" are in fact being adhered to so that untrusted templates can't run on the CI-build if they contain active content.
That is true but it's a separate issue, I think
Lloyd McKenzie (Aug 04 2021 at 21:38):
I think the only way to determine 'valid' is "first in wins" with a manual intervention step to allow migration.
Josh Mandel (Aug 04 2021 at 21:38):
Lloyd McKenzie: I think the only way to determine 'valid' is "first in wins" with a manual intervention step to allow migration.
I disagree completely.
Josh Mandel (Aug 04 2021 at 21:39):
Both of the suggestions I made above are alternative ways, so "first in wins" can't be the "only way".
Josh Mandel (Aug 04 2021 at 21:39):
And "first in" still would need to be memorialized somewhere -- qas.json is unsuitable for that purpose because it doesn't keep a full history of the world; an early template might happen to disappear from that file over time, or might transiently disappear from that file... but that doesn't mean someone new should be able to "take over" the package ID.
Lloyd McKenzie (Aug 04 2021 at 21:40):
In a world where there can be 100s or thousands of templates, I don't think we can reasonably rely on a manual process? I don't know how an automated process could tie an arbitrary URL to an arbitrary package id in an automatic fashion other than "first in wins".
Josh Mandel (Aug 04 2021 at 21:40):
Basically, the only thing qas.json can be trusted to answer is "what IG builds are currently hosted at build.fhir.org?"
Lloyd McKenzie (Aug 04 2021 at 21:41):
Wasn't suggesting that qas.json needs to be our way of tracking "first in".
Josh Mandel (Aug 04 2021 at 21:41):
In a world where there can be 100s or thousands of templates, I don't think we can reasonably rely on a manual process?
Agreed; both of my suggestions are automated.
Josh Mandel (Aug 04 2021 at 21:41):
I don't know how an automated process could tie an arbitrary URL to an arbitrary package id
"First in wins" for published templates is fine, I think, because a package repository can serve that role. We'd only need a convention pre-publication, for IGs that have never been published.
Lloyd McKenzie (Aug 04 2021 at 21:42):
I don't know that we can force a git URL convention. There will be times when the organization that owns responsibility for the template isn't necessarily the organization you want in the id. It would certainly break the id convention for a number of existing templates if we did that.
Josh Mandel (Aug 04 2021 at 21:43):
Today:
- the package repository doesn't bind packages to git sources, and
- the https://build.fhir.org/ig/qas.json can't answer the questions "which branches are the official sources for a given package"
Lloyd McKenzie (Aug 04 2021 at 21:43):
So I'm not a fan of #1. I think your #2 solution is a first in wins solution, though we might want to leverage something other than qas.json.
Josh Mandel (Aug 04 2021 at 21:43):
There will be times when the organization that owns responsibility for the template isn't necessarily the organization you want in the id.
URL conventions are only necessary if you care about referencing an unpublished template. In which case you don't really have or need a package ID.
Josh Mandel (Aug 04 2021 at 21:44):
though we might want to leverage something other than qas.json.
We 100% cannot use qas.json for this.
Lloyd McKenzie (Aug 04 2021 at 21:44):
The HL7 git organization currently publishes templates that don't include 'hl7' as part of their package id.
Josh Mandel (Aug 04 2021 at 21:45):
I'm not following your point re: "hl7 as part of their package id". So what?
Lloyd McKenzie (Aug 04 2021 at 21:45):
#1 is saying that the structure of the Git URL drives the package id - at least that's my understanding?
Lloyd McKenzie (Aug 04 2021 at 21:46):
I'm saying the values of the Git URL and package id should be independent, so the linkage needs to be established some other way.
Lloyd McKenzie (Aug 04 2021 at 21:47):
Does that make sense?
Josh Mandel (Aug 04 2021 at 21:55):
Other way around: I was saying that the structure of the package ID could be deterministically mapped to a git branch.
Josh Mandel (Aug 04 2021 at 21:55):
That deterministic mapping only matters when you're working on a template pre-publication.
Josh Mandel (Aug 04 2021 at 21:56):
Once you're ready to publish your work, you can rely on the the package server as a global source of truth, and name your package according to whatever rules/conventions govern your work.
Josh Mandel (Aug 04 2021 at 21:57):
A different way to skin this: just require everyone to publish templates with the package server when they start work, even before they have content ready. That's probably manageable too, if a bit clunky (work that gets abandoned before the author really "Wanted" to publish it would still pollute the package server, but no big deal).
Lloyd McKenzie (Aug 04 2021 at 22:01):
I'm saying we don't want to change existing package ids (which would break existing IGs) or Git URLs (which would break what organizations can maintain stuff and would also force package id changes if you ever switched project owners).
Lloyd McKenzie (Aug 04 2021 at 22:02):
I don't understand the pre-publication vs. post-publication process.
Lloyd McKenzie (Aug 04 2021 at 22:03):
What do you mean by "publish templates with the package server"?
Josh Mandel (Aug 04 2021 at 22:48):
How are templates published today? What's the official process for resolving a (non-"current") template? Wherever published packages live is what I mean by package server.
Lloyd McKenzie (Aug 04 2021 at 23:19):
Anyone who wants to create a template can do so by putting it on Github somewhere and adding a webhook to the CI-build. Publishing (successfully) on the CIBuild causes the package.tgz file on the CI build. I don't actually know what the process is for doing a formal package release - Grahame does some magic that involves creating releases for all dependency packages for the HL7 IGs - if you create a release of 'base', that means an update to HL7, FHIR, Da Vinci and posslibly a couple of others at this point. As for how external folks get official packages into the package server, I don't know.
Josh Mandel (Aug 04 2021 at 23:23):
Based on what you're saying, it sounds like we don't have a clear process for community development of templates. I mean, there is no algorithm for resolving a published template unless you go through the hl7 repository as the source of truth.
It seems like there is a desire to treat build.fhir.org as a kind of secondary package repository without most of the features of a package repository -- this is a mistake. A proper repository needs to provide well defined namespaces and clear permissions about who can write to each namespace.
Lloyd McKenzie (Aug 04 2021 at 23:30):
Correct. Anyone can create a template with the id of their choosing, and anyone can host it at the Git location of their choosing. I'm not sure we want to change that.
Our general package repository has clear controls over writing HL7 artifacts. I don't know what the rules are for anyone else.
Elliot Silver (Aug 04 2021 at 23:37):
Out of curiosity, is there a process to prevent two IGs from claiming the same ids?
Lloyd McKenzie (Aug 04 2021 at 23:40):
Two templates? No. Which is exactly what caused the issue we just had. Two IG projects had the same id. One was old and was developed under the FHIR organization before we decided that, because we needed tight control over the scripts in it, that it should live in the HL7 organization. The old project was never removed though. So when someone, somehow, triggered the build on it, we had an issue. Obviously that's not an acceptable situation, so the question is how we prevent multiple IGs from publishing the same package ids in the future.
Gino Canessa (Aug 05 2021 at 00:06):
Noting that I’m skipping some messages (so may have been discussed), but versioning could be handled by release tagging in GitHub as well.. it already has ‘latest’ and linking releases to commits.
Would make “a new version of the template” intentional and should be straightforward to modify the resolution logic.
Elliot Silver (Aug 05 2021 at 01:06):
@Lloyd McKenzie , no I meant two IGs. I see that we've just got through an issues where two templates have the same ids, but I was wondering what is to prevent two IGs from both claiming the same id. Can I create a new IG and call it hl7.fhir.us.core.argo? I mean, I doubt that policy would allow it, but it seems a great way to mess things up for a couple of days if I was so inclined.
Lloyd McKenzie (Aug 05 2021 at 01:34):
Short answer, for the 'current' IG, nothing would stop you from doing that at all - other than we could easily tell what Git repository it came from and arrange to put something nasty in your beer at the next face-to-face WGM. For someone who doesn't drink beer, there wouldn't be much we could do :frown:. So yes, this is an issue we need to address for more than just templates.
Josh Mandel (Aug 05 2021 at 02:37):
Two templates? No. Which is exactly what caused the issue we just had. Two IG projects had the same id.
I don't think that's correct. That would have been possible but in fact, all entries in qas.json were different branches in the same (official) git repository (GitHub/FHIR/hl7-ig-template).
Josh Mandel (Aug 05 2021 at 02:38):
I guess we'd better write out a list of requirements.
I think everyone agrees:
- Anyone should be able to create a template for their own needs
Josh Mandel (Aug 05 2021 at 02:40):
- publication tooling must be able to resolve published template IDs (anywhere the publisher runs -- whether locally, in hl7's auto build environment, or elsewhere)
Josh Mandel (Aug 05 2021 at 02:41):
- ? The resolution algorithm takes in a "registry" parameter they defaults to the official hl7 package registry, and in the auto build environment this can't be overridden (but perhaps in other environments that would be perfect)
Josh Mandel (Aug 05 2021 at 02:42):
Are these fair?
Lloyd McKenzie (Aug 05 2021 at 02:56):
No, they weren't. Some were from Github/FHIR, but the official was from Github/HL7
Josh Mandel (Aug 05 2021 at 02:57):
(I don't think it's a requirement for the hl7 auto build infrastructure to support arbitrary git sources for templates that have never been published in the hl7 package repository and aren't on track to be published in the hl7 package repository.)
Lloyd McKenzie (Aug 05 2021 at 02:58):
It's a requirement that any organization that wants to use the CI build process can create templates and have them work. I don't know what the process is to get them published in the HL7 package repository.
Josh Mandel (Aug 05 2021 at 02:58):
In your post above, all 3 of these were in the official hl7 GitHub repository, no?
Josh Mandel (Aug 05 2021 at 02:59):
It's a requirement that any organization that wants to use the CI build process can create templates and have them work. I don't know what the process is to get them published in the HL7 package repository.
Where is this requirement coming from, and who is responsible for implementing it safely?
Lloyd McKenzie (Aug 05 2021 at 03:00):
Sorry, that was a paste error. First one should have been:
{
"url": "http://fhir.org/templates/hl7.fhir.template",
"package-id": "hl7.fhir.template",
"ig-ver": "0.3.2",
"date": "Tue, 29 Sep, 2020 06:55:16 +0000",
"version": "4.5.0",
"tool": "4.5.0 (3)",
"repo": "HL7/ig-template-fhir/branches/master/qa.json"
},
Lloyd McKenzie (Aug 05 2021 at 03:00):
That one's actually the authoritative version
Josh Mandel (Aug 05 2021 at 03:00):
Does "create templates and have them work" refer to the "current build" of never-yet-published template?
Lloyd McKenzie (Aug 05 2021 at 03:01):
Like I said, I'm not sure what the process is to get something into the registry for anything other than HL7-maintained templates.
Lloyd McKenzie (Aug 05 2021 at 03:02):
But there are a growing number of templates for IGs that use our CI build process that aren't HL7-managed.
Josh Mandel (Aug 05 2021 at 03:04):
That's fine -- but each of these templates need to have a known authoritative source meaning (I think) they need to be registered in an official hl7 package repository, or we need a decentralized algorithm for resolving the authoritative source for a given template package ID.
Josh Mandel (Aug 05 2021 at 03:05):
(same applies to non template packages as far as I can tell. Like someone could create a fake US Core they would mess up anyone's depending on "uscore#current")
Lloyd McKenzie (Aug 05 2021 at 03:22):
Problem is, I don't think that the set of those using the CI build for their IGs is necessarily the set who want their IGs in HL7's registry. Those two things have historically been separated. Do you think there's a problem where we just track what IGs have been built and what repos they've come from and refuse to accept IGs with the same IG coming from a different repo unless someone's specifically come to us and said "Hey, we've moved this"?
Lloyd McKenzie (Aug 05 2021 at 03:23):
That keeps the manual effort down to only handling moves, which presumably would be infrequent
Lloyd McKenzie (Aug 05 2021 at 03:26):
We might be able to impose use of the registry for templates, given that (presumably), those managing IG templates will want to support versions other than 'current' eventually, and the only place the publisher is going to look for specific versions of templates is in our package repository. But we can't impose that on IGs being built.
Josh Mandel (Aug 05 2021 at 03:29):
Maintaining these records properly and reliably would require a different approach than the current auto build infrastructure. If we wanted to do this I would think about implementing a package server ("npm registry" or whatever) for it, so every build gets posted to a "CI" package server even if it's just transient stuff. Otherwise we're going to wind up recreating most of the functionality of a package server but with a slightly different API, which makes the whole resolution system more complicated.
Josh Mandel (Aug 05 2021 at 03:56):
I also realize I'm not sure for templates: is there a build step required to create the contents of a template package? Or would cloning a template's git repository gve you everything you needed to run with?
Lloyd McKenzie (Aug 05 2021 at 03:58):
I'm open to whatever software approach you think best. I think key requirements are:
- No need for any manual action to build an IG or template other than set up your webhook
- We would ignore any branches other than master or main
- If someone wants to move their Git repository somewhere else, it's straightforward for Joshua or someone similar to make that happen.
To create a simple template, you can just copy someone else's, change the package info and substitute your color scheme and logo for whatever was in the original.
Josh Mandel (Aug 05 2021 at 04:25):
We're already failing on "ignore" and "move" requirements today. My key recommendation is to tie package ids to authoritative git source URLs -- whether by naming convention or centralized registry.
Glibly, you can't cheat at https://en.m.wikipedia.org/wiki/Zooko%27s_triangle
Josh Mandel (Aug 05 2021 at 04:28):
I'm thinking about whether I can come around to your conception of trust on first use here, Lloyd. Will sleep on it.
Josh Mandel (Aug 05 2021 at 04:46):
I'd rather see dependencies on current made explicit like:
{
"name": "hl7.example.template",
"type": "fhir.template",
"license": "CC0-1.0",
"description": "Example template",
"author": "http://hl7.org/fhir",
"canonical": "http://example.org/templates/hl7.fhir.template",
"base": "hl7.base.template",
"dependencies": {
"hl7.base.template": "https://build.fhir.org/ig/HL7/ig-template-base/package.tgz"
// ^^ instead of "current", use a full, explicit URL. This is much more reliable.
// Can even include a branch
// Can even point to somebody's fork for debugging purposes
},
"version": "0.3.2"
}
Josh Mandel (Aug 05 2021 at 04:55):
This is consistent with how NPM dependencies work already: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#urls-as-dependencies
Josh Mandel (Aug 05 2021 at 04:56):
and correctly expresses semantics we know how to enforce (i.e., "I want use whatever's sitting at this location on the CI server right now, and treat that as my "hl7.base.template".)
Lloyd McKenzie (Aug 05 2021 at 14:53):
Changing how dependencies work is going to break all the existing infrastructure - every template, every IG that uses templates. So we should only pursue that path if we genuinely have no alternative. Also, I'm not sure how that reference gets resolved when talking about specific versions
Josh Mandel (Aug 05 2021 at 15:28):
There's a finite list of existing implementation guides in the auto build infrastructure and we can just create a mapping file to bring them all into the future if we can define a better future that will be more stable and easy to manage.
We are talking about what should be an edge case of references to material that is not published and is subject to change at any moment; most packages should not have a dependency on this kind of content.
Kevin Power (Aug 05 2021 at 15:35):
@Lloyd McKenzie said:
We would ignore any branches other than master or main
Are you talking about build for IGs? I like the fact that creating a branch for our IG triggers auto-build so that we can easily let others see the updates. I am not a huge fan of that requirement? Or, am I misunderstanding your comment?
Lloyd McKenzie (Aug 05 2021 at 15:38):
@Kevin Power You'll still be able to build branches, but branches of templates will never be treated as 'current', nor would they be considered as part of the "first in wins" approach to what Git URL is tied to a particular package id.
Kevin Power (Aug 05 2021 at 15:39):
Got it, thanks @Lloyd McKenzie
Lloyd McKenzie (Aug 05 2021 at 15:40):
@Josh Mandel The package dependency structure we're using right now is tied into an external standard - is a URL even allowed in that location? Even if we have mappings, it's going to impose change on everyone at some point, no? Also, being able to say #current as opposed to a version isn't really something we want to change. It should be super easy to change from pointing to current vs. a specific version. If you have to drop the package id and replace with a Git URL, that creates complexity for the users.
Lloyd McKenzie (Aug 05 2021 at 15:41):
Also @Kevin Power it means that if you have a dependency on 'current', it'll always only resolve to the 'main' or 'master' branch, never another branch.
Josh Mandel (Aug 05 2021 at 16:22):
The package dependency structure we're using right now is tied into an external standard - is a URL even allowed in that location?
Do you mean NPM? Yes, NPM supports dependency resolution by tgz URL (see the link in my post above)
Lloyd McKenzie (Aug 05 2021 at 16:34):
I'd still prefer that we keep ids as they are and continue to use #current to signify "grab from Github" and have the resolution of the URL outside the dependency declaration. That moves complexity from authors to infrastructure, which is where I think it should be and avoids making everyone update everything that already exists. If we were to change approach, I'd want Grahame to ok it - which means that we're vulnerable for longer.
Are there specific problems you see in a "first in wins" approach?
Josh Mandel (Aug 05 2021 at 16:45):
keep ids as they are and continue to use #current to signify
Why not use a more explicit reference?
Are there specific problems you see in a "first in wins" approach?
Yes -- it's brittle and we don't have the tools to manage it.
Josh Mandel (Aug 05 2021 at 16:46):
Using "#current" also prevents many other integration scenarios (say: grabbing source from another branch for testing).
Josh Mandel (Aug 05 2021 at 16:47):
Using explicit URLs makes resolution simple (less error prone); is clear; and shouldn't pack "surprises".
Lloyd McKenzie (Aug 05 2021 at 17:10):
Because when referring to officially released packages, they'll be using package ids - it's much easier for people to switch between hl7.gravity.template#current and hl7.gravity.template#1.3.0 than it is to switch to and from https://github.com/HL7/ig-template-gravity - to me, that's more error prone because few people are going to understand what the correlation is. It also means that if we ever move the gravity template, all IGs and dependent templates have to change instead of just a registry entry.
Rather than saying "we have no tools to manage it", I think it's more accurate to say, "the tool we're using to manage it isn't doing everything we need it to".
I understand that tooling has an ongoing cost. Complexity for authors also has an ongoing cost. My take is the cost of maintaining a centralized file that maps between package id and Git URL and is auto-updated the first time a new package is seen is significantly lower than the short term cost of everyone needing to revamp how their IGs reference templates and templates reference each other, as well as the ongoing cost of complexity in switching between 'current' and 'fixed release' (which we want to be super-easy) and the complexity of managing migrations of templates and occasionally IGs
David Pyke (Aug 05 2021 at 17:13):
deleted, wrong thread
Josh Mandel (Aug 05 2021 at 17:56):
Because when referring to officially released packages, they'll be using package ids - it's much easier for people to switch between
hl7.gravity.template#currentandhl7.gravity.template#1.3.0than it is to switch to and fromhttps://github.com/HL7/ig-template-gravity- to me, that's more error prone
I am not suggesting changing the package ID of these. I'm only suggesting changing the version from the opaque string "current" to a transparent uri. Package ID stays the same in the dependencies list; in the example I showed above, the dependency is still called "hl7.fhir.base", and only the version needs to be updated
Lloyd McKenzie (Aug 05 2021 at 18:32):
You had said
"hl7.base.template": "https://build.fhir.org/ig/HL7/ig-template-base/package.tgz"
not
"hl7.base.template": "fhir.base.template#https://build.fhir.org/ig/HL7/ig-template-base/package.tgz"
But even
Lloyd McKenzie (Aug 05 2021 at 18:33):
But even that is far more confusing to implementers than #current. #current is something that would be consistent across all IGs. The URL approach requires authors to know the Git location of the template or IG they're depending on.
Lloyd McKenzie (Aug 05 2021 at 18:34):
Also, this wouldn't just affect HL7's tooling, it would also impact Simplifier I believe because they use the same mechanisms to reference IG dependencies by package id.
Gino Canessa (Aug 05 2021 at 18:59):
I think the issue is disambiguating #current between 'latest release' and 'latest CI build'.
Generally speaking, IGs need to use 'latest release'. Template developers are the only ones that should ever be using 'latest CI build'. If we conflate the two, then we'll keep running into problems like this (e.g., someone checks something in that, intentionally or not, breaks #allTheIGs).
Part of the issue is that many of the interested parties are the same people wearing two hats.
Josh Mandel (Aug 05 2021 at 19:05):
"hl7.base.template": "https://build.fhir.org/ig/HL7/ig-template-base/package.tgz"
^^ that's correct -- the purpose of the NPM dependencies object is to tell NPM how to resolve a specific package ID (on the left of the :, like "hl7.base.template") to specific versioned content. In this case, the "version" (the part on the right of the :) is the URL of a tarball. https://docs.npmjs.com/cli/v7/configuring-npm/package-json#urls-as-dependencies provides the background and examples.
Lloyd McKenzie (Aug 05 2021 at 19:18):
If you don't specify any version at all, you'll get the latest official release. Based on the testing infrastructure we have, there's been a conscious choice to have most IGs running on the CI build, falling back to latest release only if they have problems. At some point we might have test infrastructure that will make it practical to change that, but that's not the question up for discussion right now.
Josh Mandel (Aug 05 2021 at 19:25):
If you don't specify any version at all, you'll get the latest official release.
Is an NPM package.json file valid if it doesn't specify a version for a dependency? How would you write this down?
Lloyd McKenzie (Aug 05 2021 at 19:29):
I think IGs must declare versions. Template references in the IG.ini don't have to
Lloyd McKenzie (Aug 05 2021 at 19:30):
If you specify #current, you get latest build (which is what most people use now, and we generally want them to). If you omit any '#', you get most recent release. If you specify #1.2.3, you get that release.
Lloyd McKenzie (Aug 05 2021 at 19:32):
I don't understand why the need we have to create a fixed link between the Git URL and the package id necessitates changing this convention.
Josh Mandel (Aug 05 2021 at 20:48):
3.2.1 is a version, which is one (good!) way to resolve a dependency; so is ^3.0 or 3.x to express "anything compatible with 3"... but you can just as well use "https://build.fhir.org/ig/HL7/ig-template-base/package.tgz" as a way to say "whatever version is present at this URL right now. That seems to fully cover the use case for the non-standard "current", and avoids ambiguity.
Lloyd McKenzie (Aug 05 2021 at 22:34):
But it requires knowledge of the Git location by those making the change and makes switching between 'current build' and 'current release' hard. Those are expensive things. I haven't yet heard why we can't just beef up our current solution to just maintain a JSON file of Git URLs to package ID bindings, treat first in as winner, and keep everything the same for all IGs and users. The reality is that when Grahame set up this process, he could have required people to list the Git location for the 'current' release and very consciously chose not to. I believe he had good reasons for that decision. Obviously relying on the file we are for doing the linkage isn't appropriate and we have some logic we need to add to the process, but I don't understand why that won't work, be robust and solve our problem while minimizing both short and long-term impact on everyone else.
Lloyd McKenzie (Aug 10 2021 at 23:54):
We discussed this on the IG Authoring call today. Those on the call (only 3 of us) agreed that we want to stick with #current and find a tooling solution to create a binding between the Git URL and the IG package. I guess the question is, how do we move forward on this? Right now, @Josh Mandel is the only one who knows how to manage that code, though @Elliot Silver has at least done a 'look-see'. We need this hole closed pretty urgently because there could be far worse outcomes than just having the build go down for a day. The proposed change is as follows:
- when the CI build runs, check to see if the invoking branch is 'master' or 'main'
- if so, check a shared file to see if the IG id already exists in the file
- if not, add a row in the file with the IG id and the Git project URL
Once that's in place, I can update the IGPublisher to drive the 'current' build resolver to look at the new file rather than the existing file.
How do we move this forward quickly?
Josh Mandel (Aug 11 2021 at 00:36):
I'm concerned about this conclusion, because I don't think it's based on things that we can safely deliver @Lloyd McKenzie .
Josh Mandel (Aug 11 2021 at 00:38):
If #current doesn't reference a package that the package server hosts, and doesn't directly specify a source location, then we're outside the scope of npm package management.
Josh Mandel (Aug 11 2021 at 00:38):
That's not a good place to be.
Josh Mandel (Aug 11 2021 at 00:40):
(Short term fix: create a list of known build.fhir.org/ig/... URLs for every package that exists, and have the existing tools look up the URL in that list whenever it encounters "#current". For obvious reasons -- lack of compliance with standard npm tooling means ongoing customization; requires a long term state management commitment -- maintaining this in the long run would be painful and costly. To limit that long-run cost: deprecate the implicit "#current" syntax and have authors reference a published release or a specific package URL.)
Lloyd McKenzie (Aug 11 2021 at 01:11):
We want to be able to point to current - and we want most IGs to do that. We also want it to be super-easy to revert back to the official release without any author needing to know the Git URL. That's the desired long-term outcome.
I don't understand how maintaining it in the long run would be painful or costly. Once the change is made to the CI build process and the publisher, the only ongoing cost should be the occasional manual update to the file if a package migrates from one Git repository to another. That is likely to happen only a few times a year.
Where do you expect the costs to come from? What are the safety concerns?
Elliot Silver (Aug 11 2021 at 01:13):
Sorry that I missed today. I’m not sure what @Lloyd McKenzie thinks I’ve had a look-see at, but I don’t think I’ve investigated anything relevant.
Josh Mandel (Aug 11 2021 at 02:14):
We already have multiple independent tools that can resolve dependencies for a FHIR IG (the publisher, and sushi). Maintaining these is expensive and there will be more. Spreading the complexity of non-standard package resolution -- when npm already has a perfectly good answer to this problem -- raises the cost of writing and maintaining custom tools, not to mention contributing to security risks when tools get it wrong. We should be ruthlessly simplifying and shrinking our operational burden here.
It's also really unfair to ask IG authors to cope with bleeding edge dependencies from a CI build; template authors should publish template versions every time there's a coherent set of changes tested and ready for use, and IG authors can opt in to the latest published template that's compatible with their work (e.g. by specifying a version like 4.* or an even a tag like latest in their package.json).
Josh Mandel (Aug 11 2021 at 02:16):
I'm happy to talk through this on a call BTW!
Lloyd McKenzie (Aug 11 2021 at 02:53):
For templates, IG developers will either get the bleeding edge with the 'current' release or they'll get it with the 'latest' release if problems aren't found in the period before they're migrated to an official release. We don't have the resources to do more at the moment. For IG dependencies, current is used regularly when multiple interrelated guides are in development together and there's no desire to lock to specific versions.
I don't understand what maintenance you're envisioning. The process of looking up the correspondence between 'current' and the Git URL is already in place and works with the existing tool suite - Publisher, SUSHI and (I believe) Firely's tools. All we're talking about is changing which file is pointed at and the logic of pointing to it.
NPM doesn't do what we need it to do. We've shown that the workaround works, it's just that the file we were pointing at wasn't suitable for the purpose and the appropriate logic wasn't in place to make it safe.
I've asked for the topic to be added to tomorrow's FMG agenda.
Josh Mandel (Aug 11 2021 at 04:45):
NPM doesn't do what we need
Let's try to unpack this on a call. Not sure we should subject FMG to it, but I'm game if we have space on the agenda.
Grahame Grieve (Aug 17 2021 at 04:52):
can someone summarise this long thread for me? What's the actual problem>?
Lloyd McKenzie (Aug 17 2021 at 04:58):
Anyone can create a fork of an IG and, if they leave the IG packageId the same and build using the CI-build, their Git project becomes the 'current' build from the perspective of package resolution. The same is true for templates.
I've just submitted a pull request for a temporary fix for this (https://github.com/hapifhir/org.hl7.fhir.core/pull/57), though it's failing and I can't see the test logs to see why. (Have pinged Mark)
Lloyd McKenzie (Aug 17 2021 at 04:59):
My fix is temporary. Josh would like the long-term-fix to be made by customizing the package server (if we don't ditch #current entirely).
Grahame Grieve (Aug 17 2021 at 05:02):
we don't want to ditch #current, that's for sure
Grahame Grieve (Aug 17 2021 at 05:02):
but what's it got to do with the package server?
Gino Canessa (Aug 17 2021 at 12:33):
TLDR (from my perspective): we don’t use the package server to resolve #current, it has custom logic to pull from GH. This is fragile and hard to discover, and is relevant for templates and IG packages.
Josh Mandel (Aug 17 2021 at 13:39):
And more specifically: the custom logic, never formally documented but currently implemented in the IG publisher and in sushi independently (at least!), has a serious bug that allows anyone in the world to substitute their own content for any package's "#current".
In fmg last week we decided to hard code (in a GitHub repo) a map specifying the location where any given package's "#current" can be found, and augment the current custom logic by having it consult this map rather than blindly matching an arbitrary entry in the build server.
-
I'm looking this change as a temporary measure to prevent current implementation guides from breaking while we switch over to using existing npm features that already cover this use case (package URLs can be used as versions in a packages.json dependencies map). This does not require package server customization.
-
OTOH, Lloyd is looking at this as the first step of a longer term deeper customization, where we develop automated tooling as a kind of shadow package server to determine which GitHub repositories are responsible for which packages and an automated first come first serve database :-)
At least we were able to agree on a common first step to plug the immediate hole. I don't think the step has been implemented yet.
Lloyd McKenzie (Aug 17 2021 at 15:45):
The Git project and file have been created - they're here: https://github.com/hl7/package-info
I've made and tested and submitted a pull request to use that new file. It's tripping over something Mark says Grahame's working on and Mark's also asked for some cosmetic changes which I'll make.
Lloyd is totally fine if this functionality gets moved into the package server. I'm not as fussed as Josh about having supplementary custom code, but agree that having it handled by the package server would be better. What Lloyd is passionate about is that from an end-user perspective, #current works as it always did. (But that there's an authoritative source for '#current' that can't be overridden by someone externally, either by accident or on purpose without oversight.)
Chris Moesel (Aug 17 2021 at 17:06):
We can update SUSHI to use this, but I would like to understand how new projects get added to the list. #current is actually the only option for referring to a package that hasn't yet been balloted (aside from #dev) -- so I would think that it's important for new projects to know how to get themselves added to the list. Despite the issues w/ the former approach (and I agree there are issues), one advantage was that new projects were automatically registered w/ no manual intervention needed.
So... if a user specifies a #current dependency and SUSHI cannot find it in the new (temporary) package-info file, I would like for SUSHI to be able to provide the user a message indicating how they can get that project added to the package-info. But before I can create that message, I need to know the process myself. ;-)
Also, just as an aside, SUSHI does not attempt to download the template at all. So the original issue (related to hl7.fhir.template) is actually based on how the IG publisher resolves templates (not how SUSHI resolves dependencies). That said, as noted, the underlying concern obviously applies to both.
Josh Mandel (Aug 17 2021 at 17:06):
(my perspective on this is that pointing to the very latest bleeding edge commit on git is generally not what anybody wants, even if they think they do. We should be issuing frequent releases so that functionality that has actually been tested is always available as a release right away. This dramatically alleviates the need for anyone to point to a bleeding edge commit, and of course if they do want to point to a bleeding edge commit they can do so with a url.)
Josh Mandel (Aug 17 2021 at 17:06):
Of course using URL based dependencies for this kind of thing also allows you to point to other branches, other repositories, hot fixes, and so on. It's a much more general and reliable pattern then using a magic string called current.
Chris Moesel (Aug 17 2021 at 17:09):
Josh Mandel said:
(my perspective on this is that pointing to the very latest bleeding edge commit on git is generally not what anybody wants, even if they think they do. We should be issuing frequent releases so that functionality that has actually been tested is always available as a release right away. This dramatically alleviates the need for anyone to point to a bleeding edge commit, and of course if they do want to point to a bleeding edge commit they can do so with a url.)
Just to be clear, SUSHI does not interpret #current as "last commit on git" -- but rather as "last successful build on CI". We don't really want SUSHI to have to build dependencies from source -- we want to always use pre-built packages.
Josh Mandel (Aug 17 2021 at 17:09):
Yes you're right, I was being imprecise there. I should have written the latest successfully completed build, rather than the latest commit. This still does not imply a build that has been tested or is working or ready for adoption.
Lloyd McKenzie (Aug 17 2021 at 19:05):
When #current is used, it's because someone absolutely wants the last successful build. And there is no chance of there being a release for weeks or likely months. Releases are when you have something well tested and stable. There's often a need to use things that aren't at that point. That requirement isn't going away.
Gino Canessa (Aug 17 2021 at 19:43):
So how would someone specify that they want the latest stable build?
Grahame Grieve (Aug 17 2021 at 19:58):
just don't specify a version, you get the latest release
Grahame Grieve (Aug 17 2021 at 19:58):
I think #current makes sense as it is, but it's being used too much
Grahame Grieve (Aug 17 2021 at 19:59):
allows anyone in the world to substitute their own content for any package's "#current"
Obviously this is a bug, but I don't see how changing the package server helps
Grahame Grieve (Aug 17 2021 at 20:00):
I totally dislike the idea of maintaining this file. That's a crap solution.
Josh Mandel (Aug 17 2021 at 20:09):
I totally dislike the idea of maintaining this file. That's a crap solution.
I agree it's not a file we want to maintain! It's a spot fix for a security vulnerability.
Josh Mandel (Aug 17 2021 at 20:09):
We should talk through the solution space in more detail maybe on a call.
Josh Mandel (Aug 17 2021 at 20:10):
When #current is used, it's because someone absolutely wants the last successful build.
I don't think this is true. I think it is used everywhere because people copy and paste it from example documentation, which should not use this syntax.
Josh Mandel (Aug 17 2021 at 20:11):
I was also unable to find where our templates are officially published in a package server. @Grahame Grieve for example on what package server do releases of the official hl7 template get published?
Grahame Grieve (Aug 17 2021 at 20:11):
well, it's what it's intended for. I can't help it if people use something else, though the shouldn't
Grahame Grieve (Aug 17 2021 at 20:12):
Josh Mandel (Aug 17 2021 at 20:19):
Both of these return the same (empty) response:
$ npm --registry https://packages2.fhir.org/packages view hl7.fhir.template
$ npm --registry https://packages2.fhir.org/packages view does.not.exist.fhir.template
Josh Mandel (Aug 17 2021 at 20:19):
(And I don't see hl7.fhir.template or fhir.base.template at https://packages2.fhir.org/packages/catalog in the UI.)
Josh Mandel (Aug 17 2021 at 20:23):
(Packages that are present, like hl7.fhir.us.core, fail in different ways.)
Errors resolving and installing "hl7.fhir.us.core"
Grahame Grieve (Aug 17 2021 at 20:37):
packages2.fhir.org is not a general npm server; it only implements the part of the npm spec documented here: https://docs.fire.ly/projects/Simplifier/api.html#package-server-api.
Grahame Grieve (Aug 17 2021 at 20:38):
packages2.fhir.org is not really intended to be a long term thing, but maybe it's going to have to be; it allows me to work around various limitations in packages.fhir.org
Lloyd McKenzie (Aug 17 2021 at 20:43):
We need current for two reasons:
- when you're writing two IGs in parallel and one depends on the other
- with templates so that people can easily experiment with what's 'current' and make sure they're happy with it.
I understand that people don't like #2 - the idea of IG authors being part of the testing process may not be appealing, but it's reality and it's not a reality that's going to change without a huge infusion of resources (which seems unlikely).
Grahame Grieve (Aug 17 2021 at 20:47):
it sounds to me like some/many/most IGs are depending on #current templates when they shouldn't be .
Josh Mandel (Aug 17 2021 at 20:50):
when you're writing two IGs in parallel and one depends on the other
This can directly be addressed with URL based references
Grahame Grieve (Aug 17 2021 at 20:51):
I don't see how or why that should be necessary
Josh Mandel (Aug 17 2021 at 20:51):
with templates so that people can easily experiment with what's 'current' and make sure they're happy with it.
This can be addressed with URL based references, or (better!) by generally publishing to npm every time a template is in a working state
Josh Mandel (Aug 17 2021 at 20:51):
it sounds to me like some/many/most IGs are depending on #current templates when they shouldn't be .
Precisely.
Josh Mandel (Aug 17 2021 at 20:52):
I understand that people don't like #2 - the idea of IG authors being part of the testing process may not be appealing, but it's reality and it's not a reality that's going to change
This is a pretty hostile stance for IG authors, who are just trying to get through their day.
Lloyd McKenzie (Aug 17 2021 at 20:56):
They should be using #current, because otherwise they're going to get hit with the identical changes once we put out an official release. Once something is committed to current, it's staying that way unless someone who's not a developer complains. If the only time anyone notices is when it's an official release, then that's what's going to happen.
Lloyd McKenzie (Aug 17 2021 at 20:56):
We want it to be easy to switch between #current and latest release. Switching to a full blown URL is too painful and makes something we want to be easy unnecessarily hard.
Grahame Grieve (Aug 17 2021 at 21:07):
I still think that most IGs should be running on the latest release, not #current.
Grahame Grieve (Aug 17 2021 at 21:08):
but things still need to be tested, and we don't have a budget for testing other than IG authors doing the testing, @Josh Mandel, so in practice they are part of the testing process, however things work
Josh Mandel (Aug 17 2021 at 21:35):
things still need to be tested, and we don't have a budget for testing other than IG authors doing the testing
It's all about time management. For example in our auto-build cluster I have some old cruft that I know I need to update. But I can do it on my own terms, when I'm ready to make the switch. I don't need to stop making bugfixes and feature improvements to go fight an upgrade fire.
Josh Mandel (Aug 17 2021 at 21:36):
Yes, IG authors need to test and review changes. But that shouldn't need to block progress on IG features.
Josh Mandel (Aug 17 2021 at 21:37):
We can run a bunch of builds in the background and tell IG authors: "Click here to see your latest release re-built with our latest template, and let us know if anything looks off". That's way better than "hey, your work is blocked now."
Grahame Grieve (Aug 17 2021 at 21:49):
obviously the work shouldn't get blocked because of template changes, but they never have. What blocked them was a bug in the build code
Grahame Grieve (Aug 17 2021 at 21:50):
how about this for a bug: the current template code always use #current if you don't specify the veresion
Grahame Grieve (Aug 17 2021 at 21:53):
and when I fix that, then it turns out that the template packages aren't being loaded onto the package server. I'll have to fix that...
Grahame Grieve (Aug 17 2021 at 21:54):
@Josh Mandel That'll be why you didn't see them
Josh Mandel (Aug 17 2021 at 22:49):
Yep. This is progress :-)
Lloyd McKenzie (Aug 18 2021 at 00:12):
If #current doesn't work for someone, that's never a blocker. They just strip it off to get the most recent 'official' release. That's a super-easy thing for them to do. #current should never contain cruft. Nothing should ever be in the CI build 'master' branch that hasn't been tested as much as it's going to be and is believed to work. If anyone is messing around and wants to share, they do that with a branch other than master.
Grahame Grieve (Aug 18 2021 at 00:43):
They just strip it off to get the most recent 'official' release
except that no one ever has because that doesn't work
Grahame Grieve (Aug 18 2021 at 04:02):
it will work from the next release
Grahame Grieve (Aug 18 2021 at 05:32):
now. turning to the change. The problem is that if someone clones the repo, and then gets the autobuilder to build it, their latest master overrides the last build of that id, unless they change the id?
Grahame Grieve (Aug 18 2021 at 05:32):
that's a feature, not a problem, for most cases. So why has it suddenly been deemed to be a problem?
Grahame Grieve (Aug 18 2021 at 05:32):
@Lloyd McKenzie
Jean Duteau (Aug 18 2021 at 05:33):
in this case, someone caused an old version of the template to be built and pushed to the last build. that then broke everybody
Grahame Grieve (Aug 18 2021 at 05:34):
btw, @Lloyd McKenzie,
Nothing should ever be in the CI build 'master' branch that hasn't been tested as much as it's going to be and is believed to work
Good luck with that. Since you can't test dependencies across the templates without committing to master. I think it's not as simple as you think
Grahame Grieve (Aug 18 2021 at 05:35):
so this is a template issue. And the templates are protected, and already listed in the code
Grahame Grieve (Aug 18 2021 at 05:47):
we already have a mapping from packageId to github repo for IGs. So there's no point in recreating that.
Grahame Grieve (Aug 18 2021 at 06:02):
so we can just have a simpler json file, that's way less maintenance: https://github.com/FHIR/ig-registry/blob/master/templates.json
Lloyd McKenzie (Aug 18 2021 at 13:10):
My original proposal was a file managed by the CI build process where first-in wins, and non-master/main branches are ignored. That would minimize maintenance. Josh was strongly not in favor of making any changes to the CI build process to do that though. A file maintained in Git was the "mutually tolerable" short-term solution.
Having someone's custom branch override the "current" version of an IG is problematic. Overriding the "current" version of a template which includes scripts is downright dangerous. The code, whatever it is (I couldn't see it) that's supposed to protect against the 'wrong' Git project taking control of 'current' templates did not function as someone somehow triggered an 'old' copy of the FHIR template and suddenly overrode what everyone using #current got. That's the problem we need to fix.
My preference is that we go with a "first in, wins" approach where the first Git repo associated with a package id is permanently associated with that package id and, if you want to move the association to a new repo, you need to ask Joshua or someone to handle that. Also, only commits to main or master are treated as #current, everything else is ignored.
Josh Mandel (Aug 18 2021 at 13:59):
(I'm not against automated rules -- just against implementing a new custom standalone system to manage them. These kinds of ownership rules should be pushed to a package server with API access; this is why npm package servers exist. Things like https://github.com/verdaccio/verdaccio or Simplifier. Npm supports authentication, association of packages with accounts, automated publication of releases, and tagging releases with things like latest or canary or stable in addition to giving them semantic versions.)
Lloyd McKenzie (Aug 18 2021 at 16:08):
We don't really want authentication. We'd like the process to be managed automatically from the CI-build process. A new author of a new IG shouldn't have to do anything than define their package id and set up a webhook.
Lloyd McKenzie (Aug 18 2021 at 16:08):
If we can make that work with a package server, that's great.
Josh Mandel (Aug 18 2021 at 16:25):
We don't really want authentication
We want to publish content in a given package only from an authentic source (i.e., ensuring the content is authentic). That's authentication.
Josh Mandel (Aug 18 2021 at 16:27):
A new author of a new IG shouldn't have to do anything than define their package id and set up a webhook.
I don't think we should be too fixated on the specifics of a webhook workflow. There are lots of options that might have a similar ease of use (e.g., configuring a GH Action, or connecting a FHIR Builder GH App, or whatever)
John Moehrke (Aug 18 2021 at 18:11):
it is quite easy to use that webhook on a personal github repo.
John Moehrke (Aug 18 2021 at 18:12):
I applaud the idea that anyone should be able to be first to claim a space.. and I am not against us mostly trusting the goodness of the community. But I do think we should be doing something a bit more controlled when it comes to templates.
John Moehrke (Aug 18 2021 at 18:13):
I think we need to separate templates from common IG.
Josh Mandel (Aug 18 2021 at 18:43):
John Moehrke: it is quite easy to use that webhook on a personal github repo.
For sure, any solutions we provide need to work in personal repos. (Better still, they'd work across hosting providers beyond github.)
Lloyd McKenzie (Aug 18 2021 at 18:58):
We want to establish a particular branch of a Git repository as the sole authorized source of the #current version. We don't want anything to do with user authentication, which is what I presumed 'authentication' meant. I don't think we should treat IGs and templates differently. Having the wrong content show up as the CI-build for US core could be almost as detrimental as having someone get the wrong template when building.
Josh Mandel (Aug 18 2021 at 19:16):
You can't enforce something like "establish a particular branch of a Git repository as the sole authorized source" without some authentication strategy.
Chris Moesel (Aug 18 2021 at 19:25):
I think the assumption is that once the relationship between repo and IG id is established, you're counting on GitHub authentication to ensure only the right people can write to the repo (the "sole authorized source"). So there is authentication, it's just in the source system, not the build/publication system.
Grahame Grieve (Aug 18 2021 at 19:36):
US Core is a good case in point, but this happened with other repos as well: they got moved. It's a feature that you can just move them
Lloyd McKenzie (Aug 18 2021 at 19:37):
We don't want them to be "just moved" without some confirmation that this is actually intentional. If you're going to move, we're going to need human intervention.
Lloyd McKenzie (Aug 18 2021 at 19:38):
@Josh Mandel - We can enforce something like that. It just might not fit into the existing repository's capabilities. It's very easy for us to say that the first repository with a main/master branch to use the CI build is the owner. And that's what we want. We don't want to deal with users or credientialling - because it could be anyone in the world creating any kind of IG and we don't care about who they are or what IG they're creating.
Grahame Grieve (Aug 18 2021 at 19:39):
If you're going to move, we're going to need human intervention.
Why? Apparently you see having to be involved in other people's workflow as a good thing, but other people won't
Lloyd McKenzie (Aug 18 2021 at 19:41):
Because someone cloning a repository and messing around shouldn't mess up US core. And right now, that can happen.
Gino Canessa (Aug 18 2021 at 19:44):
As a note, if there's any sort of registration step (e.g., register package 'xyz'), you can easily generate tokens for them. Adding a secret in GH that gets used in the webhook / action is not a high bar.
That would let people have full control over their parts (e.g., where it is hosted), but still allow 'authorization' to prevent someone else from hijacking the package. This is what many public services (npm, nuget, etc.) do.
As long as someone via HL7 has the ability to revoke/reset a package, this also allows for things like 'person A moved on and we can't get a hold of them'.
I think Josh's point is that these are all solved problems in package management. If we opt out of them, we will need to rebuild all of those pieces (over time) and end up managing all of that ourselves.
Lloyd McKenzie (Aug 18 2021 at 19:45):
There's no safe way to be able to tell that some new repository that has the same package id is a legitimate move vs. a clone by someone who didn't bother to change the package id. (Or even is maliciously trying to get people to see the wrong content - right now I could create a Git account under some temporary email account, clone US core, change the content completely, publish it using the CI build and that's the package everyone referencing uscore#current would get.)
Gino Canessa (Aug 18 2021 at 19:57):
I also wanted to chime in on the 'ci build' vs. 'release' discussion from earlier (re: #current) since I missed most of that in real time. All of the common packaging services I'm aware of support a notion of 'prerelease' now, via standard semver tagging. Using those services would mean consumers could opt into or out of 'stable' releases the same way they do in all their other projects. Resolution logic likewise moves from 'custom in our tooling' to the package management client.
It does add an extra step somewhere for someone on the production side. Most likely, whomever sets up CI builds needs to push them with a prerelease tag of some sort... but I believe that will just be a small addition to the initial infrastructure (e.g., when writing a GH action).
Overall, I feel like we have enough to be getting on with that we don't need to take responsibility for things that someone else has done. Yes, it may mean some additional work in the short term (e.g., updating our workflows), but in the long term it means that we don't have to write and maintain all the moving parts.
Josh Mandel (Aug 18 2021 at 20:00):
you're counting on GitHub authentication to ensure only the right people can write to the repo (the "sole authorized source").
For sure -- an authn strategy can depend on existing components, but it's important to do this properly to avoid https://en.wikipedia.org/wiki/Confused_deputy_problem. (The current CI build infrastructure manages this by a direct mapping between github repos and IG build directories -- because we build everything from scratch every time, taking sources from a single spot and copying output to a deterministic spot. That's one simple example of how to manage this, with some benefits and costs.)
Josh Mandel (Aug 18 2021 at 20:02):
There's no safe way to be able to tell that some new repository that has the same package id is a legitimate move vs. a clone by someone who didn't bother to change the package id.
Right. That's why you need to enforce invariants like "only authenticated users with authorization can cause a new package version to be published."
Grahame Grieve (Aug 18 2021 at 20:28):
I admit to not knowing how using a npm package server solves this problem. I can only imagine some workflow like this:
- Someone wants a new IG. They have to email someone (me?) to register it on the npm server
- whoever registers it, gives the person a secret
- They have to remember the secret somewhere.
- they put the secret in their github hook setup
- the build pushes the package to the npm server if the secret is correct
Josh Mandel (Aug 18 2021 at 20:32):
Yes but step one is open to anyone, I think. Unless we have reserved names/policies (analysis there isn't unique to npm publishing, it applies to any strategy)
Josh Mandel (Aug 18 2021 at 20:33):
And that means step 2 is automated.
Grahame Grieve (Aug 18 2021 at 20:33):
how can it be open to anyone?
Josh Mandel (Aug 18 2021 at 20:46):
That's how the public worldwide npm registry works. It implements a first come first serve registration process for arbitrary package names, and a restricted registration process for scoped package names like ®my-gh-user/project
Gino Canessa (Aug 18 2021 at 20:53):
For nuget, this article describes the workflow for publishing a package:
- create a user account
- generate an api key (can scope to a specific package)
- push packages with the api key
npm has the same process, though the official docs are bit more complicated (I don't see an 'official' short guide).
As Josh said, names are first-come-first-serve for registering, but the management org has the ability to revoke packages (e.g., if I register a phishing package with a misleading name).
Grahame Grieve (Aug 18 2021 at 21:02):
sigh. I expected this would be the case. There's a mismatch here, user vs package permissions
Josh Mandel (Aug 18 2021 at 21:06):
That's exactly right.
Gino Canessa (Aug 18 2021 at 21:07):
Yeah.. there needs to be something that can authorize writing a package. AFAIK, that's a generally accepted part of a package server. E.g., the NuGet Gallery Project, the GitHub Package Registry, etc.
Josh Mandel (Aug 18 2021 at 21:11):
At the end of the day, there's some policy specifying how to decide who can write to which packages, and some process to enforce the policy.
- Today the enforced policy is "anyone can write any package at any time
- In the future we might have policies based on who asked first; based on who controls a domain, or a GitHub org; based on who HL7 blesses, etc (and in combination)
Josh Mandel (Aug 18 2021 at 21:14):
You can't make that complexity go away. But sometimes you can outsource a chunk of it (I.e., to existing registry software, rather than recreating it).
Josh Mandel (Aug 18 2021 at 21:38):
Anyway, I didn't mean to be so dogmatic and absolutist on this thread. I'm sorry for that.
I most critically want to make sure we're considering the design space (understanding pros and cons of different solutions). That will help us make an informed decision, whatever we pick.
Lloyd McKenzie (Aug 19 2021 at 04:27):
Wanted to respond to the question on testing dependencies - actually it is possible to test dependencies locally - it requires a bit of work as you have to fuss with the dependencies of your local copies, but it's doable. Obviously, when we make changes to the base, we can't know about it breaking templates other than the ones HL7 controls though. However, from our perspective, that's still 'tested'. Seeing how the changes work with templates outside HL7's control is part of what releasing to #current is for. (Note: it's possible that as we start to have more formal governance over changes to the base template and to publisher function that changes might be tested on templates other than HL7's if/when we have volunteers who commit to doing that.)
Corey Spears (Aug 22 2021 at 00:07):
This conversation is incredibly interesting to me, but I have not been able to dig in to the details as many on this thread, so I wish I understood more of it. For most IG authors, I assume they just use the initiation capabilities of their favorite IG authoring tool or copy over from another IG. I doubt most know anything about the templates other than making sure they have the right one for their scope as defined here: http://build.fhir.org/ig/FHIR/ig-guidance/index.html
Is there some guidance regarding what #current means or how to use the latest official release. My expectation is most just want the latest acceptable tested version to get their IG out there.
Last updated: Apr 12 2022 at 19:14 UTC
