deploySite task in github workflow failing

[another_commander]

We seem to have an issue with the auto-build script on github. Earlier tooday I updated the code on master and the build failed. That was because we were using a recently deprecated upload-artifact action. After fixing that, the workflow run again but although a pre-release was successfully created, the build was still reported as failing. This is the output of the deploySite task, which was the point of failure:

Code: Select all

Run actions/deploy-pages@v2
  with:
    token: ***
    timeout: 600000
    error_count: 10
    reporting_interval: 5000
    artifact_name: github-pages
    preview: false
Artifact exchange URL: https://pipelinesghubeus24.actions.githubusercontent.com/yOkN68OsvTXlm3slYtE6HCHMi8FrQcLpFlh55gIeh5iUhX4PxO/_apis/pipelines/workflows/14112224591/artifacts?api-version=6.0-preview
Error: Getting signed artifact URL failed
Error: HttpError: Cannot find any run with github.run_id 14112224591.
    at processRuntimeResponse (/home/runner/work/_actions/actions/deploy-pages/v2/src/internal/api-client.js:48:1)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at getSignedArtifactMetadata (/home/runner/work/_actions/actions/deploy-pages/v2/src/internal/api-client.js:82:1)
    at Deployment.create (/home/runner/work/_actions/actions/deploy-pages/v2/src/internal/deployment.js:68:1)
    at main (/home/runner/work/_actions/actions/deploy-pages/v2/src/index.js:30:1)
Error: Error: Failed to create deployment (status: 404) with build version ca04e6454be56bc6c11c4e29b9ccd493c3b3a92a. Ensure GitHub Pages has been enabled: https://github.com/OoliteProject/oolite/settings/pages

In order to fix it I had to completely disable the deploySite action, I am not sure what the issue is here. Not a huge deal, as the action is just about uploading the doxygen output to a website, but it would be nice to get it back if we could. Any input resulting in a proper fix would be much appreciated.

Thankfully the nightly builds continue to be generated properly so the latest one contains the most recent code changes (the -nodust cmd line option, that is).

[MrFlibble]

Any input resulting in a proper fix would be much appreciated.

I bounced off this a little on my 'linux library bundle fix' fork, and mostly ignored it, as it was not my main focus.

Will have a look, maybe later today as github are due to deprecate an Ubuntu release, and I hope to make a fork of latest release available at that older version, for those nursing old nVidia cards with proprietary drivers etc.

Re: My fork. When the dust settles, and as we have to go to the next Ubuntu up, I'll try to work out a less manual way to bundle the libraries and do a PR. It's pretty much just updated linux-dependencies. It'd be quite sweet to do a 'fixed' version of 1.90 for current distros, unless consensus is that it's near time to settle a 1.92 as stable.

[Cholmondely]

Was moving to GitHub something which is now proving to be a mistake (with their now relentless drive to update everything which moves)?

[another_commander]

Absolutely not, it was the right move.

[MrFlibble]

Was moving to GitHub something which is now proving to be a mistake (with their now relentless drive to update everything which moves)?

I agree with a_c.

The apparent 'relentless drive' is not so bad really. They tend to keep runners available until their proper end of life.

So the Ubuntu 20.04 github runner will be fully retired this coming Tuesday. The same day that Ubuntu cease maintenance updates for it. Any releases built with it may remain available.

There's nothing to prevent us from building binaries on older or more obscure platforms at home, then uploading them to the Github release... where there' any real point. I'll do that occasionally with Starter for older MacOS versions.

[Cholmondely]

I'd understood that it was GitHub which made it impossible to simply update the broken url in the Oolite v.1.90 Expansions Manager

[MrFlibble]

I'd understood that it was GitHub which made it impossible to simply update the broken url in the Oolite v.1.90 Expansions Manager

Not impossible, but far from simple. I suppose it'd be easiest as a one-off, to build at home, then manually re-upload them. I'll have a crack at doing that for at least the Linux versions, when time permits, and see if I can fix the bundle of libraries if they're not right while I'm about it. 1.90 ought to be made functional if it's the 'current stable' release. It's slightly complicated by the self-installer gubbins.

A quick prod at the Mac version, as it's a nice simple zip file...

AddOns/Debug.oxp/manifest.plist: change http://www.oolite.org/ to https://www.oolite.space/

fix broken bb links in:
Oolite.app/Contents/Resources/Scripts/oolite-contracts-cargo.js
Oolite.app/Contents/Resources/Config/gpu-settings.plist

