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.
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!
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.
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
as source code and have no link for viewing the rendered version.
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.
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.
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.
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
code and some utilities
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,
, 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.
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!