The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,835 other subscribers

Archive for the ‘Source Code Management’ Category

« Previous Entries
Next Entries »

Don’t fall for the golden hammer: avoid git empty commits, especially for kicking off parts of your CI/CD

Posted by jpluimers on 2022/08/16

A while back Kristian Köhntopp (isotopp) wrote a blog post after quite a Twitter argument where he poses against using git empty commits. I’m with Kris: don’t use them for anything, especially not for kicking off your CI/CD.

Basically his blog post is all about avoiding to think you have a golden hammer, and avoid falling for the Law of the instrument – Wikipedia.

Originally, Abraham Maslow said in 1966:

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

For me this has all to do with preventing technical debt: find the right tool to kick your CI/CD pipeline after part of that chain somehow malfunctioned is way better than polluting the commit history with empty commits.

His blog post: [Wayback/Archive.is] Empty commits and other wrong tools for the job | Die wunderbare Welt von Isotopp

The most important bit in it:

And since we are talking about CI/CD pipelines: Don’t YAML them. Don’t JSON them. Don’t XML them.

…

Programming in any of these three is wrong use of tooling, and you should not do it.

  • YAML, JSON and XML are for declarative things.
  • Python, Go and Rust are for procedural things.
  • Bash is for interactive use only.

Use the proper tooling for the job. Be an engineer.

This very much reminds me of an Entwickler Konferenz keynote a long time ago, where Neal Ford made the point that most software engineers act very much unlike what is expected from traditional engineering way of operating where the engineer is both responsible and liable for his actions.

The start of the Twitter thread: [Archive.is] Kristian Köhntopp on Twitter: “A lot of people right now that git is an API and triggering CI/CD pipelines with empty commits replaces the equivalent of a Kubernetes controller for their fragile pile of bash in git triggers. This is broken and begets more brokenness. Evidence:… “

The tweet that started the subtweet: [Archive.is] Florian Haas on Twitter: “(For anyone wondering, what’s nice about this one is it works in any CI. So you don’t have to remember how to manually kick off a GitLab CI pipeline or GitHub Action or Zuul job, you just push an empty commit and off you go.)”

Other relevant tweets:

Yes, you want to avoid shell too (anything like for instance sh, ash, dash, bash or zsh), but you have to know it (and understand why to avoid it) as often it is the only interactive way to access systems from the console.

And of course Kris also wrote a big document on that too, which is available as full PDF (Wayback), full HTML (Wayback) and chaptered HTML Die UNIX Shell /bin/sh.

But more importantly, Kris wrote [Wayback/Archive.is] Using Python to bash | Die wunderbare Welt von Isotopp which is about using Python to do things you might be tempted to do in the shell. It quotes

Shell is a thing you want to understand and then not use, because you learned to understand it.

which is from the German post in thread [Wayback/Archive.is] Bashprogrammierung, wo gehts am besten los which quotes Kris’ 1998 message:

From kris Tue Sep 1 11:26:12 1998
From: kris
Newsgroups: de.comp.os.unix.misc
Subject: Re: Shell-Frage, find, xargs, kopieren von vielen Dateien
References: <6seh24$q9a$2...@nz12.rz.uni-karlsruhe.de>
From: kr...@koehntopp.de (Kristian Koehntopp)
Alignment: chaotic/neutral
X-Copyright: (C) Copyright 1987-1998 Kristian Koehntopp -- All rights
reserved.
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Marc.Hab...@gmx.de (Marc Haber) writes:
>mir ist das ganze Zeug mit der Shell, find, xargs und Konsorten noch
>reichlich verschlüsselt.

http://www.koehntopp.de/kris/artikel/unix/shellprogrammierung/

>xargs hin oder sollte ich besser ein Perlskript schreiben?

Verwende Perl. Shell will man koennen, dann aber nicht verwenden.

Kristian

–jeroen

Posted in *nix, *nix-tools, ash/dash, ash/dash development, bash, bash, Conference Topics, Conferences, Continuous Integration, Development, DVCS - Distributed Version Control, Event, git, Power User, Scripting, sh, Sh Shell, Software Development, Source Code Management, Technical Debt | Leave a Comment »

GitKon Sept 22 – 23, 2021 – Virtual Git Conference | Presented by GitKraken

Posted by jpluimers on 2022/07/12

GitKon was a cool virtual conference about git and the git ecosystem: [Wayback/Archive.is] GitKon Sept 22 – 23, 2021 – Virtual Git Conference | Presented by GitKraken

