Stream: committers/git-help
Topic: Re streamlining the process for commiters
Eric Haas (Oct 23 2018 at 21:23):
I streamlined my process for committing down to:
( working in my local master branch)
- git pull
- [make changes]
- git add .
- git commit
- git push origin master:[new branch]
(switching from the command line to GitHub)
- click on the PR button
- wait and see....
Notice I don't do a local build unless I have to - like a dreaded did not close the spreadsheet error- and this is same as doing it locally when getting errors. I'd rather use the cloud to do the builds since it frees up my local system and is much faster. But is there a way to view the published output when the PR is successful? That would be handy to see if I made any typos or formatting errors before I merge it into the CI build.
Ewout Kramer (Oct 26 2018 at 11:45):
Notice I don't do a local build unless I have to - like a dreaded did not close the spreadsheet error- and this is same as doing it locally when getting errors. I'd rather use the cloud to do the builds since it frees up my local system and is much faster.
I think that makes total sense you avoid to things:
- Your machine will not be slowed done by the build
- You can start working on another issue, without having to wait.
I discussed with Grahame that he could do the same - he found himself in a situation where he wanted to go on working on another branch - so he needed multiple copies of the repo on his machine. That can get pretty confusing.
Grahame Grieve (Oct 26 2018 at 13:02):
So the way git does branching means that it's really quite hard to interlace your work. That problem does not resolve, you just learn not to try ;-(
Eric Haas (Oct 27 2018 at 13:35):
When the PR succeeds , does the cloud build publish and if so is there a way to see it? That is my missing piece?
Lloyd McKenzie (Oct 27 2018 at 14:56):
It should sho up in #committers/notification under "FHIR build status"
Eric Haas (Oct 27 2018 at 17:04):
Ok but I’m naving from github. The success details link doesn’t have a preview build link just logs as far as I can see
Grahame Grieve (Oct 27 2018 at 17:11):
right I don't think it does
Eric Haas (Oct 27 2018 at 21:08):
Could it?
Grahame Grieve (Oct 27 2018 at 21:12):
it could. It would be a bit slower and it would also consume inordinate amounts of space somewhere
Grahame Grieve (Oct 27 2018 at 21:12):
1GB+ per build...
Eric Haas (Oct 28 2018 at 22:09):
Well I think it would be handy... can those files be temporary -24 hr lifetime and or an option when doing a pr?
Grahame Grieve (Oct 29 2018 at 06:09):
@Josh Mandel this would be in your camp....
Josh Mandel (Oct 29 2018 at 12:44):
Making this work would be pretty straightforward by extending the infrastructure we have today. We discussed it in Baltimore and decided to hold off -- but I'd happy to help set this up if we want it. I'd probably delete all hosted branch content after a few days (or a week, or month, or some fixed lifetime independent of how long the branch was around, to bound space and discourage long-term reliance).
Lloyd McKenzie (Oct 29 2018 at 16:37):
I think 1 week after last commit is reasonable. That's long enough for people to review a proposed change. And someone can always keep it alive by doing another commit.
John Moehrke (Oct 29 2018 at 16:40):
sure would prefer that to trying to get the build to work on my local machine... UGG
Lloyd McKenzie (Oct 29 2018 at 16:44):
You'll have to run the build to at least the schema generation step regardless.
John Moehrke (Oct 29 2018 at 16:47):
a brand new clone, with no changes, and it won't build. (See committers stream)
Lloyd McKenzie (Oct 29 2018 at 16:55):
I know. I'm running the build on my system to see if I get the same issue.
John Moehrke (Oct 29 2018 at 16:58):
I am suspecting it is the new jekyll requirement that I missed, and don't see in the core build instructions
Lloyd McKenzie (Oct 29 2018 at 17:00):
Just added it
Josh Mandel (Oct 29 2018 at 21:16):
I have a version of this feature ready to test @Eric Haas . Each time your pull request builds that should appear at http://build.fhir.org/branches/
Josh Mandel (Oct 29 2018 at 21:17):
Er, once I merged my branch
Josh Mandel (Oct 29 2018 at 21:18):
Okay. Yeah so starting in about half an hour :-)
Josh Mandel (Oct 29 2018 at 22:14):
Seems to be working. E.g., @Grahame Grieve http://build.fhir.org/branches/remove_usersession/resourcelist.html shows the usersession resource gone from the remove_usersession branch.
Grahame Grieve (Oct 30 2018 at 00:51):
thanks
Eric Haas (Oct 30 2018 at 02:53):
yes ty!
Josh Mandel (Oct 30 2018 at 02:54):
Sure thing. current rules will expire each published Branch 3 days after creation, or as soon as the branch is deleted from GitHub if that happens first.
Josh Mandel (Oct 30 2018 at 02:54):
Let me know how it goes.
Lloyd McKenzie (Oct 30 2018 at 02:55):
Speaking of, there are quite a few undeleted server-side branches kicking around. Is there a way to check which branches have been merged?
Josh Mandel (Oct 30 2018 at 02:58):
https://github.com/HL7/fhir/branches/active is pretty close to what you're asking about.
Lloyd McKenzie (Oct 30 2018 at 03:00):
Is there any reason to not go along and click on all the trash cans that are red?
Josh Mandel (Oct 30 2018 at 03:01):
Deleting merged branches is fine.
Lloyd McKenzie (Oct 30 2018 at 03:02):
Well, aside from it being a slight pain that it was necessary at all, at least that bit was easy :) All gone...
John Moehrke (Oct 30 2018 at 12:21):
I noticed the note after merge that the branch could be deleted.... since it was not part of the instructions for using GIT, I didn't do anything... should we be deleting the branches? Or is there some re-use function to a branch?
Josh Mandel (Oct 30 2018 at 16:09):
I'd be happy to update the instructions to say "delete the feature branch after you merge." Any concerns with this @Lloyd McKenzie ?
Lloyd McKenzie (Oct 30 2018 at 16:39):
Nope
Last updated: Apr 12 2022 at 19:14 UTC
