Issues

Integrating GitLab into AxAp will require various issues to be addressed. Some of these have to do with "rough spots" in GitLab's offerings. Others result from places where its design goals do not match our specific needs. This page, in any event, is a sketchy first cut at a summary.

Accessibility

Unlike AxAp, GitLab has no strong emphasis on accessibility. So, it's inevitable that we will discover assorted issues. As we do, we'll need to characterize, report, and (possibly) help to resolve them. This section will contain summary information and links; submissions welcome!

Documentation

Although GitLab has quite a lot of documentation, it isn't always easy to find the relevant page. Neither the existing index pages nor the search engine meet our needs very well. Fortunately, creating an index is much easier than creating the documentation itself. See the Resources page for our start on producing a reasonably comprehensive index, organized as a topical hierarchy.

Markdown files (e.g., README.md) are automagically rendered into HTML. However, if the window is too narrow for the intended layout, content disappears from the page:

  • information on the last commit: hash key, message, ...
  • a row of buttons: Open raw, Blame, History, ...

Contrariwise, files such as markdown.md.erb are presented as source code and have no link for viewing the rendered version.

Usage Modes

GitLab can be used in either a local or remote mode. Local mode should be more flexible and performant; remote mode is a lot easier to try out.

Local

GitLab's "Golden Path" involves installing and running a local copy. We are currently recommending use of a certified Docker container for this (even when the host system is running a compatible version of Linux). Aside from ensuring that all dependencies are in order, this approach fits in well with AxAp's long-term architectural plans.

That said, installing a local copy of GitLab isn't as easy as it might be. Although Rich has installed Docker Toolbox on his 2008 Mac Pro (it can't run Docker), he has not yet been able to get a copy of GitLab running on it. So, setting up a local installation of Docker may not be appropriate for all users.

Remote

Although GitLab provides a cloud-based server, most users are expected to access the server via the command-line (e.g., Git), run a local copy of the GitLab client, etc. To the extent that the user is relying on these sorts of approaches, many server-related issues (e.g., Performance) will be less relevant.

Performance

GitLab's online performance can be quite sluggish, often taking a few seconds to respond. If the user runs a local copy of the GitLab software, this isn't much of an issue. However, it would also be nice to have a good user experience for prospects to try out. Finally, if the online performance issues affect the GitLab servers that the clients use, even local performance could be affected.

Fortunately, many performance issues are amenable to tuning. The GitLab code is based on the Ruby on Rails web framework, augmented by assorted Ruby and Go code and some utilities (e.g., Nginx, PostgreSQL, Redis). To the extent that the web server code is running in Ruby, it seems reasonable to find and replace the slowest parts.

Our preference, FWIW, would be for someone to rewrite the front end completely, using Phoenix, Elixir, et al. This would dramatically improve both the system's efficiency, responsiveness, and robustness. It would also help with upcoming issues such as distribution, long-running connections, etc.

Workflow

GitLab supports and strongly promotes a workflow based on continuous integration: Idea, Issue, Plan, Code, Commit, Test, Review, Staging, Production, Feedback. We haven't had a chance to try this out in practice, but it seems quite reasonable. Presumably, GitLab applications and Git's own tooling can handle any corner cases.

This workflow could be very useful as a way to organize a community of AxAp developers. So, it is very attractive, in terms of AxAp's long term goals. However, it's not clear that the typical AxAp user will have much interest in getting involved with continuous integration, etc. So, we may need to find or develop a simpler option for these users.


This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r13 - 26 Apr 2017, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email