just a side note RGSoC runs on github
https://github.com/rails-girls-summer-of-code/rgsoc-teams looked at their read.me
Not sure what they are doing with this, another set of eyes is needed. Will it matter that their code is looking to git hub for issues, prs etc?
@all
New Group - https://gitlab.com/librehealth/ehr
Notice the extra level in the git path … gives us subgroup control
GITHUB issues are locked. Please use GitLab. If we need to unlock (and unhide them) we still can easily.
Please use GitLab going forward for all WRITE operations.
The github will be a readonly mirror so other operations that pull branches and stuff should still function.
@tony, @downey and @r0bby will help research solutions to any issues you have and we will start working on automatic stuff for our sites (which they tell me is easier in GitLab)
Thank you for helping us out on this migration.
I think there is a problem… Every one on the repo with the triangle gives this error . and there are a lot of them.
This is what I think this issue is, which I did not expect but should have.
Working Theory, untested.
The people that do not have branches / PRs directly on our master (like we do) need to migrate their branches to GitLab as well. Just like when they first created their Github accounts. They need to FORK the gitlab EHR Base (repo) to their GitLab account and then update the URL for ‘origin’ on any clones and push their branches to their gitlab. That probably means the the pull requests need to be re-requested.
Do you guys (@aethelwulffe and @teryhill) have time this morning to do a ZOOM meeting and see if we can work out a process? I think I need to talk it out to get something that will work.
I wonder if we could write a script that would migrate the user environment? Or is that too Linux centric?
FYI for those new to GitLab:
@tony and I were chatting yesterday about various tools availble for use with GitLab. Turns out GL has a curated list of recommendations:
From this page, of particular note for some of you may be:
Check 'em out and share any recommendations here back with the group!
In that same note, I like this view of the project… https://gitlab.com/librehealth/ehr/lh-ehr/branches
Makes it easy to do cleanup work.
Also @tony you’ll probably be interested in checking out the issue boards feature which I think can roll-up across multiple projects in the same sub-group, example at https://gitlab.com/groups/librehealth/ehr/-/boards?= …
Here’s something I like: You can automatically keep your fork master and protected branches (like the release branches) up to date in your Gitlab account.
@r0bby and I have a workable plan for migrating the unfinished PRs. It does require the submitter to migrate, but I’ll write good instructions and we will be creating “to do” list of the migrations needed. Anything that falls thru the cracks (like the submitter no longer available) I will pull into the main repo as needed.
All NEW work should happen in gitlab and be fine… Standby for more details …
This is interesting …
Have your users email incoming+librehealth/ehr/lh-ehr@gitlab.com
Those emails automatically become issues (with the comments becoming the email conversation) listed here. Read more
I’ve seen Service Desk – I haven’t used it personally – contemplating it for ITSM tickets
To update here for others – I closed the Merge Requests and labeled them with “NEEDS MIGRATION”
The ones across all EHR repos can be found here.
So here’s the plan as I see it.
Anything that doesn’t get handled by the owner I migrate as a branch of interest into the main repo.
Sound OK, guys @aethelwulffe @teryhill
I need someone like @Trodrige to test the migration instructions, or even help write them as I don’t have that kind of user account or outstanding pull requests to test against…
Note: this process does not apply to the committers (Tony/Art/Terry), we have it easier as our stuff is already on the gitlab master/branches
If you need anything from me – I’m around.
@tony I have succeeded in opening a MR in GitLab. The unmerged work was re-pushed and re-requested for review and Merging.
I wrote these down. Check the instructions, then we can share it with the other EHR folks to follow. GitHub to GitLab Migration Instructions For LibreHealth EHR repositories.pdf (425.2 KB)
