Githost going away. Choose GitLab.com, Framagit, or self-host?

git
ops
#1

In initially discussing GitLab.com vs git.snowdrift.coop I thought there were jut pros and cons but we could live with just our one instance. However, it turns out that we currently use GitLab Pages for our design prototyping process, and git.snowdrift.coop cannot use Pages, we have a repo at framagit.org/snowdrift.

UPDATE: GitHost is going away in a year anyway, so that option is out.

To consolidate and for the future, we have these options:

  • [probably not this] self-host GitLab CE, take responsibility for all sysadmin stuff and hosting costs, but we get GitLab Pages and could eventually figure out single sign-on within our ecosystem
    • [unlikely] find another free GitLab hosting service that would do everything we have now but work with GitLab Pages
  • move to GitLab.com and accept that it’s EE (proprietary edition), and while people may have accounts and can use GitHub and other options, no SSO with our system, and less full control over our setup
  • move everything to Framagit’s instance, relying on them, not sure what trade-offs

On the last option, we want to develop more partnership and communication with Framasoft anyway. They are one of the primary software-freedom organizations out there whose work we’d love to include at Snowdrift.coop. Are there many downsides the moving to Framagit entirely? Maybe we should open communication with them first?

Thoughts?

more on how we use GitLab Pages

The core issue relates to working out this workflow:

  • Designers do their user-stories, wireframes, mockups
  • Prototypers build HTML/Sass stuff per that repo linked above and can see it live and share it publicly with the designers and others
  • There should be a code review of the protoype HTML/Sass before it is handed off to haskellers to implement on the live Snowdrift.coop site in Hamlet etc.
  • Then, a code review of the final work before merging and deploying

This process itself needs to be finalized and documented, but we’re almost through a first iteration of this for new design stuff.

GitLab.com vs git.snowdrift.coop
#2

@wolftune Would it be possible to have SSO between the main site and Framagit?:old_key:

Also, what does GitLab Pages provide, that the team uses, that we can’t get from hosting the prototype repo on Snowdrift’s server, at a different url than the main site? I know you mentioned “workflow”, but did not name any GitLab-specific features.

#3

If that were possible, it would, I suspect, also be possible to do that with our own git.snowdrift.coop instance, but we haven’t explored that fully yet.

I don’t actually know, it’s a good question. The work of setting up a URL (a subdomain perhaps) to hold the prototype might be less work than moving our repos around.

I’m not sure what they are. Does GitLab Pages offer the ability to rapidly see the pages from the state of various git commits or branches? Does it make it easier in this or other ways for any contributor to see and publicly share their work?

I guess we need clarity here to determine what to do.

#4

@wolftune Good point.

That would be easier than hosting to localhost on one’s computer, for seeing old/branch versions, and pushing local changes.

#5

To be clear, I don’t know if GitLab Pages does this, I hope someone can clarify soon. I suppose @iko likely knows…

#6

A hosted service like GitLab Pages simplifies access management. No need to set up hooks to an existing Snowdrift web server, or manage server credentials for people to upload changes. Theoretically the pages can also be generated on the GitLab server (via a GitLab CI runner compiling Hakyll) without having to install the static site generator locally, though I didn’t test it as a Hakyll binary was sufficiently portable.

As far as I know it does not handle snapshot previews of commits. However, it is possible to specify different branches for different deployment environments, e.g. push changes from other branches to staging and only the master branch for the production server.

It is easier for contributors to see and publicly share work — they can give other devs their fork’s preview link to discuss roughs, collaborate on the original and show its link to people from other domains. It is helpful for potential contributors who don’t have a remote dev server or don’t want to port forward behind a home firewall.

#7

Well, we have no choice to stay with our current service long-term. GitHost.io (GitLab’s service we currently use) is being discontinued June 1st, 2019.

So, no rush, but assuming we’re still using GitLab, still pushing forward (hopefully all launched) well before then, it won’t be a good investment to get more and more stuff set up in our current state unless we want to (and can) move the entire instance to self-hosted. We might want that, but if instead we move to GitLab.com or framagit, we may as well just figure out which one and make plans to move whenever we have time.

