Migrate to GitLab

[zaquestion]

GitLab has had an open issue for a while now desiring a "Lab CLI for GitLab", and we've made ourselves known. More recently we've started talking about officially making the move into GitLab's official namespace.

See: https://gitlab.com/gitlab-org/gitlab/-/issues/14448#note_399479784

This issue aims to capture the immediate todos to get lab fully re-homed functionally speaking. (no particular order)

• [ ] Replace Travis CI with GitLab CI
  • [ ] Update .goreleaser to upload artifacts as GitLab release artifacts
  • [x] Update homebrew tap home? Submit formula to homebrew core?
    • [x] https://github.com/zaquestion/homebrew-tap (probably going to want to update this going forward for a while, but should also setup a new one, or perhaps automation to homebrew-core
• [ ] Update install.sh to look for GitLab homed artifacts
• [ ] Host https://zaquestion.github.io/lab/ (./docs) in GitLab Pages
• [ ] Update tests (some rely on existing GOPATH)
  • [ ] Deal with https://gitlab.com/zaquestion/test
• [ ] Add existing collaborators to new repo
  • [ ] https://gitlab.com/zaquestion
  • [ ] https://gitlab.com/prarit
  • [ ] https://gitlab.com/rsteube
  • [ ] https://gitlab.com/claytonrcarter (if he's still interested?)
• [ ] Get 0.18.0 out (good forcing function for this stuff)

Longer Term

• [ ] @zaquestion: go through all open issues and organize, label, rank, etc
• [ ] Start a v1 branch so gitlabers and lab maintainers alike can start introducing new vision, rehauls, and other breaking changes (Starting with items in the 1.0 project)

[zaquestion]

@claytonrcarter @rsteube @prarit for visibility