Navigation was a bit hard because of the visual overload on the site (look at the various Archive.is archivals), so here is the outlined list of sessions with the rough timestamps in the below live recordings:

Global sitemap:

Live recordings are below. Hopefully they will last and per session splits will have become available.

None of them are at listed at [Wayback/Archive.is] www.youtube.com/c/Gitkraken/videos.

Via: [Wayback/Archive.is] Attendee Registration Thank You – GitKon 2021

–jeroen

Day 1 live recordings

Day 2 live recordings

Posted in Development, DVCS - Distributed Version Control, git, Mobile Development, Software Development, Source Code Management, Web Development | Leave a Comment »

Moving an existing GitLab project into a new subgroup is called “Transferring”

Posted by jpluimers on 2022/06/14

Turns out the “slug” for a project… the part of the URL after the GitLab server domain name is made up of the “namespace” and the project name. The name space is the group/subgroup path, so I was

Via [Wayback] git – Moving an existing GitLab project into a new subgroup – Stack Overflow

Turns out the “slug” for a project… the part of the URL after the GitLab server domain name is made up of the “namespace” and the project name. The name space is the group/subgroup path, so I was looking to transfer project to new namespace.

Transferring the project to a different namespace means re-typing the project name during the transfer. You can do this using copy & paste.

The documentation is under [Wayback] Project settings: Transferring an existing project into another namespace | GitLab.

–jeroen

Posted in Development, DVCS - Distributed Version Control, git, GitLab, Source Code Management | Leave a Comment »

version control – Migrate from bitbucket to GitLab – Stack Overflow

Posted by jpluimers on 2022/05/24

For my link archive: [Wayback] version control – Migrate from bitbucket to GitLab – Stack Overflow

Documentation: [Wayback] Import your project from Bitbucket Cloud to GitLab | GitLab

–jeroen

Posted in BitBucket, Development, DVCS - Distributed Version Control, git, GitLab, Software Development, Source Code Management | Leave a Comment »

Setting up a GitLab project so it is served over https as a gitlab.io and a custom subdomain

Posted by jpluimers on 2022/05/05

Last week, I posted about Setting up a GitHub project so it is served over https as a custom github.io subdomain.

Today it’s the equivalent, but on GitLab.

Why GitLab? Two major reasons: unlike GitHub:

  1. it’s open source
  2. provides way more granular control over permissions
  3. allows a hierarchy of repositories on which you can specify that permission control

Already 2. and 3. combined are a huge advantage, though we will see that 3. also makes some of the subcases (hosting as user.gitlab.io from account gitlab.com/user where user is your username) is harder than the similar user.github.io, github.com/user combo.

So here we go, starting with a similar set of links:

The goal is to have

  1. page projects as or under wiert.gitlab.io (like wiert.gitlab.io/wiert)
  2. a gitlabstatus.wiert.me plain html (or maybe markdown) page project that eventually will show some status information (kind of like status.gitlab.com, but for different things).

The beauty of GitLab is that it supports hierarchies of repositories through groups and subgroups, so I already had these subgroups hoping they would cover both the first and second kind of page projects:

Steps I did

Since there are quite a few links above, here are the steps I took from my gitlab.com/wiert account and gitlab.com/wiert.me group.

