It's still not a 100% solution, but I think sourcehut is a good fit for CDE CI, mostly because it directly supports running jobs on a wide array of Linux distros *and* BSDs. It also works with just using their CI against a repo hosted elsewhere (in our case, sourceforge). It does have 2 major shortcomings: 1. Sourcehut supports more OSs on their hosted CI than anybody else, but they still don't cover all systems that CDE intends to run on (ex. no illumos distos). I think this is still better than needing to run the build servers ourselves and/or not have CI at all, but it is a shortcoming. 2. As you note, there's a question of who "owns" the CI stuff; if a person sets it up and manages CI jobs but then stops working on CDE, someone else would have to manage it. Since CI configs could be managed in git, I personally feel that such a handoff wouldn't be too hard, but it is a possible point of friction.
In particular, while I couch this in hypothetical terms, I actually prototyped this out once (and indeed if you search back through my posts on the mailing list, you'll see that I always post comments as "here's an exact build output on sourcehut along with the script to reproduce it"), and if there's actual interest in this I'm happy to take point on it. - Brian On Sat, Nov 28, 2020, at 7:20 PM, Jon Trulson wrote: > On 11/28/20 3:54 PM, Danilo Pecher wrote: > >> Hi folks, >> >> May I offer a suggestion? We need something of a release strategy. We should >> depart from the "pull stuff from the git repo" strategy in the Wikis, >> because we keep breaking our build by pushing untested stuff. >> >> As I build CDE daily on several platforms to test the builds, I can pretty >> much pinpoint the latest breakage to Thursday. On Wednesday it built on >> FreeBSD, NetBSD, Raspbian, Ubuntu, Fedora and CentOS - on Friday it was >> broken on all of them because of the breakage I reported earlier today. >> > > This is going to happen... The issue is not a release strategy problem, it's > a lack of CI problem. Of course the mistake in the above issue was > committing a change that had not been tested in a full CDE build. That is > something we try very hard to avoid, but apparently that did not happen with > the libcsa changes. > > But a problem is that that even if it had, and lets say it worked on the > linuxen - there is no guarantee it would not break on the BSD's or Solaris > for example since people will (hopefully) test on the OS/hardware they have, > and that will be good enough for them. > > Ideally, when someone comes across a problem on a platform, they should send > a patch along that fixes it. But not too many people do that. As a matter > of fact, it's pretty rare these days. > > And I can only speak for myself, but I have a day job - so I don't get a lot > of time anymore to 'play' with CDE, and write patches for people who can't be > bothered to write and submit them themselves. > > Having some sort of CI would be a good interim solution for that, but alas, > there is no such animal with SF. It would be up to people (like you) who > can/do run multiple OS's and can identify problems. But then depending on > that has it's own issues as people enter and leave the project. > > I'm not really sure how to resolve that problem, other than setting up some > sort of setup like you have and using jenkins or some such to test all builds > (based on a commit) and send a status somewhere indicating failure. But that > will take more time than I currently have, and money too. > > Master should generally always be considered 'unstable' - though it should > ALWAYS be build-able on linux (ubuntu LTS). Though I will admit - if you > send a patch or commit one, you should certainly make sure it doesn't break > things. But as I mentioned above, without some kind of formal CI > infrastructure we can't really 'enforce' that. > > >> For me personally that isn't much of a big deal, but I'm out there banging >> the drum for the project and I look a bit of a berk if people then run into >> a broken build by following our Wiki instructions. Wouldn't it be better if >> we regularly released tested tar.gz releases and left the bleeding edge git >> stuff to internal testing? It would also greatly reduce the >> pre-requirements, especially on FreeBSD where, due to the rampant dependency >> bloat in the ports collection, just compiling git can easily hand you a >> 3-hour time penalty. >> > > Odd... I was test building on FBSD some months ago for the autotools branch, > and I just installed the relevant packages. IIRC, there was very little I > had to actually build via the ports collection, and when I did, I only needed > to do it once. Don't recall off-hand what I built vs. what I installed via > the package manager. I believe I just followed the wiki :) And building git > cannot be more expensive than building CDE... > > Also, 2020 has been somewhat of a challenging year :) > > -jon > > > > > >> Cheers, >> Danilo >> >> >> _______________________________________________ cdesktopenv-devel mailing list >> cdesktopenv-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >> > > -- Jon Trulson "Entropy. It isn't what it used to be." -- Sheldon > > > _______________________________________________ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
