Stream: committers/git-help
Topic: DocumentRef/Media stuck
John Moehrke (Jun 04 2019 at 16:38):
I have submitted changes to the branch to get it to re-build.. but it doesn't seem to be moving. Please help https://github.com/HL7/fhir/pull/561
Eric Haas (Jun 04 2019 at 17:10):
John is getting conflicts as well.... status-codes.xml and compartmets.xml would not read from excel so I had to go in and remove some attributes in the xml to fix them. nevertheless even if I revert to the head and try to edit them I get a conflict. I will try a commit to just touch these files and see what happens
John Moehrke (Jun 04 2019 at 17:25):
I didn't know what to do about that... is that what is stalling my build?
John Moehrke (Jun 04 2019 at 17:26):
and what is the conflict? I click on resolve conflicts and never get a web page to appear.
Josh Mandel (Jun 04 2019 at 17:28):
Resolving conflicts on spreadsheets is hard! @Grahame Grieve , is there a way to tell whether a given spreadsheet (as pushed to a git branch) has been properly canonicalized first?
John Moehrke (Jun 04 2019 at 17:28):
I assumed these were conflicts with master... I expect that master has passed my branch by, as my branch is a temp branch
John Moehrke (Jun 04 2019 at 17:29):
I expected to resolve these conflicts later when the branch intent is approved... and expected I would just manually re-apply the same changes I made to the new master.
John Moehrke (Jun 04 2019 at 17:29):
but are these conflicts different than that? Are they causing other branches failures?
John Moehrke (Jun 04 2019 at 17:33):
hmmm, so Grahame did fixup something in the DocumentReference spreadsheet he commented as "fix for may problems related to missing code checks..." https://github.com/HL7/fhir/commit/fc3c6cadaa37e3406afa114a0e31509e78d7ba51
do I need to merge these changes into my branch now?
John Moehrke (Jun 04 2019 at 17:34):
I guess the new build is doing some new checks?
John Moehrke (Jun 04 2019 at 17:36):
seems similar change to ClinicalImpressions was also done 4 days ago
John Moehrke (Jun 04 2019 at 17:42):
the other two have also been changed..... Surprising that there is only 4 conflicts given that my branch touches 37 files... SO, do I need to manually integrate these changes into my branch? I would guess that I need to pull all other changes into my branch too to get it as close to master?
Eric Haas (Jun 04 2019 at 17:46):
resolving spreadsheet conflicts is easy but tedious (if the source spreadsheet is readable). you just start over and re-edit it. but yes its never pretty and that is why its so important to close the spreadsheet before commiting.
John Moehrke (Jun 04 2019 at 17:47):
my problem caused by different reasons... by the long-term branch
John Moehrke (Jun 04 2019 at 17:47):
I can do the manual merge.. just don't know if that is what I should do
John Moehrke (Jun 04 2019 at 17:48):
Ill wait for AU morning
Eric Haas (Jun 04 2019 at 20:38):
here is the error for the status file
Error: The spreadsheet /home/ubuntu/agents/01/_work/2/s/source/status-codes.xml was committed after editing in excel, but before the build could run *after Excel was closed*
[java] org.hl7.fhir.exceptions.FHIRException: The spreadsheet /home/ubuntu/agents/01/_work/2/s/source/status-codes.xml was committed after editing in excel, but before the build could run *after Excel was closed*
I tried this on a mac and pc and saved and closed the file prior to commit. So I don't know what is going on...
Grahame Grieve (Jun 05 2019 at 09:50):
I'm in London right now! There is a real conflict here. The github conflict editor fails on large files; the only way to resolve this is to follow the (confusing but correct) git hub command lines instructions
John Moehrke (Jun 05 2019 at 12:45):
@Grahame Grieve for my long-term branch, do I need to integrate the changes that have happened on master since I branched?
Josh Mandel (Jun 05 2019 at 12:46):
It's generally a good practice, to make sure you haven't gotten too far out of sync
John Moehrke (Jun 05 2019 at 12:48):
I figured I would need to do it eventually, before merging the branch... I was just hoping to hold off the pain given that my integration of the changes likely will not be seen by GIT as a proper versioned merge... I don't like this long-term branch idea, but was forced by committee process.
John Moehrke (Jun 05 2019 at 12:49):
I simply do not understand what GIT is complaining about. See pull request https://github.com/HL7/fhir/pull/561
John Moehrke (Jun 05 2019 at 16:39):
I can see the conflicts with the provided "web editor". I would prefer to keep all my changes and thus just keep what I submitted. However when I use the "web editor" to resolve the conflicts, it leaves me ONLY with the choice to "Merge". I don't want to merge the branch into master... do they mean this level merge? Or do they mean merge the edits I did in the "web editor" to the four files to be merged into the branch?
Josh Mandel (Jun 05 2019 at 16:52):
It sounds like there's an issue where the build detects that a source file has not been canonicalized:
[java] Error: The spreadsheet /home/ubuntu/agents/01/_work/2/s/source/status-codes.xml was committed after editing in excel, but before the build could run after Excel was closed
Even though @Eric Haas indicates he did close Excel and run the build before committing. @Grahame Grieve can you clarify whether there is a known issue here, or if this looks like a new bug or user error?
John Moehrke (Jun 06 2019 at 00:19):
Please GIT community help.... I would be glad to resolve these four conflicts, but I must NOT merge my branch into master. This seems to be the only solution I am given. I want my branch to be built into a temporary build...
Josh Mandel (Jun 06 2019 at 01:14):
I'm think what you want to do is merge master into your branch.
Josh Mandel (Jun 06 2019 at 01:14):
On the command line, that's "git checkout mybranch; git merge master"
Josh Mandel (Jun 06 2019 at 01:15):
Then resolve conflicts, then "git add" the resolved files.
Eric Haas (Jun 06 2019 at 01:57):
OK I am trying this now ....
Eric Haas (Jun 06 2019 at 01:59):
OK the build is being pickier than snot ....
Eric Haas (Jun 06 2019 at 03:08):
Yes thats the ticket...
I looks like once you get a conflict on a spreadsheet you can't undo it with a subsequent local build because I did the following:
- open spreadsheet
- close spreadsheet
- skip local build
- commit/push
- build conflict :-(
- build locally
- recommit/push
- build conflict still there :-(
Eric Haas (Jun 06 2019 at 03:09):
ty Josh
Eric Haas (Jun 06 2019 at 03:12):
(I am prone to avoiding local builds since its such a resource hog. I have to switch computers...)
Grahame Grieve (Jun 06 2019 at 05:20):
Error: The spreadsheet /home/ubuntu/agents/01/_work/2/s/source/status-codes.xml was committed after editing in excel, but before the build could run after Excel was closed
I normalise the spreadsheet to remove non-serious differences in the excel spreadsheet as much as possible. The intent is that the only differences will be deliberately introduced differences, but Excel does like to throw new things my way occasionally.
But I can't normalise the excel spreadsheet if Excel has it locked for editing. People can commit while excel has it opened, and therefore get 1000s of spurious differences. The CI-Build refuses to build with spreadsheets like that, to make sure something like that never gets into the master.
I'd rather have us stop using excel altogether now, but the editors are fiercely resisting that
Lloyd McKenzie (Jun 06 2019 at 12:44):
Are you normalizing for IGs now? If so, that's great - though why not indicate a failure if the spreadsheet was open?
John Moehrke (Jun 06 2019 at 13:42):
I can confirm Eric's test... I edited these four locally, did a clean, did a build, and then checked them into my branch... Still a conflict. I don't know how to make git happy. I am afraid of every instruction ends with what looks to my non-GIT expert as a forced merge of my branch with master. I don't understand how I can make git happy with my branch still existing only as a branch. Sorry to be so thick, but this is why I am asking the git-help stream for help
John Moehrke (Jun 06 2019 at 13:45):
On the command line, that's "git checkout mybranch; git merge master"
This seems most understandable to me... can someone tell me how to do this with tortoise? Im not going to like doing this, but know I need to do it at-least once before this branch eventually gets into master. So I guess catching it up now is as good of a time as any
John Moehrke (Jun 06 2019 at 13:48):
specifically... the directionality of this merge with master is the scary part for me. merge master into my branch, seems like what I need to do next... but it looks very similar to merge my branch into master, which I need to avoid until the 4 workgroups involved approve this media/docRef change.
Eric Haas (Jun 06 2019 at 13:57):
Josh s solution works like a charm. I know it sounds counterintuitive but using the cli is the way to go here.
Eric Haas (Jun 06 2019 at 13:59):
You are merging the master into the branch but that doesn’t mess up your committed changes. I don’t know why but checkout dies a lot of magic things
Eric Haas (Jun 06 2019 at 14:15):
@GG. For single sheet workbooks I think we should use a different format. I hate the status-codes.xml. It messes me up every time. I’d say cab but I am pretty sure Excel would mess that up too. I live by spreadsheets so I am torn. Is there a way the commit or push can fail or remind you to do a local build first if an excel file was opened. (Move the error upstream). Because that would prevent folks (like me) from skipping a local build. Or is there a way to make the build not use up all the local machine’s resources so it’s less painful to run.
Eric Haas (Jun 06 2019 at 14:16):
csv. Not cab.
Grahame Grieve (Jun 06 2019 at 16:13):
I can't fail the commit. Or I would.
Grahame Grieve (Jun 06 2019 at 16:13):
why is status-codes.xml such a problem?
Eric Haas (Jun 06 2019 at 17:25):
I always forget about and it doesn't show until the full build an hour later
Josh Mandel (Jun 06 2019 at 23:37):
I can't fail the commit. Or I would.
Could define a git hook to do this check and fail.
John Moehrke (Jun 07 2019 at 13:07):
I have completely recreated my branch from current master. And it builds, and I submitted the pull request, and that succeeded... BUT, I can't find the temporary publication to share with those wanting to review this. I would have expected it at http://build.fhir.org/branches/moehrke-docRef/ given past method of where these pull-request builds go. but it is not there... I do find an error in the "Publish" step
mv: cannot stat '/home/fhir_upload/uploading/www/branches/moehrke-docRef': No such file or directory
Remove deleted branch: moehrke-docRef
Is this a problem on the servers?
John Moehrke (Jun 07 2019 at 13:08):
i.e. https://dev.azure.com/fhir-build/build.fhir.org/_build/results?buildId=2032&view=logs
John Moehrke (Jun 07 2019 at 14:03):
@Josh Mandel @Grahame Grieve please help. I fear I am one step forward, but still two steps behind
Josh Mandel (Jun 07 2019 at 14:56):
Thanks for the pointer + @mention @John Moehrke -- let me see.
Josh Mandel (Jun 07 2019 at 14:58):
mv: cannot stat '/home/fhir_upload/uploading/www/branches/moehrke-docRef': No such file or directory
Is actually okay -- it's just saying "this branch didn't exist already on the CI server". But
Remove deleted branch: moehrke-docRef
Is the culprit: it's saying: we don't think this branch exists on github anymore, so we're deleting it from the CI build now. Obviously that shouldn't be happening.
John Moehrke (Jun 07 2019 at 14:59):
oh good... love to be an example of random()
Josh Mandel (Jun 07 2019 at 15:00):
No, this is good stuff -- it's happening because our branch count now exceeds the github API limit for a single results page, so
curl -s https://api.github.com/repos/HL7/fhir/branches | jq '.[].name
is no longer a reliable full list. I didn't know this API was paginated until now ;-)
Josh Mandel (Jun 07 2019 at 15:01):
Let me put the quick fix into effect...
Josh Mandel (Jun 07 2019 at 15:05):
This'll take a sec to re-launch the CI server -- it'll go offline for 1-3min
Josh Mandel (Jun 07 2019 at 15:06):
So I'm deploying https://github.com/FHIR/auto-ig-builder/commit/860a6d83ad8d7ce69b0c629575832471522d7043 -- basically, changing the logic from "delete a branch preview from CI whenever it's 2 days old or it's deleted from GH" to "delete a branch preview from CI whenever it's 3 weeks old".
Josh Mandel (Jun 07 2019 at 15:07):
(back up)
Josh Mandel (Jun 07 2019 at 15:07):
Now @John Moehrke let me re-trigger your last build...
Josh Mandel (Jun 07 2019 at 15:08):
OK, rebuilding now; should get a notification in #committers/notification when your branch re-builds and then it should be visible at http://build.fhir.org/branches/moehrke-docRef/
John Moehrke (Jun 07 2019 at 15:30):
thanks
John Moehrke (Jun 07 2019 at 15:36):
Yeah! I see the publication http://build.fhir.org/branches/moehrke-docRef/
Last updated: Apr 12 2022 at 19:14 UTC