Steps for wiert.gitlab.io/wiert

  1. For wiert.gitlab.io/wiert, try A (failed in part, and therefore interesting to understand why):
    1. Under leaf group gitlab.com/wiert.me/public/web/sites/gitlab.io, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert” (with slug “wiert“) so it would appear at gitlab.com/wiert.me/public/web/sites/gitlab.io/wiert
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Now I got in a confusing situation as the page indicated “There are currently no pipelines.”, but an enabled blue “Run pipeline” button:
      By default there is no CI/CD pipeline, but there is an enabled blue "Run pipeline" button: confusing.

      By default there is no CI/CD pipeline, but there is an enabled blue “Run pipeline” button: confusing.

    7. Clicked the “Run pipeline” button nonetheless, and that created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job and deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert/ and https://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert/
      Warning: When using Pages under the general domain of a GitLab instance (gitlab.io), you cannot use HTTPS with sub-subdomains.

      Warning: When using Pages under the general domain of a GitLab instance (gitlab.io), you cannot use HTTPS with sub-subdomains.

      The sites do work (see the [Archive.is http version] and [Archive.is https version]), but the HTTPS fails because wiert.me.gitlab.io does not match the SANs (Subject Alternative Names) in the certificate: *.gitlab.io, gitlab.io

  2. For wiert.gitlab.io/wiert, try B (failed, and therefore interesting to understand why):
    1. In my my groups gitlab.com/dashboard/groups, added a new group wiert
    2. Added subgroups until the leaf gitlab.com/wiert/public/web/sites/gitlab.io which as URL is gitlab.com/wier1/public/web/sites/gitlab.io because user account wiert already occupies gitlab.com/wiert.
    3. Under leaf group gitlab.com/wier1/public/web/sites/gitlab.io, created a new GitLab repository
    4. Chose “Create from template”
    5. Chose the template “Pages/Plain HTML”
    6. Named the project “wiert” (with slug “wiert“) so it would appear at gitlab.com/wiert.me/public/web/sites/gitlab.io/wiert
    7. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    8. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    9. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    10. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    11. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wier1.gitlab.io/public/web/sites/gitlab.io/wiert and https://wier1.gitlab.io/public/web/sites/gitlab.io/wiert.
      Bummer: again not the wiert.gitlab.io/wiert I hoped for
      The sites do work (see the [Archive.is http version] and [Archive.is https version]). The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

    12. If a user wiert exists and occupies gitlab.com/wiert, then a group named wiert cannot occupy gitlab.com/wiert, and therefore a project named wiert within that group won’t be deployed to wiert.gitlab.io/wiert.
      Maybe this can be shortened like “if there is a user wiert, then no group named wiert cannot be used to contain a project named wiert to host as wiert.gitlab.io/wiert“.
      Let’s find out!
  3. For  wiert.gitlab.io/wiert, try C (success, steps 1, 3, 4, 7 and 8 were the key ones):
    1. In my user gitlab.com/wiert, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert” (with slug “wiert“) so it would appear at gitlab.com/wiert
    5. The odd but cool thing is that the actual project now ended up at gitlab.com/wiert/wiert:
    6. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    7. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    8. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    9. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    10. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.gitlab.io/wiert/ and https://wiert.gitlab.io/wiert/.
      Success: finally the wiert.gitlab.io/wiert I hoped for:

      Success: published at https://wiert.gitlab.io/wiert/

      Success: published at https://wiert.gitlab.io/wiert/

      The sites do work fine (see the [Archive.is http version] and [Archive.is https version]). The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

Steps for wiert.gitlab.io

  1. For wiert.gitlab.io, try A (failed, and therefore interesting to understand why):
    1. Under leaf group gitlab.com/wiert.me/public/web/sites/gitlab.io, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert.gitlab.io” (with slug “wiert.gitlab.io“) so it would appear at gitlab.com/wiert.me/public/web/sites/gitlab.io/wiert.gitlab.io
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    7. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert.gitlab.io and https://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert.gitlab.io.
      Failure: not the wiert.gitlab.io I hoped for.

      The sites do work (see the [Archive.is http version] and [Archive.is https version]), but the HTTPS fails because wiert.me.gitlab.io does not match the SANs (Subject Alternative Names) in the certificate: *.gitlab.io, gitlab.io. The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

  2. For wiert.gitlab.io, try B (failed, and therefore interesting to understand why):
    1. Under leaf group gitlab.com/wier1/public/web/sites/gitlab.io, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert.gitlab.io” (with slug “wiert.gitlab.io“) so it would appear at gitlab.com/wier1/public/web/sites/gitlab.io/wiert.gitlab.io
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    7. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wier1.gitlab.io/public/web/sites/gitlab.io/wiert.gitlab.io and https://wier1.gitlab.io/public/web/sites/gitlab.io/wiert.
      Bummer: again not the wiert.gitlab.io I hoped for
      The sites do work (see the [Archive.is http version] and [Archive.is https version]). The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

    10. Try A and B were almost identical to wiert.gitlab.io/wiert try A and B, so let’s see if the solution C for that also works for us:
  3. For wiert.gitlab.io, try C (success, steps 1, 3, 4, 7 and 9 were the key ones)
    1. In my user gitlab.com/wiert, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert.gitlab.io” (with slug “wiert.gitlab.io“) so it would appear at gitlab.com/wiert/wiert.gitlab.io.
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    7. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.gitlab.io/ and https://wiert.gitlab.io/.
      Success: finally the wiert.gitlab.io I hoped for with working sites (see the [Archive.is http version] and [Archive.is https version]).
    10. Note the HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

