> I just thought it's a better match because it comes with pacman, but also > because it is generally up-to-date w.r.t. to toolchains and wine. So we could > build the Windows binaries using the latest and greatest toolchain. > > Debian/Ubuntu is usually several years behind and I worry a bit if that might > cause trouble in the future if mingw packages require a newer toolchain > (mingw is also rolling like Arch AFAIK). But it's your choice. > > One more (personal) reason to use Arch: You know I'm working on a flatpak > version of Geany. Assuming we ever want to create such a flatpak image for > official releases via CI, then I would certainly prefer Arch Linux because > that has the latest flatpak tooling. > > But that doesn't necessarily mean mingw jobs must use Arch Linux containers > as well, so still your choice.
I was working on these scripts since 2021 or maybe even 2020 and had no problems with the toolchains provided by Debian, AFAIR. Of course, I cannot guarantee that it will keep it this way. But as previous long time ArchLinux user I also know sometimes ArchLinux is so bleeding edge that its toolchain or other components *might* be too new for other software which is not yet compatible. So I guess this can happen in both directions. And please stop this too old joke of Debian being "several years" behind. It's usually rather 1-2 years and this is on purpose. After all, I guess Debian and ArchLinux could work as base and given that the current setup works with Debian, I personally see no need to change it. > I don't really like that this repository knows how to build Geany and G-P. > > A developer might make changes in that area and might become unable to > proceed because he can't get CI to work as the job needs to be adapted. > > A realistic example: we might want to switch to the meson build by default > (or maybe only for specific platforms) and the PR to implement would be > unable to fix the CI. > > We should probably just provide the Docker image itself and not the scripts > to build Geany or packages. Agreed. We could move builders/scripts/build_mingw64_geany_plugins.sh and its companions to the Geany resp. G-P repos. Will try once I find time for it. I guess I did it this way because the initial idea of all this started with renewing the nightly build scripts and over the time it turned out to be usable for CI builds as well. > I think the current restrictions are OK. Perhaps we could auto-update the > image based on CI but I wouldn't trigger that from Geany repos but this > repository (this is where the dockerfile is after all). Sounds good to me. > Do we have anything to lose when giving forks access to the image, like > losing some GH actions budget to it? Not that I know of. To me it seems that GH actions are not billed at all for us and so there is also no budget or limit. Giving read access to forks should be OK, even if it would be read access to the world. We should note that images cannot be deleted anymore once they have been made public which is reasonable and probably also acceptable for a automatically built CI image. -- Reply to this email directly or view it on GitHub: https://github.com/geany/infrastructure/pull/7#issuecomment-1252868257 You are receiving this because you are subscribed to this thread. Message ID: <geany/infrastructure/pull/7/c1252868...@github.com>