(if there's any opposition to moving over nows the time to voice it ;)

[prarit]

I have a copy of lab on gitlab FWIW. https://gitlab.com/prarit/lab

I will nuke it if necessary to free up the namespace.

[rsteube]

Nah, makes sense as it will tend to more usage of it during development (EYODF). Keeping track will be a bit harder for me though as everything else is on github so far. Might want to get #151 done first so that it won't interfere with any work profiles. And i think the ci tests need to be updated to support parallel builds - i believe there was sth. regarding the test repo that might prevent that.

[zaquestion]

Welcome @mocha and @leipert -- they'll be aiding us on the GitLab side to get everything over. @leipert to post his thoughts on best approach. So far we've talked about getting the project imported and with a 1way mirror (github -> gitlab) to start, with the ultimate goal of reversing the direction or even severing the mirror.

[zaquestion]

Might want to get #151 done first so that it won't interfere with any work profiles

@rsteube Good point

There are some small things we can do (called out on the issue) to make this work nicer. I imagine many of us will have private instances and need to work with gitlab.com -- Long term I want to redo the config for 1.0 and support this sensibly

[rsteube]

Quick fix would be to just look at the origin remote domain of the current project (if any) to load configuration for that and fall back to the default otherwise.

[leipert]

I have had a look, (as you already have seen by MR) and wanted to leave a proposal for an updated plan on the move with added responsibilities.

• [ ] @leipert Initial Setup CI:

  I have added mirroring to: https://gitlab.com/gitlab-org/ecosystem-team/lab, this is just temporary until we have the CI running on GitLab: https://github.com/zaquestion/lab/pull/409

  Blocker (@zaquestion): The integration tests currently run against: https://gitlab.com/zaquestion/test and https://gitlab.com/lab-testing/ as described in the readme. Would it be possible to add me to the project and share the lab-testing account with me, otherwise I could fork / create a new test account for the tests.

• [ ] @leipert: One-off import of the Project to https://gitlab.com/gitlab-org/lab, this will import issues and pull requests. We then could close all open issues and pull requests on GitHub, and point to their "upstream equivalent" on GitLab.

  • [ ] @leipert Setup Push mirroring, so that updates are pushed from GitLab to GitHub.

  • [ ] @leipert Add existing collaborators to new repo (https://gitlab.com/zaquestion, https://gitlab.com/prarit, https://gitlab.com/rsteube, https://gitlab.com/claytonrcarter (if he's still interested?))

  • [ ] @leipert / @zaquestion Point towards the new repo.

• [ ] @leipert: Migrate .goreleaser.

  • [x] This probably means in the short term that we need access to:
  • https://github.com/zaquestion/scoop-bucket
  • https://github.com/zaquestion/homebrew-tap

• [ ] @leipert: Update install.sh to look for GitLab homed artifacts

• [ ] @leipert: Release 0.18.0

• [ ] @leipert: Port older releases over to GitLab?

• [ ] @leipert: Host https://zaquestion.github.io/lab/ (./docs) in GitLab Pages. I assume that we need to introduce some static site render for this, as GitHub Pages uses jekyll by default and GitLab pages nothing. So this can be done independently from the whole CI/release ordeal. Especially considering that in the meanwhile the GitHub pages will still be deployed.

---

Might want to get #151 done first so that it won't interfere with any work profiles

@rsteube Interesting, I think https://github.com/zaquestion/lab/issues/151 is a good idea to focus on, I wouldn't see it as an impediment though for the move, given that it "only" affects collaborators on lab . We might even have prior art by a GitLab employee (https://gitlab.com/jramsay/git-lab) for config management.

And i think the ci tests need to be updated to support parallel builds - i believe there was sth. regarding the test repo that might prevent that.

Seems like we can "artificially" limit concurrency in GitLab to one, with the help of Resource Groups. Thanks for the tip though, I will add it to the MR right away.

[zaquestion]

@leipert Plan looks good, a couple notes:

Initial Setup CI:

I've updated #409 so the tests are working now, I'm going to continue on to see if I can get some of the release functionality working too.

I've added you to the https://gitlab.com/zaquestion/test repo and to the homebrew-tab & scoop-bucket repos. Happy to share the lab-testing user creds as well, just need a better way to send them. thoughts?

Port older releases over to GitLab?

The import should handle this, I can see the releases made it over in this import already: https://gitlab.com/gitlab-org/ecosystem-team/lab/-/releases

[zaquestion]

@leipert @mocha Reminder that lab currently uses the CC0 license: https://github.com/zaquestion/lab/blob/master/LICENSE

Any friction there?

[rsteube]

Any progress on this? Can see some work for gitlab-ci on gitlab.com but seems the jobs still fail.

[zaquestion]

Need to fix the tests on GitLab, which all broke when the config changes happened I believe, but https://github.com/zaquestion/lab/pull/455 should be enough for us to make the cutover once that's done. We'll probably need to poke @leipert on the actual GitLab issue, since I think over here is probably less visible for them https://gitlab.com/gitlab-org/gitlab/-/issues/14448

[Atralb]

What about now ? Is the migration still planned as before ?

[zaquestion]

@Atralb I need to reengage the folks at GitLab, to get this actually moving again, which I'm planning to do in the new year. That said, I'm planning to sort out the 0.18.0 release without migrating and hoping to have that out next week.

[leipert]

Hey folks! Sorry for the long time with no movement. I was on a long leave until just before the holidays (👶 🥳). Let's pick this up in the new year. I will figure out what stuff that we need from you @zaquestion, I think some access to some projects was missing, but otherwise we should be good to go 😄

[prarit]

Hey @leipert , I think @zaquestion was planning on releasing 0.18 this week. @zaquestion ,what do you think of creating a 0.19 release that only had this issue in it? ie) all 0.19 would be is the move to GitLab? I know in some ways it would be a throwaway release but I think that being able to point to a specific release would be good for future debugging and testing.

[davinkevin]

FYI, I would love to see a new version released, especially to fix some bugs.

But, for information, I've tried to built master for macOS, and the application crash at when displaying a pipeline… I have the "screen" but then it doesn't respond and have to be killed with a pkill command.

So, it could be cool to check this is working in other OS before doing a release because it can be worse for some case.

BTW, if you need help to migrate to GitLab, as a GitLab Hero, I can help if you want, 👍.

[zaquestion]

Released 0.18.0, which doesn't change anything for this effort other than the first GitLab release being a higher version number.

[davinkevin]

Installed and working, 👍

[prarit]

@leipert -- any update here? Just curious if you've made any progress. I'd really like for this issue to be the focus of the next release.

[alerque]

It looks like GitLab has chosen to go with glab instead. Does that mean this project won't be moving? Or will move to GitLab hosting but not as the official upstream CLI?

[rsteube]

Makes sense going for glab. Haven't been working with gitlab for quite a while, but when i did i was favoring it myself as well. Github did well on the structure of their cli and it was a good choice to adopt that. I think the question rather arises if work isn't better spent there in the future.

[alerque]

I like glab too and have favored it when possible, but lab still does a couple things for me that are not yet supported. Actually it looks like current development might cover the features I need they just aren't in a release yet.

In any event as a distro packager I was just looking around for what the future of this project was looking like. I got a lot of millage out of it myself and thank the contributors. Going forward it would probably be nice to have a plan—either migrate and continue development or call it unmaintained or something.

[zaquestion]

Hi folks, thanks for the kind words it means a lot. GitLab didn't communicate anything with me about it, but I would make the same guess as above, they wanted to adopt glab to have a similar experience to how gh. I was in communication with the glab dev at the time, and he was favorable to having GitLab adopt both tools, we've been friendly from the get go. I guess that's the way it goes.

I'm very proud of this project, and while I wish that we had been allowed to live alongside glab, the decision seems to have been made. I would still be happy to migrate the project should that ever come up again. For now I'm going to close this issue. Checking recent development i seems @prarit is continuing to maintain this repo, and when possibly I'll be around as well. I'm not at a GitLab shop myself, but this tool would still be my first stop should I find myself in one :) .

[zaquestion]

Oh one final note, this tool lives on in glab as the pipeline view over there is ported from here :)