Git.io Deprecation

[tajmone]

@thoni56, a few months back I discovered that the Git.io URL shortening service for "GitHub Posh URLs" was being discontinued, and that all links would stop redirecting in May 2022.

So I had planned to replace all occurrences of the shortened links to the ALAN-Docs website:

• https://git.io/alan-docs

with the full GH Pages URL:

• https://alan-if.github.io/alan-docs/

in all our repositories, Wiki pages, etc.

Today, as I began to work on this I realized that the Git.io short URLs are still working even though we're well behind the service announced expiration date. So I looked it up and found out that it seems that GitHub ultimately decided to opt for an extended "read-only" grace period of the service, in order not to break existing links:

2022-04-27 Update:
While the git.io url redirection service is read-only and use of the service is limited, we have received feedback from developers and academic researchers who have published git.io links in print documentation and research papers.
In order to preserve the integrity of these historical documents, we have decided to archive the current git.io links in a new read-only service that will allow us to serve redirects for those links longer term.

Now, it's not clear how long this grace period will last — i.e. whether it's for good, to preserve existing links in the WWW and search engines, or just to allow developers enough time to replace their short URLs.

I'm not sure what to do regarding our projects: should we play it safe and replace all Git.io URLs with the full URL, or just keep using the shortened URL (easier to remember) as long as the read-only service still works?

Both solutions have pros and cons, so I'm not sure which way to go.

[thoni56]

From the information you have gathered, I feel that there is no rush, but we should probably do it fairly soon, not to get caught with our pants down ;-)

Since the full links work, we could do it anytime. Actually, the longer to shorted URL:s are available to more peoples, and possibly websites, will have picked up on them.

Personally I think that the only "problem" with the longer links are that I haven't found out how to auto-redirect https://alanif.github.io to https://alanif.github.io/alan-docs. Which is what we want since that is the hub for all the documentation, right?

Probably there is something you need to do from the organization page, but I have not dug deeper into it.

On a slightly related note, it would be nice to get the "continuous integration" builds/actions going for the beta and alpha documents. Not that we create document version that often so it's a burdon to do it manually. Rather the opposite, at least I tend to forget how to do it...

For Cgreen I managed to add a GitHub action that published the documentation straight of the master branch. I know we have some specialised tool-chains for the Alan documentation, but I thought I should at least mention it, maybe it's possible to extend that action.

[tajmone]

I feel that there is no rush, but we should probably do it fairly soon, not to get caught with our pants down ;-) [...] the longer to shorted URL:s are available to more peoples, and possibly websites, will have picked up on them.

Yes, my worry in procrastinating was exactly that, the proliferation of shortened URL and its search engines indexing (although I believe search engines are "smart" enough to see that these links always redirect to another one).

Personally I think that the only "problem" with the longer links are that I haven't found out how to auto-redirect https://alanif.github.io to https://alanif.github.io/alan-docs. Which is what we want since that is the hub for all the documentation, right?

AFAIK, this can't be done with GitHub, since each repository has its own websites, plus the special website for the user or organization, but they adopt a strict naming convention.

What you can do with GitHub Page is to have your custom domains point to the repository GH Pages website, but you have to purchase the domain privately.

Probably there is something you need to do from the organization page, but I have not dug deeper into it.

I haven't heard of the possibility of redirecting the org website to a specific repository, but then it's also true that GitHub is always coming up with more new features than I can keep up with. So I'll dig into it, just in case.

The only special feature for user accounts that I'm aware of is the possibility of creating a specially named markdown doc in a repository having the same name as the user ID, so that this markdown doc is then shown in the user landing page as a sort of "custom banner", but this only works with user accounts, not organizations — I remember that we tried it for ALAN but didn't work: alan-if/alan-if#1

CI Alpha/Beta Builds

On a slightly related note, it would be nice to get the "continuous integration" builds/actions going for the beta and alpha documents. Not that we create document version that often so it's a burdon to do it manually. Rather the opposite, at least I tend to forget how to do it...

For Cgreen I managed to add a GitHub action that published the documentation straight of the master branch. I know we have some specialised tool-chains for the Alan documentation, but I thought I should at least mention it, maybe it's possible to extend that action.

Yes, this has been on our TODOs list for quite some while.

I'm not really in favour of GitHub Actions though, for various reasons (ranging from their monthly limits up to the Node.js requirement) but mostly because:

1. They make a repository service/hosting specific (not portable to other hosts like GitLab, etc.).
2. GH Action only work online, not locally.

The second point is the most important, for we would like to be able to manually execute those build locally in some occasions, and I'd rather keep a single script/solution for both online and local builds.

I think the best solution would be to use Ruby and just add them as optional tasks in our Rake toolchain, so they can be run both locally and on online CI servers. Ruby is more flexible than Bash scripts, and having a unified toolchain would be better. Ruby's standard library natively incorporates functions that mimic the most common shell commands, so we won't be reinventing the wheel in this case.

I also believe that there are tons of similar Rake scripts to pick from in the wild, because of Ruby on Rails' popularity.