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,861 other subscribers

Archive for the ‘Source Code Management’ Category

« Previous Entries
Next Entries »

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 »

No GitHub: re-introducing an Inbox or Direct Messages is a bad idea!

Posted by jpluimers on 2021/08/18

Yesterday I published about Yet again, GitHub violates the Web Content Accessibility Guidelines by stealing a key: not it is the dot (.), and this week some feelers were put out for a kind of GitHub Inbox / Direct Message feature:

[Archive.is] GitHub Projects on Twitter: “What if there was 📨 DM/inbox feature on GitHub?”

There already is gitter.im (which is public instant messaging around GitHub repositories), and people have enough trouble managing all their incoming private message streams (be it paper/email inbox, social media and others), in large part because of SPAM and harassment messages.

It wasn’t by accident that the Private Messaging at GitHub feature was ditched almost a decade ago during [Wayback/Archive.is] 2012 Spring Cleaning | The GitHub Blog:

Private Messaging, however, was a step backwards: nobody wants another inbox. And a sub-par one, at that. Email is still the best way to contact someone.

Today we’re removing Private Messaging from GitHub. If you want people to contact you, please provide a public email address for your profile.

So I’m with all these:

Yes, I know [Archive.is] Tierney Cyren on Twitter: “A reminder that this account doesn’t actually represent GitHub nor any feature planning GitHub is doing… “, but I want to make absolutely clear to GitHub that another private message feature is a very bad idea.

–jeroen

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

Yet again, GitHub violates the Web Content Accessibility Guidelines by stealing a key: not it is the dot (.)

Posted by jpluimers on 2021/08/17

More sites seem to have a tendency of stealing keyboard shortcuts and violating the WCGA (Web Content Accessibility Guidelines), especially the (lowest!) conformance level A in [Wayback] WCAG version 2.1, section Success Criterion 2.1.4 Character Key Shortcuts

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

1. Turn off
A mechanism is available to turn the shortcut off;
2. Remap
A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
3. Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.

Mind you, I’m a keyboard person, there is even a: Keyboards and Keyboard Shortcuts category, but they always need to be configurable, anything else is a sin.

And GitHub did it again: [Archive.is] GitHub on Twitter: “🤫 New shortcut: Press . on any GitHub repo.… “.

So I’m totally with these:

Now they have started to steal the dot (.) keyboard to (in-place, with a fully new URL and no indication how to easily go back) start Visual Studio Code in the current repository.

Going back, though not documented, actually takes between one and three “back” movements in your web-browser history: utterly ridiculous for a key one can accidentally hit.

This behaviour violates all three above sub-criterions:

  1. it cannot be turned off
  2. there is no way to remap it
  3. it is almost always activated (unless there a text input – like “search” or “goto file” – has focus)

This is a very bad way to cope with accessibility, especially as conformance level A is yet again violated.

[Wayback] WCAG 2.1: section 5.2.1 Conformance Level:

One of the following levels of conformance is met in full.

  • For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided.
  • For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.
  • For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.

To me another cardinal sin is that they stole Ctrl-F / Command-F (depending if you use non-MacOS or MacOS) from the web browser. So now it does not find it in the full page, but only in the currently selected file. (You guessed it, I’m with [Archive.is] KewlCat on Twitter: “I hate it when they intercept “/” and even [Ctrl]-F… “ too)

More of those conformance violation sins are at [Wayback] Keyboard shortcuts – GitHub Docs.

It isn’t hard to prevent this kind of thinking: it’s a mind set as described by [Archive.is] Patrick Joannisse on Twitter: “I don’t know if you are expecting a real answer but here goes: it starts with the mindset. In my training they had us wear goggles to block our vision and made us use a screen reader for a while. We met people with disabilities and they would show us how they work.… “

If you still like it and want to know how it works

–jeroen

Read the rest of this entry »

Posted in accessibility (a11y), Development, GitHub, Keyboards and Keyboard Shortcuts, Power User, Software Development, Source Code Management | Leave a Comment »

Frank A. Krueger on Twitter: “I made a build status IoT thing! Automatically polls @bitrise and is even Alexa controlled (for brightness and to turn off). Now I want to add github issue and PR counts. Just a $12 ESP32 and a $30 led matrix.”

