Since many distros now distribute the GTK3 version of Geany the nightly builds should also check GTK3.
Alternatively, we could even remove the GTK2 nightly builds as they are pretty much obsoleted by the Travis builds which are run more often and even against PRs. In contrary to the Debian nightly builds, the build results are of no further use and so are no better than the Travis builds, IMO.
I see only one advantage over Travis: if we would build the nightlies against the minimum required versions of GTK2 and GTK3 to ensure compatibility. But this would require compiling the whole GTK2 and GTK3 stack manually to compile against (the current GTK2 nightlies are built against the GTK2 stack provided by Debian Stable).
Yeah, I saw the benefit of the nightlys that they could use different versions of GTK from Travis, but compiling the whole stack seems a bit OTT.
But otherwise they don't add a lot any more.
Hence the proposal to drop the GTK2 builds instead of adding new ones.
OTOH, compiling the whole stack for GTK 2.24 and GTK 3.0 probably isn't the hardest thing ever, it just needs to be done. And it needs to be done only once we change the minimum required versions or a new Debian version is released (because of dist-upgrade and binary incompatibilities). The rebuilding can probably be solved easily scripted.
I believe people actually use the Windows nightly binaries, but probably not much on other OS.
If we want it should also be possible to build older GTK versions on Travis just the same, and with its support for caches, it'd also only have to be built once.
I believe people actually use the Windows nightly binaries, but probably not much on other OS.
I'd be curious how. As mentioned in https://github.com/geany/geany/issues/1979, the current Windows nightly builds are not compatible with the usual releases since the MSYS2 switch.
@b4n is it worth the effort and worth the increased build time on Travis? This would grow the build matrix. I think having test builds against the minimum GTK versions is nice to have but probably enough once a day and not for each push.
@eht16 I don't really think it's worth it to set it up, but for the build matrix itself I don't think it's so much of a problem. I added a few items to it recently, and yes it has a small impact on the reactiveness because it seems one of the build always only starts after one of the other finished, but it's not so bad either, so I don't think that should be much of a reason to do it or not.
I'd be curious how.
Well I meant we've gotten bug reports when it doesn't work, at least previously before the statement about using them was removed since they aren't compatible. FWIW, I don't think it was a good way to test bleeding edge Geany. In the future if/when anyone gets motivated to do it, it would be better to have the whole installer(s) built automatically when master branch is updated.
There are no issues about the nightly builds not being runable for several years, and the last ones by that @eht16 guy so they don't count :grin: So I would say that its a non-issue.
Travis builds the pull requests, it doesn't build master after merges, thats one thing nightly builds can do that Travis doesn't. That will pick up any issues with one PR affecting another even if they have no conflicts in Git.
As @codebrainz said, it should build an installable version for windows, and maybe a generic Linux binary tarball to encourage testing (ok, thats hopeful but still :)
Travis builds the pull requests, it doesn't build master after merges, thats one thing nightly builds can do that Travis doesn't. That will pick up any issues with one PR affecting another even if they have no conflicts in Git.
I think Travis *does* build also on pushes to master, e.g. https://travis-ci.org/geany/geany/builds/464017469 this was a regular commit without merge or PR, I think.
As @codebrainz said, it should build an installable version for windows, and maybe a generic Linux binary tarball to encourage testing (ok, thats hopeful but still :)
I agree, at least for the Windows installer part. Providing a Linux binary would be easy but I'm not sure how generic it can be built since we can't link statically. Maybe we could Flatpak or so for this if at all. The Windows installer generation is more fun: luckily NSIS exists for Linux and so cross-compiling the installer should be possible. The problem is just to get a MSYS2 environment running on Linux for the dependency management. In theory it could work with Wine but I never tested it.
I think Travis does build also on pushes to master
That wasn't really what I was meaning, what I meant was that when a PR is merged the other PRs are not re-tested to be sure they still compile/work with new master, eg if PR A removes variable X declaration, but PR B uses X, then merging A will make B fail to compile, but I don't think Travis notices on PR B if it already exists when A is merged.
For Linux, yeah I said its hopeful :) But flatpacks or snaps may not be good for testing since they are tied to the dependencies in the package. For testing we want a wide range of environments to be used, maybe forget it.
For windows, I didn't realise that the installer was built on actual windows, not the cross build, so I guess it depends on how much work it is to get going on the cross build to decide if its worth it.
Closed #2003 as completed.
I'd like to close this. We do have GTK3 nightly and CI builds and there is no more Travis, six years later :).
github-comments@lists.geany.org