Maybe this discussion is slightly off topic, and at the risk of derailing things I’d like to put out my view on this.
There is more to it than just “using Github’s computing power”, just as there is more to using AWS than “using Amazon’s computing power”. That’s only a small part of it: it’s also the ecosystem, the integrations, the maintenance cost, the *ease of use*, the support, etc. Django’s “core business” is Django. Time and resources that are spent not focusing on improving that should be reduced. Keeping Jenkins alive and stable seems like a waste to me. Something similar could be said about flake8 vs black. Jenkins is actually a really interesting and unique piece of technology, far more interesting than most people realize. But who cares because we don’t need interesting. We need to run “pip install flake8 && flake8” on every commit and show the results in Github. That’s a solved problem thanks to Travis, CircleCI, actions or even Gitlab-CI with 0 effort from us. So IMO it shouldn’t matter at all if Jenkins is open or closed source. Time is, as always, our fiat and the expenditure of it is what counts. To that end I would honestly avoid self hosting runners, there are some easier alternatives we can try first to support Oracle. Anyway, I will make the flake8 merge request tomorrow and we can see where we go from there. > On 7 Nov 2019, at 01:10, Matemática A3K <matematica....@gmail.com> wrote: > > > > >> On Wed, Nov 6, 2019 at 3:51 AM Carlton Gibson <carlton.gib...@gmail.com> >> wrote: >> Hey Shai. >> >>> On Wednesday, 6 November 2019 08:43:21 UTC+1, Shai Berger wrote: >>> >>> Is there benefit enough in GitHub Actions (over Jenkins) to justify a >>> move from an open-source based solution? >> >> I don't think we have to move away entirely but it would be good to bring in >> something else... (or at least try it...) >> >> These are the top on my mind reasons for wanting to: >> >> * Mariusz spends Quite a lot of time™ maintaining Jenkins and all the job >> definitions etc. This doesn't go away with another builder but if we can >> move to declarative config file in the repo, then that could become shared >> work. (Jenkins has this these days no...? But we don't...) >> * I'd really like to try GitHub actions Windows builds. Maybe we could get >> Jenkins to behave better but currently we have a failure on every force >> push. >> * Maybe we can stage runs: i.e. do the lint, and some basic builds first. Do >> one Python against each DB before running then all. And so on, to save some >> trees. (Again maybe we might be able to do this with Jenkins but it seems >> more likely to actually happen if we give GitHub Actions a trial.) >> * I think we're running up against capacity for the sponsored space, so >> builds slow down. If we can spread the load we should get faster CI. >> >> Kind Regards, >> >> Carlton > > I also share Shai's concerns. Thinking a bit about it, it is about depending > on other's resources for the workflow. Nothing in Django changes, as all the > tests are the same and can be ran with tox - and all the source code is the > same - the difference would be using Github's computing power instead of > Jenkin's for leveraging resources (i.e. manpower) which are not infinite. > > It would be ideal - to me - to have the entire workflow depending on FOSS > solutions. I guess this was one of the reasons that Jenkins was chosen > instead, say, Travis, but if the health of Django improves with this, the > overall impact to the the community will be better than staying being users > of a project which we don't contribute (at least to my knowledge): almost > nothing changes to Jenkins - well, it starts loosing users over Github, I > think the same may happen with Gitlab - and Django gets an improvement > because is already dependent on Github. > > It would be also an alarm to Jenkins in the way that it needs to catch up > with others, if Github Actions end up providing the same functionality with a > lower setup and maintainability effort, the might migrate there. > > When you use others' servers like in SaaS, there is no way but trusting the > other to "behave as expected", even using the AGPL. As long as it a conscious > decision, seems good to me :) > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/e509afbc-21ea-4b3b-9e23-18718594fa49%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CA%2BFDnh%2BTMwfRNTWQiK_gtFjJ-A4wTLsSofv_DV3hPgqcmU7D_g%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/60D608A7-2902-42A2-A2A7-E4EA8395DA07%40tomforb.es.