Alas, the string 'oxz-index-url' only occurs in the Oolite binary. The new URL being two bytes longer than the old one makes it a non-trivial (for me) hack to simply binary edit. I tried it, and my guess is that it broke all the offsets in the executable, so it fell over. I tried to guess my way round it, and changed the 3A preceding the value/key to 3C, but still no. Anyone?

My conclusion, even the Mac version needs a rebuild to fix that one string.

The same is true of the Linux builds. The .GNUstepDefaults file is created by the Oolite executable. If the contents of that file do not vary based on location then it's possible that a wrapper script could take care of it, or a patch script. Not an easy fix on github itself, but we can still upload our own fixed files.

Another idea... https://github.com/OoliteProject/oolite ... s/tag/1.90 could have a very large font boldface pointer to viewtopic.php?f=2&t=21368

[phkb]

Alas, the string 'oxz-index-url' only occurs in the Oolite binary. The new URL being two bytes longer than the old one makes it a non-trivial (for me) hack to simply binary edit. I tried it, and my guess is that it broke all the offsets in the executable, so it fell over. I tried to guess my way round it, and changed the 3A preceding the value/key to 3C, but still no. Anyone?

Could we create a URL that is the same length (or less than) as the previous one, but which points to the new location? That *might* allow the binaries to be edited.

[MrFlibble]

Could we create a URL that is the same length (or less than) as the previous one, but which points to the new location? That *might* allow the binaries to be edited.

Cunning! I'll see if editing to same num chars can work after tea.

[MrFlibble]

Could we create a URL that is the same length.

Thoughts/progress.

https://addons.oolite.space/api/1.0/overview/ exists.. Can/should/could Oolite use https for the expansion manager?

Leaving out the last two chars of the URL works, at least for the Mac version. I say works.. obviously the URL is non-existent.

Code: Select all

  I tested replacing:
http://addons.oolite.org/api/1.0/overview
  with:
http://addons.oolite.space/api/1.0/overvi

  And it ran fine.
  Note, the absence of a trailing slash probably incurs an extra redirect.

  If http is the only way, then we could try and set up:
http://addons.oolite.space/api/1.0/index/
  and if https is do-able..
https://addons.oolite.space/api/1.0/repo/
  Both have the trailing slash already.

If it's trivial to do.. would somebody with relevant access please set up aliases at addons.oolite.space to allow both those last two to be tested.

For reference: The offending portion in the Mac binary looks like this:

Code: Select all

0045B700 6F 6E 00 75 │ 70 6C 6F 61 │ 64 5F 64 61 │ 74 65 00 74 │ 3A 00 64 3A │ 00 61 3A 00 │ 6B 3A 00 69 │ 00 75 00 68 │ 74 74 70 3A │ 2F 2F 61 64 │ 64 6F 6E 73 │ 2E 6F 6F 6C  on.upload_date.t:.d:.a:.k:.i.u.http://addons.ool
0045B730 69 74 65 2E │ 6F 72 67 2F │ 61 70 69 2F │ 31 2E 30 2F │ 6F 76 65 72 │ 76 69 65 77 │ 00 6F 78 7A │ 2D 69 6E 64 │ 65 78 2D 75 │ 72 6C 00 4F │ 6F 6C 69 74 │ 65 2D 64 6F  ite.org/api/1.0/overview.oxz-index-url.Oolite-do

[MrFlibble]

If the domain oolite.org expires on the 9th May, I might snap it up to catch, log and redirect to oolite.space. It'd not be expensive. Does anyone know who/why is holding it? The WhoIs info points at a French lady.

Redirecting old bb links is something only the exalted one can do. It ought not take much effort to add a wildcard redirect for all the /bb/ links.

The "Let's Encrypt" cert on aegidian.org conked out last July, so I guess he's not kept an eye on acme.sh. His 'current' sites get redirected from the aegidian.org variants, but of course, if an https://WHATEVER.aegidian.org link is clicked from a stale link, the cert issue will scare off the user.

Perhaps someone should tell Giles. Maybe he didn't notice.

[phkb]

Could you use a URL shortening service (like Tiny URL) to shorten it? That way, nothing else needs to be created.

[hiran]

I enabled the commented out steps and switched to the latest version 4 of the workflow step.
Works.

[hiran]

Could you use a URL shortening service (like Tiny URL) to shorten it? That way, nothing else needs to be created.

Rather than adding yet another dependency I'd involve timer to test whether https://oolite.space/ is feasible.

The string oxz-index-url is looked up in the configuration (GnuStepDefaults?) file. If not found, the builtin default is used.
https://github.com/OoliteProject/oolite ... ger.m#L311

This behaviour is already documented in https://wiki.alioth.net/index.php/Apple ... revious.29