Steps for gitlabstatus.wiert.me

Having learned from the GitHub githubstatus.wiert.me procedure (where I had to wait a long time for the default *.wiert.me domain mapping timeout and the githubstatus.wiert.me DNS CNAME record to become effective), I started on the DNS CNAME record side which is documented at [Wayback] Custom domains and SSL/TLS certificates: Section 3. Set up DNS records for Pages: For subdomains | GitLab:

Subdomains (subdomain.example.com) require:

  • A DNS CNAME record pointing your subdomain to the Pages server.
  • A DNS TXT record to verify your domain’s ownership.
From DNS Record To
subdomain.example.com CNAME namespace.gitlab.io
_gitlab-pages-verification-code.subdomain.example.com TXT gitlab-pages-verification-code=00112233445566778899aabbccddeeff

Note that, whether it’s a user or a project website, the CNAME should point to your Pages domain (namespace.gitlab.io), without any /project-name.

DNS CNAME record pointing to GitLab.com project

The value for the TXT record is only known after you created the pages project, but the value for the CNAME record is known beforehand:

From DNS Record To
gitlabstatus.wiert.me CNAME namespace.gitlab.io

So let’s see if I can do this in one try, with these steps:

  1. For gitlabstatus.wiert.me, try A (success, steps 1, 3, 4, 7 and 9 were the key ones)
    1. In my DNS settings of the wiert.me domain, created a CNAME record from gitlabstatus.wiert.me to namespace.gitlab.io:

      gitlabstatus.wiert.me CNAME record pointing to namespace.gitlab.io

      gitlabstatus.wiert.me CNAME record pointing to namespace.gitlab.io

    2. Under leaf group gitlab.com/wiert.me/public/web/sites/wiert.me, created a new GitLab repository
    3. Chose “Create from template”
    4. Chose the template “Pages/Plain HTML”
    5. Named the project “gitlabstatus.wiert.me” (with slug “gitlabstatus.wiert.me“) so it would appear at gitlab.com/wiert.me/public/web/sites/wiert.me/gitlabstatus.wiert.me
    6. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    7. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    8. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    9. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    10. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.me.gitlab.io/public/web/sites/wiert.me/gitlabstatus.wiert.me and https://wiert.me.gitlab.io/public/web/sites/wiert.me/gitlabstatus.wiert.me.
      Intermediate success: working sites (see the [Archive.is http version] and [Archive.is https version]).
    11. Now it is time to get the DNS CNAME record from gitlabstatus.wiert.me to namespace.gitlab.io into operation by clicking the “New Domain” button:
      "New Domain" button in the "Pages" settings.

      “New Domain” button in the “Pages” settings.

    12. There I filled in the correct gitlabstatus.wiert.me domain name, then pressed the “Create New Domain” button:

      New domain becomes gitlabstatus.wiert.me

      New domain becomes gitlabstatus.wiert.me

    13. Then a page appeared voiding the DNS CNAME work I already did: the documentation is clearly wrong as these are the two DNS record entries to be made as shown by gitlab.com/wiert.me/public/web/sites/wiert.me/gitlabstatus.wiert.me/pages/domains/gitlabstatus.wiert.me:
      Correct instructions for the DNS records to get gitlabstatus.wiert.me working

      Correct instructions for the DNS records to get gitlabstatus.wiert.me working

      Subdomains (gitlabstatus.wiert.me) require:

      • A DNS CNAME record pointing your subdomain to the Pages server.
      • A DNS TXT record to verify your domain’s ownership.
      From DNS Record To
      gitlabstatus.wiert.me CNAME wiert.me.gitlab.io.
      _gitlab-pages-verification-code.gitlabstatus.wiert.me TXT gitlab-pages-verification-code=c5619988d386b1a36c253ce05db55dbb

      Basically the whole namespace.gitlab.io part of the documentation is a placeholder for the actual namespace that belongs to the leaf group the pages project is in (in my case wiert.me).

      So this is the new DNS entry, for which I had to wait until the DNS TTL to time out and effectuate:
      New DNS gitlabstatus.wiert.me CNAME record pointing to wiert.me.gitlab.io

      New DNS gitlabstatus.wiert.me CNAME record pointing to wiert.me.gitlab.io

      Note that this DNS administrative interface from WordPress.com does omit the final period of the CNAME destination (officially this would be wiert.me.gitlab.io.)

    14. After the CNAME DNS record, I also made the TXT DNS record:
      New DNS TXT record for verification of gitlabstatus.wiert.me

      New DNS TXT record for verification of gitlabstatus.wiert.me

      Then I waited a little for the DNS TXT record to be saved and try the verification of the TXT record.

    15. Even then, verification took some time. I had to click the refresh button a few times before verification succeeded:
      The DNS TXT record for gitlabstatus.wiert.me finally got verified

      The DNS TXT record for gitlabstatus.wiert.me finally got verified

    16. Now I could press blue “Save Changes” button below and waited for the CNAME record DNS TTL to expire so I could check the domain and – hopefully – the TLS certificate to be requested by Let’s Encrypt:
      After the gitlabstatus.wiert DNS TXT record got verified, I could save the domain information

      After the gitlabstatus.wiert DNS TXT record got verified, I could save the domain information

    17. After the old CNAME record DNS TTL expired and the new CNAME record came into effect, the domain became available as http://gitlabstatus.wiert.me/:
      Waiting for gitlabstatus.wiert.me to become active

      Waiting for gitlabstatus.wiert.me to become active

    18. After verification, the “Domains (1)” bit changed from this:
      Domain gitlabstatus.wiert.me information before verification

      Domain gitlabstatus.wiert.me information before verification

      to this:

      Domain gitlabstatus.wiert.me information after verification

      Domain gitlabstatus.wiert.me information after verification

    19. In the mean time, also the TLS certificate got issued by Let’s Encrypt, so the final sites now both worked: http://gitlabstatus.wiert.me/ and https://gitlabstatus.wiert.me/.
    20. Success: finally the gitlabstatus.wiert.me I hoped for with working sites (see the [Archive.is http version] and [Archive.is https version] for the wiert.me domain, and [Archive.is http version] and [Archive.is https version] for the wiert.me domain).
    21. Note the HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