#8

What costs would be involved with the different options?

#9

In this case, both options mentioned (GitLab.com vs framagit), neither involve financial costs directly. GitLab is gratis to all public projects and framagit is gratis for fully-FLO projects. The software is GitLab in both cases, but proprietary edition at GitLab.com and fully-FLO at framagit. I haven’t explored if otherwise there are any advantages in terms of features or capacity for us one way or the other or any other questions.

#10

I’m inclined towards gitlab.com right now. It’s a lower barrier to contribution, as many people already have accounts (myself included). Obviously fully-FLO is ideal, and if we were a larger project I’d say it’s fine to ask people to create an account just for us, but at this stage I think we should prioritize ease of contribution.

Later, when we have the bandwidth to add sso, we can move to hosting our own. Or not, it’s a little premature to be planning that far out, anyway.

#11

+1 to gitlab.com. I’m in favor of not dealing with crap like:

image

#12

@chreekat in case you missed the later parts of the thread, GitHost is going away entirely, and we probably don’t want to self-host (despite the principle of it). So, between Framagit vs Gitlab.com, either way we don’t deal with that crap… (I’m going to change topic title anyway)

#13

Is there no way of integrating the git and snowdrift.coop accounts? I absolutely love that community.snowdrift.coop and snowdrift.coop us the same global account.

Or am I going to answer my own question in that the ratio of how much work that would be required and the size of our project doesn’t support self-hosting at this time?
:yum:

#14

There’s a chance that collaborating with Framagit could result in them adding a “sign in with Snowdrift.coop” feature that we could ever support, although we really really do not want to become some broad sign-in-with tool and all that liability…

#15

It’s possible but:

  1. Is effort to implement that’s probably better spent on other things.
  2. Is effort to maintain (ex: monitoring to prevent spam).
#16

Maybe we want the ends-justify-the-means case of using GitLab.com in order to actually get the EE functions. As much as we dislike that they are proprietary, they are substantially useful to us. Examples:

  • multiple issue boards per repo
  • marking epics, roadmaps
  • multiple assignees for issues
  • issue weighting
  • marking related issues
  • more…

The fact is, we simply have a rougher, more costly, more painful project management experience without some of these tools, even though we can make it work. Using them locks us in somewhat more, but there’s still the ability to export issues. Can they then be imported, i.e.g can we escape the EE version and move back to CE (or a fork of it) at a future time as a fallback? If not, I suspect GitLab folks will be receptive to requests for such fallback guarantees as they have been pretty sensitive and responsive to software-freedom requests, short of actually freeing their proprietary features fully…

All in all, I’m leaning pretty strongly toward GitLab.com at this point. I welcome push-back if anyone opposes this direction.

P.S. With more people moving to GitLab since Microsoft’s acquiring of GitHub, it potentially means that many more potential contributors will just already have GitLab.com accounts…

#17

Some blockers we’d like fixed before we moving to GitLab.com:

#18

Don’t know if you’re aware of it, but Web Architects run a GitLab CE instance aimed at co-ops: https://git.coop/

It could be a reasonable compromise between self-hosting and GitLab.com ?

edit: may not be suitable given the join-the-coop requirements for getting an account.

#19

As a co-op, we are dedicated to working with and supporting other co-ops, so the idea is appropriate enough. But I doubt we’ll actually decide to go for that for various reasons.

Incidentally, we were aware, and git.coop is listed at https://wiki.snowdrift.coop/market-research/flo-repos#flo-source-hosting

(Is it actually the case that all volunteers would need to join the co-op just to have accounts? That would be a no-go for us, and we should perhaps clarify that in the wiki page too for others’ reference)

#20

Issues with Gitlab EE notwithstanding, I still think we should make the move.

I would like to start planning for this. Are there any objections?

Snowdrift GitLab should clearly identify itself in email as being distinct from GitLab.com