Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Finger always has been a bit of an issue. And especially with things like kubernetes (on which OpenTTD now runs), it is really difficult to do. I have been wondering about how to solve this.
For now, I think the easiest is to have a "finger" per release type. You can use this file for that:
It will always show the latest release available; it is in CSV format, with
The "branches" and "tags" on finger are completely superseded by GitHub. GitHub allows to fetch this information via their API, and is much more likely to be future-proof. So I would suggest we remove those completely from finger.
Not all downloads are migrated to the new CDN yet, which makes a good solution for finger a bit more difficult. But it was more important to get the new nightlies available than it was to get everything perfect. If there are suggestions what a better replacement for finger is, I would love to hear it. Is an URL like above sufficient? Or should we publish every nightly on GitHub? Or tag every nightly?
Feel free to leave any ideas!
Also, not less important, the URL to download binaries from has changed between the old system and new (from https://binaries.openttd.org to https://proxy.binaries.openttd.org). This URL might change again in the future. Not sure how to handle this cleanly. I think that is not really possible.
Biggest hurdle is that the ingame client uses https://binaries.openttd.org for ingame content, and it is unlikely we can deprecate that any time soon (because BaNaNaS is being rewritten, which tights into this). Or I have to find a way to automatically update the CDN with content of BaNaNaS.
Many possibilities, but most of all, tons of annoying issues :D
Either way, still thinking we should stop using "finger" in the current form, and go with the "listing.txt" per release type.
Still looking for additional input!
Ok, I don't mind so much when the download URL and the place to get version info changes. That's about a one-time update to scripts and fine.
listing.txt as given by you lists the revisions... but what URL could I give a script to get the URL from?
Navigate to https://www.openttd.org, hit the
That is the URL where you can find the source, for example!
If you want the direct URL on the webpage:
But I am guessing you want the download URL more than anything else.
Not sure why you are trying the 20190118 version; that is rather old :D
Hope it helps!
With the addition of releasees, it turns out that
Please let me know if you are scripting things with this, and see other possibilities :)
Hi, I reported the issue here and also suggested the implementation of meta tags.
The https://openttd.ams3.digitaloceanspaces.com/openttd-releases/listing.txt does not include stable releases, is this intentional? Where can we get info about latest stable release? Also, implementing a single XML file would be more clean than this multiple TXT files method...
Also, what's with the bizarre "openttd.ams3.digitaloceanspaces.com" URL? Where does it come from and how can we ensure this URL won't change in the near future? I think it would be more reliable to request them from the http://www.openttd.org server directly... Thanks.
Let me see if I get all the questions here ... (forgive me if I miss any).
Please create a new issue about 'meta tags', or even better, a Pull Request ;) I have yet to look into it, what the best practices are, etc. Tnx!
I will see what I can do about the URL itself. Currently it just points to the CDN, but as it doesn't support IPv6, having it wrapped in some openttd.org URL might be nice. You could use proxy.binaries.openttd.org, but those files are cached for at least a day on the edge. That is not ideal for these kind of files. So we will have to cook up some other solution. I will put that on my todo. Good suggestion.
Currently these URLs only list what has been published on the new infrastructure. So it is not listing any stable, as there are no stables on the new infrastructure. Currently, a combination of 'finger' and these URLs are needed for the complete overview (as where the files are located also differ between those two). Soon that will be fixed if we release our first stable (and finger can be deprecated completely). Or I might manually migrate an older stable to the new infrastructure. (depends a bit on the timeline for the next stable, I guess).
We won't be publishing any XML files anymore. XML is a very unfriendly format, both for machine and human. I considered YAML briefly for the
We won't be publishing a single file anymore with everything in there. Currently how 'finger' works is unmaintainable, especially as we want to allow building and publishing things like patchpacks etc. Currently I think it is sufficient to have these
There was a lot to unfold in your comment; I hope I have them all :) Lets please continue the talk, and see what we can do to make everyone happy here! This is all about collaboration :) Tnx!
Sorry for the delay, the idea behind the XML is to download a single file (faster and more reliable than multiple HTTP queries) in order to populate the info required for my OpenTTD Manager to show versions info, and allow direct download:
As you can see, all I need is version number, date, and download URL. I suggested XML because VB6 features very simple XML parser.
I strongly disagree with the comment about XML being an unfriendly format. Please check out the following sample XML that would be needed in this case, and let me know if you find it complicated. XML does become cumbersome and tedious when additional features such as namespaces or attributes are introduced, they could easily drive mad any developer / parser, but they are not required here. As a personal opinion, the guy who invented namespaces should be lapidated.
The ill-use of XML may have damaged its reputation, but the XML format at its core remains simple and elegant. The currently used text files could change and are not very useful, specially when their URL keeps changing and no one knows what info and in what order could they provide. XML avoids all these problems, and allows adding info without breaking current implementations.
The Previous Versions combo box is populated from some binaries URL, but this might be removed because that URL is not updated anymore either.
Just joining in a bit. I'm Zuu on the forums/irc and ran OpenTTD Auto Update for some years, but I do not plan to maintain it further. If I can say something, it is to if possible publish information such that it allow standard tools on platforms to use it. That being said I don't know any standardized tool on Windows to upload software using some sort of finger server.
For the big releases it may be possible to setup CI/CD to push to windows store. If it would be feasible to have a nightly channel there I don't know. If windows store is not possible, then maybe there is something like apt but similar for programs on windows we could work with that is open and reasonable to offer as either you use this or you download on your own or build it yourself.
Okay, after almost a year, I finally found time to tackle this issue. What I came up with will replace https://finger.openttd.org/ soon (tm).
https://cdn.openttd.org/ is the URL of our new CDN. It is fully browsable (and cached). What replaces finger are two files:
https://cdn.openttd.org/config.yaml: this tells how this CDN is build up. It tells which folders are indexed, and what is special about them, if anything. Most important for automation is the
https://cdn.openttd.org/latest.yaml: this tells of each release what the latest version is. For example, in category "openttd" you will find "stable", "testing", "master", and several PRs. The
In case you don't care about all releases, don't worry: there is a subset of this file in every subfolder. For example: https://cdn.openttd.org/openttd-nightlies/latest.yaml
In every release is, as has been for a long time, a
There is also a
This is not yet in production, but will be soon. I need to automate a few more things; after that all traffic will be redirect here, and finger will be closed.
Found a bug or problem? Let me know.
I am planning to do so yes, just haven't gotten around to it. Will push the change tonight.
I don't really have a way to redirect people, as the formats are very different. As these URLs are mainly used for automation, there is not really a point. So the idea was to simply pull the DNS entry, and tools will simply stop working. I feel bad about this, but I also don't see any other way. Guess that is also the reason I haven't done this.
Just went through the stats. Turns out, only 2 users seem to still be using this URL. So I guess the damage is rather limited. Sadly, which-ever tool they run, it doesn't tell the User-Agent, or, pro-tip, put their email in the User-Agent, so I have no way of knowing which tool it is.
But .. such is life I guess .. after 15 years .. time to retire finger.openttd.org I guess. Anyone wants to say some words?