Allow users to add webhooks to auto-update the Asset Library records for releases.

[willnationsdev]

On GitHub (and perhaps on others? I don't know), I am able to define a webhook that initiates a workflow whenever a repository of mine has a new release. I am wondering if it would be possible to have these releases automatically update the associated commit/tag used by the Asset Library API to fetch the data.

On the upside, it would mean that I can configure the "version" of my asset in a one-and-done fashion. No need to update the info in multiple places.

On the downside, I am aware that it is the repository's owner who configures under what conditions the webhook triggers a workflow. If they set it to anything other than "Releases", then it could submit an unreasonable number of version/asset modifications to the AssetLibrary (you would definitely need #143).

If we don't have any ability to control the flow though, I don't know if we would want to do this. I just don't know the specifics of what can be controlled on the receiving end of webhooks, so maybe it's not as bad as I think it could be? Thoughts?

[Calinou]

This is a good idea, but how would it play with a changelog system? I've been planning to add version history support, where each version can have its own release notes.

[willnationsdev]

Hmm. Well, you could 1) fetch release notes from the foreign API if it supports it (GitHub has a title and description for releases for example) or, if it doesn't support that, then 2) you could establish a convention of users maintaining a CHANGELOG.md file or something, that way the data can be pulled directly from the repository. 3) In the event that they don't have one of these files, then you could create a stubbed barebones string for the changelog field in the version history data and users could update it later on, without needing to submit a whole new version to the Asset Library.

How does that sound?

[Calinou]

@willnationsdev Sounds good to me 🙂

[willnationsdev]

@Calinou Out of curiosity, how are things coming with the version history stuff? One of my friends said he was interested in helping out with that. Do you already have a WIP implementation? If not, is there anything he would need to know / gain access to in order to get started with refactoring the backend API / front-end GUI, etc.?

[Calinou]

@willnationsdev The WIP reimplementation is at Calinou/godot-asset-library-laravel, but note that I'm not looking for code-related help yet. My current focus is on exposing a 100% backwards-compatible API at first, so that it works with the current Godot editor versions. Once this is done, we can look at exposing more data in an incompatible way in a v2 API endpoint (the routes are already set up for API versioning).

Also, if we are to source release notes directly from a CHANGELOG.md file contained in the repository, we might as well drop the per-version release notes to avoid duplicating information. Instead, each version would just have a version string, release date and the associated Git tag/commit. (Parsing changelogs for versions is a difficult endeavor, I don't personally believe in it.)

The same goes for sourcing the asset description from the repository's README.md. The asset submission process would fetch it automatically and fill the asset's description field with the README's contents.

[willnationsdev]

@Calinou

Parsing changelogs for versions is a difficult endeavor, I don't personally believe in it.

What if users could configure the Godot Asset Library to auto-insert the tag as the version string? That is, assuming the commit/tag field doesn't match the format of a commit hash.

not looking for code-related help yet

cc @Austinmack-dev. So he says. I guess you'll have to tackle one of the other things I brought up in godotengine/godot-proposals#142. We're basically stuck not doing anything but peripheral stuff until #143 and the "dependency management" decisions get worked out. No one seems to be talking about them much though. Anyway, that's all off-topic to this Issue. :-P

[Calinou]

What if users could configure the Godot Asset Library to auto-insert the tag as the version string? That is, assuming the commit/tag field doesn't match the format of a commit hash.

I plan to do this too. Inferring as many values as possible is a good idea to decrease the amount of effort required for asset submitters 🙂

[Calinou]

There's a GitHub action that can be used to automatically send edits for new commits: https://github.com/deep-entertainment/godot-asset-lib-action

However, please only send edits for tagged releases, not development versions (as those edits currently have to be approved manually by our small moderation team).