Posted by jpluimers on 2021/07/28

[WayBack] Frank A. Krueger on Twitter: “I made a build status IoT thing! Automatically polls @bitrise and is even Alexa controlled (for brightness and to turn off). Now I want to add github issue and PR counts. Just a $12 ESP32 and a $30 led matrix.”

[WayBack]

https://web.archive.org/web/20190822202203/https://video.twimg.com/ext_tw_video/1164251716927156224/pu/vid/1280×720/Pn_rAACnrcUHfXol.mp4

–jeroen

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

Fixing hg.exe “ImportError: DLL load failed: %1 is not a valid Win32 application.”

Posted by jpluimers on 2021/07/21

If you get the below error when running hg.exe, then you are mixing a 64-bit Mercurial with 32-bit dependencies:

C:\>hg --version
Traceback (most recent call last):
  File "hg", line 43, in 
  File "hgdemandimport\demandimportpy2.pyc", line 150, in __getattr__
  File "hgdemandimport\demandimportpy2.pyc", line 94, in _load
  File "hgdemandimport\demandimportpy2.pyc", line 43, in _hgextimport
  File "mercurial\dispatch.pyc", line 22, in 
  File "hgdemandimport\demandimportpy2.pyc", line 248, in _demandimport
  File "hgdemandimport\demandimportpy2.pyc", line 43, in _hgextimport
  File "mercurial\i18n.pyc", line 28, in 
  File "hgdemandimport\demandimportpy2.pyc", line 150, in __getattr__
  File "hgdemandimport\demandimportpy2.pyc", line 94, in _load
  File "hgdemandimport\demandimportpy2.pyc", line 43, in _hgextimport
  File "mercurial\encoding.pyc", line 24, in 
  File "mercurial\policy.pyc", line 101, in importmod
  File "mercurial\policy.pyc", line 63, in _importfrom
  File "hgdemandimport\demandimportpy2.pyc", line 164, in __doc__
  File "hgdemandimport\demandimportpy2.pyc", line 94, in _load
  File "hgdemandimport\demandimportpy2.pyc", line 43, in _hgextimport
  File "mercurial\cext\parsers.pyc", line 12, in 
  File "mercurial\cext\parsers.pyc", line 10, in __load
ImportError: DLL load failed: %1 is geen geldige Win32-toepassing.

The equivalent English error is [WayBack] “ImportError: DLL load failed: %1 is not a valid Win32 application.” – Google Search.

The problem is the bitness of hg.exe: [WayBack] python – Error while installing Mercurial on IIS7 64bit: “DLL Load Failed: %1 is not a valid Win32 application” – Stack Overflow

You can quickly figure out the bitness of hg.exe:

C:\>where hg
C:\Program Files\Mercurial\hg.exe

C:\>sigcheck "C:\Program Files\Mercurial\hg.exe"

Sigcheck v2.72 - File version and signature viewer
Copyright (C) 2004-2019 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\program files\mercurial\hg.exe:
        Verified:       Unsigned
        Link date:      17:49 9-7-2019
        Publisher:      n/a
        Company:        n/a
        Description:    Fast scalable distributed SCM (revision control, version control) system
        Product:        mercurial
        Prod version:   5.0.2
        File version:   5.0.2
        MachineType:    64-bit

Forcing x86 of Mercurial

Since I use chocolatey for most my installs, I forced x86 the Chocolatey way:

So after these:

choco uninstall --yes hg
choco install --yes --force86 hg

I got this signature check:

C:\>sigcheck "C:\Program Files (x86)\Mercurial\hg.exe"

Sigcheck v2.72 - File version and signature viewer
Copyright (C) 2004-2019 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\program files (x86)\mercurial\hg.exe:
        Verified:       Unsigned
        Link date:      17:50 9-7-2019
        Publisher:      n/a
        Company:        n/a
        Description:    Fast scalable distributed SCM (revision control, version control) system
        Product:        mercurial
        Prod version:   5.0.2
        File version:   5.0.2
        MachineType:    32-bit

–jeroen

Posted in Development, DVCS - Distributed Version Control, Encoding, Mercurial/Hg, Python, Scripting, Software Development, Source Code Management | Leave a Comment »

« Previous Entries
Next Entries »