endless-sky
Autoupdate: Don't fail if assumed default branch doesn't exist
The Autoupdate job is failing on manifests/Cromha Expansion.yaml.
The main branch of this plugin's repository is called "main", not "master".
On the long run, I would suggest that failing to update a plugin should not cause the whole job to abort, it should instead try to update the other plugins, and only raise the errors that happened at the end. This way, if an error is limited to a plugin, maintenance of the endless-sky-plugins repository would not be required to keep it updating the other plugins.
This would happen if a plugin updating from commits does not have the branch name configured:
According to ES's RFC 0001:
branch: Allows for special branches to be used when type iscommit. If omitted, the default branch will be used instead.
This would mean the issue is not with the manifest, but with the update script assuming the default branch is master, while it may not be.
I've updated that manifest file to refer to the main branch so it should work the next time the autoupdate job runs.
https://github.com/endless-sky/endless-sky-plugins/issues/1004 The same thing was happening with another plugin manifest as well. We can't currently just use the default branch, as far as I know.
You can get the default branch using github's api like this: https://api.github.com/repos/Pshy0/es-ruin-the-fun There is a "default_branch" field.
We should try master, then main, then (if its on github) the api. Autoupdate is supposed to be independant of git hoster, but as a workaround to minimize errors it's ok. As last resort there's still the branch field warp just used.
This script gets the repository branch pointing to the same commit than HEAD:
#!/bin/env sh
HEAD_COMMIT=$(git ls-remote $1 HEAD | head -n 1 | sed -e 's|\t.*/\?HEAD$||')
HEAD_BRANCH=$(git ls-remote --heads $1 | grep "$HEAD_COMMIT" | head -n 1 | sed 's|[0-9a-f]\{40\}\trefs/heads/||')
echo "$HEAD_BRANCH"
When I change the default branch of one of my github repositories, the change is seen instantly:
Other tests:
Framagit:
Gitlab:
NOTE: you can certainly do that after cloning, without git ls-remote (shouldn't you be on the right branch after cloning anyway?)
