⭐ NOTICE: EHR Repositories moving to GitLab


(Terry Hill) #61

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?

(Tony McCormick) #62


New Group - https://gitlab.com/librehealth/ehr

  • Owners: Tony, Art, Terry
  • Developers: We can add others when they are granted commit privileges.

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.

(Terry Hill) #63

So this will go away with time>

(Terry Hill) #64

How are we going to merge these ? Will they need to be deleted and re done?

(Terry Hill) #65

I think there is a problem… Every one on the repo with the triangle gives this error . and there are a lot of them.

(Tony McCormick) #66

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.

(Tony McCormick) #67

I wonder if we could write a script that would migrate the user environment? Or is that too Linux centric?

(Michael Downey) #68

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:

  • PhpStorm plugin for GitLab for those of you using that IDE
  • Mobile apps for iOS/Android if you want to stay up on issues/merge requests/etc. on the go
  • PHP-GitLab-API if you want to hack on some personal productivity scripts/tools/etc.
  • Quite a few good looking CLI clients for those of you who enjoy that

Check 'em out and share any recommendations here back with the group!

(Tony McCormick) #69

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.

(Michael Downey) #70

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?=

(Tony McCormick) #71

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.

(Tony McCormick) #72

@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 …

(Tony McCormick) #73

This is interesting …

Use Service Desk to connect with your users (e.g. to offer customer support) through email right inside GitLab

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

(Robby O'Connor) #74

I’ve seen Service Desk – I haven’t used it personally – contemplating it for ITSM tickets

(Robby O'Connor) #75

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.

(Tony McCormick) #76

So here’s the plan as I see it.

  1. We close all the now broken PR - Done and Labeled as “NEEDS MIGRATION” so we can find them
  2. I post a list we created that has the GITHUB versions of these, with links and we use that as work list with the owners.
  3. We add a note with instructions, here and on EACH PR so that the owner gets a notice.
  4. Owner migrates to gitlab and pushes a new PR with a link to the closed and tagged PR
  5. We use the list as a check-off to make sure everything we want get

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…

(Tony McCormick) #77

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

(Robby O'Connor) #78

If you need anything from me – I’m around.

(Tony McCormick) #79

Branch List … in need of porting to GitLab by the owners…

GitHub-PRs.pdf (35.2 KB)

(Tigpezeghe Rodrige Kwenchu) #80

@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)