Open T-vK opened 2 weeks ago
I think I have found a ... somewhat acceptable workaround. The two main issues with storing binaries directly in a git repository are:
In order to work around that you can use a separate branch and essentially disable the commit history on it.
I'm using the gh-pages branch to store all my firmware builds and whenever I push a new firmware into it, I write it into the first and only commit that exists on that branch. This can be achieved quite easily like this:
git checkout gh-pages
git add ./firmware/
git commit --amend --no-edit
git push --force
In order to still have proper source control on the actual html code of the GitHub Pages site, I store my index.html on the main branch and copy it into the gh-pages branch on every push.
I am of course not doing any of this manually. I used GitHub Actions to automate it all.
I don't know if it makes sense to link my project here because it will undergo a lot of changes the coming weeks, but here it is nevertheless: https://github.com/T-vK/ShowboxInterceptor
I also managed to dynamically create manifests on the fly using unmodified esp-web-tools. The trick is to intercept the fetch request and inject a generated response. See index.html in my repo.
If anyone has a better idea on how to do all this, I'm very open to having a discussion about it.
I am using GitHub Actions in order to automate my build process. So basically every time I push a change, it automatically creates a new build and adds a release to my GitHub repo making the binaries accessible. That in itself works great and the logical next step would be to utilize GitHub Pages in order to flash any release. But that is where I'm running into a big issue: I cannot fetch an asset from a GitHub release from the JavaScript of a GitHub Pages site because of how GitHub has set up their CORS rules.
When you search for that CORS limitation you actually quickly find other users of esp-web-tools running into the same issue.
I would like to know if anyone has found a way to make this work in some way.
The only way I could think of would be to store the builds directly in the git repository, but that would unnecessarily bloat the repo and is bad practice to begin with. Unfortunately, the only other way I see is to host on some paid storage solution, which is less than ideal for an open source project that doesn't make any money.