GitLab on FreeBSD

[jmpalacios]

So, honestly, what benefit do you see for git(lab/ea/etc) v just plain git? I know your setup, I ran my own gitlab inst for <I forget> years (I'm sure I even have a few old shell scripts lying around to set up gitlab/ea myself--and they're probably far since broken as well).

Off the top of my head, and among others:

• A rather extensive and, above all, standardized language & tooling, that I don't have to create, evolve, nor maintain myself (other, of course, than the very low effort task of maintaining the GitLab infrastructure itself), for the creation of next to arbitrarily complex CI/CD pipelines.
• Automatic scheduling and execution of said CI/CD pipelines across any number of pipeline runners, with whatever custom environments I may want in each of them (e.g. PHP runners, Java runners, QA configurations vs. prod configurations, etc.).
• Automated deployments to any number of environments, according to those pipelines. And with properly written pipelines, you can also trigger manual pipelines and deployments at your discretion, without the need for spurious commits nor pushes.
• Handling of merge requests (yes, even if you're a solo developer, a merge request workflow can be beneficial).
• Gathering and comparison of automated test reports.
• Automated documentation of each individual release that any pipeline may create.
• Automated email notifications of various sorts, e.g. of pipeline jobs, test reports, deployments, etc.
• Vault integration (something I'm still in the process of exploring).

At $work, as most tech employers now'a'days, we use containers & Kubernetes, of course, which would add a great deal of entries to that list. But, being fair, I'm not going to count them here because my own operations are 100% FreeBSD & jails based.

But, in any case, and, again, not disparaging to any degree anyone's solutions to any operational problems and/or choices (and, least of all, hand-crafted command-line driven solutions, because oh have I enjoyed writing plenty of those throughout the years!), the sole point I tried to make in response to your comments is that, provided you have automation in place for your infrastructure, maintaining it is rather low effort, and the benefits to reap can be considerable. Even if only for the benefit a low bus factor: should I be run down by a bus within the next five minutes, it'd be rather easy for anyone with a modicum of technology savvy to look at my infrastructure and learn rather quickly how to maintain it.

 

[Espionage724]

*face-palm* ...Then why imply my solution(s) are not "up-to-par"? I'm a coder, I want to code. One day, I wanted to code up server-side VCS scripts. If you want to write playbooks or templates or whatever, what's that to me (I was only trying to point out to future readers of this thread, there are other--less dependency laden--options)?

Phrases (in seeming contradiction to 'my setup') like: "solid & well established" and "critical" are being used but I actually wonder if we may have different definitions (to me 'critical' and 'solid' mean things like: frictionless, deployable, (easily) auditable, (easy) maintenance, can be taken elsewhere, etc). But given the tones of responses, I doubt you'd even click a link or try an alternate so I should just assume you don't/will not understand the reasons for—the implications of—my setup and just move on.

I'd use my wiki for coding; it has diffs/revisions (never seen anyone maintain a project through a wiki though )

Someone pointed out that code boxes on DokuWiki can be directly-referenced in scripts, so theoretically it can be hooked up to CI or other build system stuff

 

[JohnK]

Espionage724 I can respect that. I even built a tool (different topic/subject) which respects that workflow. FYI: the wiki is a separate repo in gitlab. eg: /var/db/git/personal/project.git & /var/db/git/personal/project.wiki.git (if I remember right). And before anyone ask's '/var/db/' is where repos go (this is BSD). :]~

I've not heard that myself but I've done the code is the documentation thing and I'm not really a fan (if I understand the use case for that correctly). I like to document my code but I like to type my manpages myself.

there is a lot of koolaid in that post (I'm not/never been a "Linux system admin"), jmpalacios so, I'm not going to comment on that stuff. And, I was really just looking for information as to why someone may prefer to use a web-GUI. FWIW, my initial post was more of a general hypothetical and I certainly was not trying to "sell you anything" (you use whatever you want; I couldn't care less).

Merging / branch workflow aside because I'm not here to talk about version control workflows because everyone should figure out how they like to use the tools they want to use but the ability to merge / branch, and even CI/CD for the most part, has nothing to do with a GUI but I believe I get your train of thought (or enough to get an idea).

Yes, 'bus factor' is essentially about how many team members per se but the other factor (which I believe you may not be thinking about correctly) is how many remaining team members can "carry the water" so-to-speak after you've gone. Say for example, you get hit by a bus, how much time can pass before your <thing> stops working (because of ABI changes, a bug(s), ACME_XX++, dependency hits, etc.) and how many remaining team members can expand upon your work. IMHO, you should build your infrastructure so it will last long after you've gone with as little maintence as possible (-i.e., reduce complexity to build a legacy).

EG:
Deployments are a "sticky topic" but allow me to use it as an expansion of what I just said about the 'bus factor and reducing complexity' and make it a crude example/demonstration (it's a smaller--more digestible--topic than git workflows). Ansible has/is dependencies. I have Drist which uses tar(1) and ssh(1)--this isn't a sales pitch and you wouldn't click it if I did give it, so no link for you-. So, what that means for me is, Drist has essentially zero (0) dependencies which means nothing to break (-i.e., it's less likely the command flags for tar(1) are going to change vs Ansible, SOAP, REST, etc.) so it will work (for longer) as long as the host has ssh(1). I also chalk this up to the "BSD mindset" (aka: simple, rock solid, auditable [nothing to really go wrong] and battle tested). If you feel like Ansible or whatever is right for you, then use it but you also cannot fault me for using what I feel is important (you may want "flashy", I want "battle tested"). If I cary that back to 'Git'; my git server is "git + ssh + a few scripts (which use base system and git calls)" so there is nothing to install--besides git(-tiny).

I know you're going to say "Ansible is battle tested" but may we just assume: not as much as ssh(1) and tar(1) and not have that discussion.

 

[jmpalacios]

Espionage724 I can respect that. I even built a tool (different topic/subject) which respects that workflow. FYI: the wiki is a separate repo in gitlab. eg: /var/db/git/personal/project.git & /var/db/git/personal/project.wiki.git (if I remember right). And before anyone ask's '/var/db/' is where repos go (this is BSD). :]~

I've not heard that myself but I've done the code is the documentation thing and I'm not really a fan (if I understand the use case for that correctly). I like to document my code but I like to type my manpages myself.

there is a lot of koolaid in that post (I'm not/never been a "Linux system admin"), jmpalacios so, I'm not going to comment on that stuff. And, I was really just looking for information as to why someone may prefer to use a web-GUI. FWIW, my initial post was more of a general hypothetical and I certainly was not trying to "sell you anything" (you use whatever you want; I couldn't care less).

Merging / branch workflow aside because I'm not here to talk about version control workflows because everyone should figure out how they like to use the tools they want to use but the ability to merge / branch, and even CI/CD for the most part, has nothing to do with a GUI but I believe I get your train of thought (or enough to get an idea).

Yes, 'bus factor' is essentially about how many team members per se but the other factor (which I believe you may not be thinking about correctly) is how many remaining team members can "carry the water" so-to-speak after you've gone. Say for example, you get hit by a bus, how much time can pass before your <thing> stops working (because of ABI changes, a bug(s), ACME_XX++, dependency hits, etc.) and how many remaining team members can expand upon your work. IMHO, you should build your infrastructure so it will last long after you've gone with as little maintence as possible (-i.e., reduce complexity to build a legacy).

EG:
Deployments are a "sticky topic" but allow me to use it as an expansion of what I just said about the 'bus factor and reducing complexity' and make it a crude example/demonstration (it's a smaller--more digestible--topic than git workflows). Ansible has/is dependencies. I have Drist which uses tar(1) and ssh(1)--this isn't a sales pitch and you wouldn't click it if I did give it, so no link for you-. So, what that means for me is, Drist has essentially zero (0) dependencies which means nothing to break (-i.e., it's less likely the command flags for tar(1) are going to change vs Ansible, SOAP, REST, etc.) so it will work (for longer) as long as the host has ssh(1). I also chalk this up to the "BSD mindset" (aka: simple, rock solid, auditable [nothing to really go wrong] and battle tested). If you feel like Ansible or whatever is right for you, then use it but you also cannot fault me for using what I feel is important (you may want "flashy", I want "battle tested"). If I cary that back to 'Git'; my git server is "git + ssh + a few scripts (which use base system and git calls)" so there is nothing to install--besides git(-tiny).

I know you're going to say "Ansible is battle tested" but may we just assume: not as much as ssh(1) and tar(1) and not have that discussion.

JohnK I think this discussion is getting a little bit silly, with you appearing unnecessarily defensive in your positions when no one was attacking them at any point, just expressing our own, even if at times wildly differing, opinions on the subject. And, in mine right now, discussing from a position like that more-often-than-not ends up being a waste of time and a wasted opportunity for a healthy debate, one in which we all learn and draw positive lessons from everyone wanting to share experiences that might have taken them in one direction or another, and then accept, with openness, any applicable critiques to the choices they made (even if any of that sounds like some overly hippie wishful thinking… believe me, I have made *plenty* of mistakes myself, and it's not always been easy accepting them).

So it's not like I'm super inclined to continue the discussion as currently presented, but I did want to say one thing. No, you don't know what I think, what I'm going to say, nor what I'm going to do; speak for yourself, not for me. So much so that, actually, I did click on the link you originally shared, looked at your code, and came out thinking I wasn't, at least on a first pass, understanding much of what it was trying to do. And therein lies the sole point I've been making from the start, my *own* decision to use a toolset that is so much more universally recognizable and well understood, and therefore easily maintainable and extensible in a myriad of ways by plenty of people other than just myself, than anything I could have ever put together alone. Have tried it, plenty of times with widely varying requirements and challenges, always coming to the same conclusions. That which you call the "koolaid" that I drank has that value to me: low bus factor, extensibility, and portability, if you like, in exchange for a next to negligible price to pay for it (not to mention, like I already said, the fun I had putting the solution together), and at no point did I ever attempt to sell anything of what I was advocating for as superior to anything of what you said or advocated for. Different contexts, different requirements, different viewpoints and willingness to make specific tradeoffs, or not, and different resulting conclusions and solutions; plain and simple, no more no less.

In closing, if you feel I'm missing anything out in this response, my apologies, but it's precisely because it ain't like I'm finding this discussion particularly inviting nor entertaining. For me it's not a whole lotta fun reading arguments that are being presented unnecessarily defensively, much less to respond to specific questions I was asked to then be told I'm drinking koolaid. So, without any sarcasm, seriously, best of luck with your toolset and your rationale behind it, and all the best to you!

 

[JohnK]

My apologies: I must not have given the proper context (that’s not nice). The code is an example in a larger “wrapper type script for creating jails” but (the code you looked at makes very little sense to you because you probably don’t have the proper context--the readme would probably be of more value). However, here is an explanation of what the script does (you can do the following with any jail manger—my wrapper code does not matter in this instance):

1. Creates a jail (with a mount at /var/db/git)
2. Installs git-tiny
3. Creates a user called 'git' (actually it creates a subscript that creates a ‘git’ user which gets launched by a rc.d script—but I do this only to defer the user creation part of the script after the mount gets mounted in the jail).
4. Cleans out all unnecessary files but leaves .ssh

This would be a “very DUMB git server” so-to-speak so, if you now want, you create/upload a few helper scripts to /var/db/git for things like: init, view log, view repo, list repos, etc.. Those scripts (in that jail) are called from your laptop via ssh with the -t flag. The code/readme should make more sense now but the take-away is that I interact with my git server with the “alternates” in the readme. I created functions in my .zshrc to make calling them easier. Like: “gitinit”, “gitls”, etc.. So, I have a helper script for all the git operations I want or use now-a-days (currently for git and got). I had hoped the readme listed out basic versions of my scripts which one could modify and/or explained the situation but *shrug* (pointy-hat -> me).

The whole operation will probably make more sense now but no need to test/try but you don't have too. I just wanted to clear up my error/lack of background at least.

To save you from having to actually try anything...
"gitls" output looks like this:

NAME                                 DESCRIPTION                                          CLONE
md2mdoc                              markdown to mdoc program                             git@git.local:personal/md2mdoc.git     
barevcs                              (no description)                                     git@git.local:server/barevcs.git   
drist                                dumb remote installer shell tool                     git@git.local:server/drist.git     
jcreate                              Create FreeBSD jails with a config file.             git@git.local:server/jcreate.git   
sysconf                              Get/Set key/values in config files. sysc             git@git.local:server/sysconf.git   
fhints                               Create a hints file from C functions fou             git@git.local:vim/fhints.git
...

"gitinfo" returns text that looks like github/gitlab/gitea's repo landing page.
"gitinit" creates a bare repo and returns instructions for pushing/cloning.
...you get the idea.