In retrospect, this could have been shorter when I had done the DNS part later, which is contrary to how to do this with GitHub.

Conclusion

The conclusion seems this:

Gitlab Page repositories to be published as or under wiert.gitlab.io need to reside directly under user wiert. Having them reside under a different group like wiert or wiert.me won’t work.

Or in more generic terms:

When creating pages as user.gitlab.io you have to put your pages projects directly under your user account gitlab.com/user.

Putting them under groups or leaf groups fails, no matter if the (leaf) group is named user or otherwise.

In addition, you can add custom domains to any Gitlab repository (even one that never stated out as a GitLab Pages repository). It will work as soon as the domain DNS mapping is setup through both a CNAME mapping record and TXT verification record.

The steps for this in your GitLab repository are:

  1. Ensure you have a valid .gitlab-ci.yml file at the root of your repository; I used the [Wayback/Archive.is] one from [Wayback/Archive] GitLab Pages examples / plain-html · GitLab as my site is purely static
  2. Ensure you have a valid index.html file in the public directory of your repository, similar to [Wayback/Archive] GitLab Pages examples / plain-html · GitLab
  3. When both 1. and 2. are committed in your repository at GitLab, then it will automatically be deployed to a docker container on gitlab.io, which allows the outside world to visit your GitHub Pages sie, and the Let’s Encrypt Certificate to be generated (and prevents this error: [Wayback/Archive] GitLab Pages integration with Let’s Encrypt | GitLab: “Something went wrong while obtaining the Let’s Encrypt certificate”).
  4. Under “Settings” -> “Pages”, add a new domain name to the repository: now it automatically becomes a GitLab Pages repository.
  5. When adding the domain, the settings page will show both a DNS CNAME record and DNS TXT record; ensure both are applied on your primary DNS name server and replicated to all authoritative DNS name servers.
  6. Save the new page.
  7. Check if the page is available on the new domain you added.
  8. Optionally under “Settings” -> “Pages” enable the “Force HTTPS (requires valid certificates)” option and save.

TLS information

Note: I saved the TLS information – including certificates here:

More about the Let’s Encrypt certificates at [Wayback] Chain of Trust – Let’s Encrypt:

–jeroen

Read the rest of this entry »

Posted in Cloud, Communications Development, Development, DNS, Encryption, GitLab, Hosting, HTML, HTTPS/TLS security, Infrastructure, Internet, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, Software Development, Source Code Management, TCP, TLS, Web Development | Leave a Comment »

