On Tue, May 07, 2024 at 11:52:02PM +0200, Robert Marko wrote: > On Tue, 7 May 2024 at 23:25, Paul Spooren <m...@aparcar.org> wrote: > > > > Hi all, > > > > For some reason (resource usage?) our snapshot builds do not include the > > LuCI web interface. I think it’s an advantage to have LuCI installed in > > snapshot images since a) it installed for all releases anyway and b) often > > it’s just nice to have the web interface directly available. > > > > Is anyone against having the interface installed by default? I remember > > from multiple (in-person) discussion with fellow developers, that they’d > > prefer it being installed. > > > > If it’s an oversight I’d like to see it added to the default packages (via > > the builedbot config), if there’s a reason to keep it from snapshots, I’d > > like to understand the details. > > +1 for LuCI by default in snapshots as well from me.
I understand the usability we may gain from that but you should all be aware that this basically means only having a single buildbot phase with a very slow turnover time, and that is a HUGE disadvantage for development and use of the buildbot as classic CI took. Let me explain why: Currently the snapshot builders are only building **target-specific** packages as well as packages included in the image by default. (We call that "phase1"). That means that a single build takes around 2~3 hours, depending on the target and the machine carrying out the build. In this way we manage to have every target build once approximately every 24 hours. If we wanted to include LuCI, that would basically mean that we will not only have to include all the LuCI modules and applications, but also **all their dependencies** which is basically half of the packages feed. A full build of the packages feed (called "phase2") takes around 4 additional hours (best-case) and up to 17h (worst-case). We also don't build for each (sub-)targets (think: ramips/mt7621), but only for each architecture (think: mips24kc), and many (sub-)targets share the same architecture. This results in every **architecture** being re-built approximately every two days. If we would do this for all (sub-)targets, the number would obviously be even worse, we'd probably only see fresh images once or twice a week, which is too slow to catch problems and too long for users to test changes in a timely manner. It would be a humongous slow down of development and testing on generic and core parts. For me it would mean that I would have to invest a mid four-digit $ amount into hardware to still be able to do meaningful development, and probably it would mean that for quite a few of us. What I could imaging is to have an **additional** build stop on top of that, lets call it "phase3". That could be triggered on completion of phase2 and then assemble images for all (sub-)targets using that architecture including LuCI **in addition** to the phase1 snapshot builds. From a usability point of view, maybe the answer can be much easier and the solution is already there: 1. Go to https://firmware-selector.openwrt.org/ 2. Select 'SNAPSHOT' on the right. 3. Enter the device you want to put OpenWrt on or update. 4. Click on "Customize installed packages and/or first boot script" 5. Add 'luci' (or 'luci-ssl' or 'luci-ssl-openssl', ...) to the list of to-be-installed packages. Maybe we can have an easier way to do that in that web UI and then everybody will be happy? And yes, the images generated using the firmware-selector are being cached there. In this way only the first user requesting an image with additional packages (luci in this case) would have to wait ~ 1 minute for the image to be generated, every subsequent user requesting the same image would be served instantly. The advantage would also be that we don't generated huge amounts of images for legacy devices without any users, nor for "science-fiction" R&D platforms. Just my 2 cents... _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
