Guide for self-hosting betas via github actions

[Lusito]

Hi Philipp,

we talked about this in London last year, but I didn't get to actually look into this until now.
From the readme, I can see how to build and upload an artifact, but what else is needed in order to self-host a beta version on github?

From what I gather, an update link is needed: https://extensionworkshop.com/documentation/manage/updating-your-extension/

But how do you maintain and serve this file via github? Via github pages?
It would be nice if the github action could automatically update the json and push it to a URL that stays the same.

Cheers

[kewisch]

Hi @Lusito, thanks for filing this issue! I think updating the docs here would be great, either in the README or a wiki page. We've recently added https://extensionworkshop.com/documentation/publish/distribute-pre-release-versions/ which provides some more information.

I could imagine combining action-web-ext with another action that would upload the files for hosting, either through gh-pages, or another hosting provider. What might be interesting to add to action-web-ext would be something to generate or modify the update manifest accordingly.

Is this something you'd like to explore further?

[Lusito]

Thanks for the link. Especially the part about auto-migration back to stable is something I did not know.

Yes, that sounds good. Though I wonder if there is a better way than using gh-pages, since gh-pages is sometimes used for the add-on homepage.

Would a raw link to a branch work? Looking at how the package.json shows up correctly:
https://raw.githubusercontent.com/Lusito/forget-me-not/develop/package.json

This would avoid the need for gh-pages. It could be just any branch and filename

[kewisch]

For our purposes, anything that is a https link and has mime types working correctly should work. I'm not sure mime types are right for the actual zip/xpi files using raw GitHub.

For GitHub's sake you'll want to use something that is covered by a CDN or otherwise made for mass requests. The more users you collect the more the update manifest and packages will be accessed.

[Lusito]

Sorry, been a bit busy last week. You're probably right about the CDN.

So, to get this correctly, I'm assuming the following needs to be done:

• When I want to release a beta update, I need to update the manifest version and push a github tag.
• A github workflow with action-web-ext and action-gh-release, runs whenever I push a new tag branch to github.

What I don't know yet:

• How to create or update the updates.json. This must contain the just released version number and a link to the released file.
• I use gitflow to create release tags. These will show up on github as releases. Since the gitflow code only shows a push of develop, master and the new tag, I'm assuming, that github creates the release automatically when a tag is pushed. But will this conflict with action-gh-release or is action-gh-release only changing the way releases are created?
• What kind of versioning pattern should I use? I recall that using a beta suffix is not supported anymore in Firefox.
• web-ext build creates .zip files. the documentation of web-ext sign talks about downloading a signed xpi file, but will this be the same filename except for a .xpi file ending? I've actually never used that command.
• I guess one could use json for in-place editing of the updates.json, but that would still require some variables, like the filename of the xpi.

[kewisch]

* How to create or update the updates.json. This must contain the just released version number and a link to the released file.

There is info on this here. You can have all of your versions listed there, or just go with the latest release.

* I use gitflow to create release tags. These will show up on github as releases. Since the gitflow code only shows a push of develop, master and the new tag, I'm assuming, that github creates the release automatically when a tag is pushed. But will this conflict with action-gh-release or is action-gh-release only changing the way releases are created?

You don't need action-gh-release necessarily, this was just an example on how to create a release and attach the signed xpi to it. You can also instead upload the xpi somewhere else if you prefer.

* What kind of versioning pattern should I use? I recall that using a beta suffix is not supported anymore in Firefox.

I seem to recall a bug suggesting we should only support what Chrome supports, but I don't think we followed through with this. If it installs in Firefox, then it should be fine.

* web-ext build creates .zip files. the documentation of web-ext sign talks about downloading a signed xpi file, but will this be the same filename except for a .xpi file ending? I've actually never used that command.

Yeah, an .xpi file is just a .zip file with a different name. xpi is the extension that was historically used for Firefox Extensions. You can certainly use zip files if you prefer.

* I guess one could use [json](https://www.npmjs.com/package/json) for in-place editing of the updates.json, but that would still require some variables, like the filename of the xpi.

Some variables certainly required. I think you could just generate a new one from scratch with just the latest version. You'll only need more than one if you use strict min/max versions.

[kewisch]

Closing this to clean up a bit. I hope we meet again some time, join me at summit.ubuntu.com if you are interested :-)