Setting up a GitHub project so it is served over https as a github.io and a custom subdomain

Posted by jpluimers on 2022/04/27

Some links that helped me getting this working:

Read the rest of this entry »

Posted in Cloud, Cloudflare, Communications Development, Development, Encryption, GitHub, HTML, HTTP, HTTPS/TLS security, Infrastructure, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, Security, Software Development, Source Code Management, TCP, TLS, Web Development | Leave a Comment »

Git Explorer: a cool tool to visually learn git commands

Posted by jpluimers on 2022/03/03

This is sooooo cool: [Wayback] Git Explorer

GitExplorer: Find the right git commands you need without digging through the web

What I like is the simple clean UI with a two step selection of what git functionality you want to use followed by a simple usage and explanation.

Very well suites for both referencing and interactive learning.

Bonus: it is open source at [Wayback/Archive.is] summitech/gitexplorer: Find the right git commands without digging through the web..

Via: [Archive.is] Marko ⚡ Denic on Twitter: “You can find the right git commands without digging through the web. “

–jeroen

Posted in Development, DVCS - Distributed Version Control, git, GitHub, Software Development, Versioning | Leave a Comment »

File, extensions and directories to ignore in version control

Posted by jpluimers on 2022/02/17

I will try to keep this table up-to-date.

Note that in some tooling, names are case sensitive.

Name Category Tool Comment
Debug Directory
lib Directory
*.identcache Extension Delphi
*.local Extension Delphi
*bin Extension
*obj Extension
RECYCLER Directory Windows
Bin Directory
*.user Extension Visual Studio/Delphi
*.suo Extension Visual Studio
*.dcu Extension Delphi
__history Directory Delphi
ModelSupport_* File Delphi
*.rsm Extension Delphi
thumbs.db File Windows stored in each directory that contains thumbnails on Windows systems
thumbcache_256.db File Windows stored in each directory that contains thumbnails on Windows systems
*.bak Extension
*.~* Extension pattern Delphi
__recovery Directory Delphi
*.tvsconfig Extension Delphi
*.o Extension
*.lo Extension
*.la Extension
*.al Extension
.libs
*.so Extension
*.so.[0-9]* Extension pattern
*.a Extension
*.pyc Extension Python
*.pyo Extension Python
*.rej Extension Mercurial [WayBack] Rejected patches
*~
#*#
.#* Extension pattern
.*.swp Extension
.DS_Store File MacOS stores custom attributes of its containing folder
desktop.ini File Windows determines how a directory is displayed by Windows, such as the icon used by that directory
*.chw Extension HTML Help Compiled HTML Help general index

Based on at least these earlier blog posts, and a lot of fiddling around:

 

Hopefully, some day, I will find time to compare these against gitignore templates, for instance via:

and against [WayBack] svn – How do I configure the TortoiseSVN ‘Global ignore pattern’ properly? – Stack Overflow.

–jeroen

Posted in Development, Software Development, Source Code Management | 1 Comment »

Great git videos on YouTube by @shanselman (thanks @simongeering)

Posted by jpluimers on 2021/11/11

[Archive.is] simon geering on Twitter: “Thanks to @shanselman for creating these great Git Videos. As a senior dev starting to mentor/teach tech skills this is very helpful. What tool do you use for the green arrows and other overlays please? Git 101; GitHub PRs “:

Embedded videos below the fold.

–jeroen

Read the rest of this entry »

Posted in Development, DVCS - Distributed Version Control, git, GitHub, Software Development, Source Code Management | Leave a Comment »

@adamsand0r drew up a few sketches of design decisions needed to be taken when building a #gitops-based CD pipeline

Posted by jpluimers on 2021/11/10

Great decision diagrams: [Archive.is] Thread by @adamsand0r: good morning Twitter! I drew up a few sketches of design decisions needed to be taken when building a #gitops-based CD pipeline. let me know…

Via [Archive.is] Ian Miell on Twitter: “Oh man, these diagrams will make the hell of architecting GitOps pipelines easier to reason about… Thread 👇… “

[Archive.is] Ádám Sándor on Twitter: “good morning Twitter! I drew up a few sketches of design decisions needed to be taken when building a #gitops-based CD pipeline. let me know what do you think… #gitopsdecisions”

–jeroen

via

Posted in Development, DevOps, DVCS - Distributed Version Control, git, Source Code Management | Leave a Comment »

« Previous Entries
Next Entries »