Premade builds do not have web ui active

[dosipod]

Hi ,
The web flashing is somewhat needed for the guys who are not very much familiar with pio which i hope are in the targeted users list,
still web flashing is also needed for the guys that do not have access to local pio and can only compile on gh .

I have checked now and I could flash esp32 with ledstrip project from the site and wifi ssid and pass can be set correctly ( fixed in #469)

Still web ui is not accessible ( might be the builds do not have the web ui enabled ) , i can ping and telnet to device just fine . Which is still does not make sense as someone using the site would still need to go to local pio and compile with that option for webui

As I do not have access to local pio i have tried as i do with other open source to compile on gh ( which works for wled & Tasmota )
In this example from Tasmota i see Artifacts

But for NightDriverStrip i do not see the Artifacts .

Could you double check that once installing from site that you also could access the web ui else clarify why your changes on
gh does not provide artifacts hence if one is to clone on gh and add web ui support it will still not provide an Artifacts which might be due to do with the workflow files used .

I work with students that do not own a personal PC but use a shared one and also for some other reasons ( big brother ) i am not
able to install apps on PC so i hope you would think about such cases . I have not had a chance yet to use NightDriver on an actual fixture due to those minor issues but was hoping that afterword we could help a bit from users point of view , demos ,, feedback ..etc

I could not see any option to create a feature request so had to be an issue .
Thank you

[rbergen]

Converting this to a Q&A Discussion.

[rbergen]

@dosipod It's indeed the case that some build configurations with WiFi do not have the web UI enabled. As most build configurations were not created by me but @davepl, he may be able to explain what the criteria are/were for (not) enabling the web UI for a particular build configuration on a particular device.

If you want to create a fork that also publishes a web installer - which is what you'd need if you can't use pio locally - you can modify the GitHub Actions workflow file in your fork so that it builds the web installer for (a specific branch in) your fork, and then push the build installer to a GitHub Pages branch in your fork. We could in principle create an artifact of the web installer file tree before it is pushed to Pages, but then you'd still need to host the web installer locally. As we push to Pages anyway whenever the web installer gets built, the artifact wouldn't add much from a project perspective. It would basically just sit there consuming GitHub's storage space.
Of course, if in your fork you want to modify the workflow file to not push to Pages but create an artifact instead, you're also free to do that.

[rbergen]

Because it's my lunch break anyway, a breakdown of steps to set up the GitHub Pages scenario:

1. Create a fork of NightDriverStrip if you haven't already done so. Make sure GitHub Actions are enabled.

2. Clone your fork locally (git clone ...)

3. Enter your local clone directory, and setup an empty pages branch:

   git checkout --orphan pages
   git rm -rf .
   git commit
   git push

4. On GitHub, under your fork's settings, enable Pages and configure it to publish the root of your pages branch.

5. Locally, checkout/create whatever branch you want to trigger web installer builds and deployments from (I'll assume publish for the remainder of this comment).

6. Edit .github/workflows/CI.yml. Extend line 58 to (also) trigger web installer builds for your fork and branch:

       if: ( github.repository_owner == 'PlummersSoftwareLLC' && github.ref == 'refs/heads/main' ) || ( github.repository_owner == 'rbergen' && github.ref == 'refs/heads/staging' ) || ( github.repository_owner == '<your GitHub handle>' && github.ref == 'refs/heads/publish' )

7. Save the file, commit and push.

GitHub should now trigger a build of your publish branch, including a build and push of your web installer. When done, it'll be available at https://<your GitHub handle>.github.io/NightDriverStrip (assuming your fork is called NightDriverStrip also).

Other changes you want to push to your web installer you can then also push to your publish branch.

[dosipod]

@rbergen Thank you for the clarification . I already cloned and setup basic actions to test . Did not think the web installer will be involved as for other projects i would just clone on gh , do my changes and collect and install from the resulted artifacts the but i will give it a shot . Appreciate the help

[rbergen]

@dosipod Just for the completeness of my picture: exactly how would you use the build artifacts if you can't install software locally on the machines you would use them on?

Concerning creating build artifacts, you can also enable that in your fork. I haven't tested this, but replacing these lines in CI.yml:

NightDriverStrip/.github/workflows/CI.yml

Lines 100 to 104 in b3f87ba

	- name: Push to GitHub Pages
	uses: JamesIves/github-pages-deploy-action@v4
	with:
	branch: pages
	folder: WebInstaller

with:

    - name: 'Upload web installer'
      uses: actions/upload-artifact@v3
      with:
        name: web-installer
        path: WebInstaller

should do the trick, according to the GitHub docs.

[dosipod]

We could use esptool on one machine . I also did not notice that NightDriverStrip does not have a stand alone ap mode hence ssid and pass would also have to be added to the build from our side .
Thank you for the replies but we have given up at this point as might be we are not in the target audience at the time but will try to comeback to that if we have a lot of free time .