[Feature Request] Setup config.develop.qmk.fm

[skullydazed]

Description

The API now supports building for branches other than master. To make it easier for people to test develop we should expose a new instance of configurator that makes use of this. This issue is to discus the best way to do that.

My thoughts on that follow, I'm open to changing any of this.

The metadata can be fetched from keyboards.develop.qmk.fm, much like #927 fetches from keyboards.qmk.fm.

To use the develop branch you set branch in the keymap JSON. I believe adding branch: 'develop' somewhere around line 610 in src/jquery.js would do it.

For deployment, since we can't have multiple URLs on github pages, we can upload to one of our S3 buckets like we do for the API data. The github action that does that is here: https://github.com/qmk/qmk_firmware/blob/master/.github/workflows/api.yml

Once we're uploading static files to S3 we can setup the config.develop.qmk.fm hostname.

We've talked in the past about changing the color scheme and/or graphics to indicate you're getting beta level firmware. Are there any other changes we might want to incorporate as part of this?

[yanfali]

Couple of thoughts. No, I wouldn't change the code like that, I would make it a setting in the data model. Is there an API to get the list of branches we'd like to expose? Or is just two branches? As for color scheme, I would use a watermark graphic in the background that says something like beta or experimental, or possibly even the branch name, which might be doable with SVG and opacity and Z-index.

[skullydazed]

No, I wouldn't change the code like that, I would make it a setting in the data model.

I assume this refers to the metadata hostname? I'm not tied to any particular implementation, just noting what the proper data source is.

Is there an API to get the list of branches we'd like to expose? Or is just two branches?

Not currently. I think the assumption so far has been that only master and develop would be exposed, but we have not made that decision explicitly. I think that's a good place to start, personally.

If we want to go further github already exposes all available branches here: https://api.github.com/repos/qmk/qmk_firmware/branches

As for color scheme, I would use a watermark graphic in the background that says something like beta or experimental, or possibly even the branch name, which might be doable with SVG and opacity and Z-index.

This seems good to me.

[skullydazed]

Getting back to this, I think I can create the workflow to upload to S3. I'll get started on that.

That still leaves an open question around implementation for specifying the branch and adding the branch watermark.

[yanfali]

We can probably have the UI code look at the hostname URL and just configure itself differently based on that value. A static map would be enough to prove it out. Can we get the S3 bucket to serve the assets?

[yanfali]

Sorry I haven't been paying attention here. What's the status of this? I was thinking it'd be neat if we can just get the branch we want to build against from the DNS name and publish a bunch of DNS names we want to expose with a wildcard cert and wildcard DNS

https://en.wikipedia.org/wiki/Wildcard_DNS_record

e.g.

develop.config.qmk.fm - would build develop branch audio_out.config.qmk.fm - would build the audio out branch

That way you wouldn't need a branch drop down, you could just use the branch name.

[skullydazed]

The status is I still need to figure out where to host the files. Digital Ocean has an App platform we might be able to use that's CDN fronted, but I haven't had time to dig into that yet. Another alternative is to create separate github repos that we push to that exist solely for new gh-pages endppoints.

Wildcard DNS is a great way to go, but it's not supported by any of the hosting options we've been looking at. However, we can implement the app side that way and work on the hosting side asynchronously.