Wow, the response has been much bigger than expected. That's great, it's good to know that this is a topic people are invested in. It shows me two things: 1. There is a certain degree of dissatisfaction about the current setup. 2. There is enough interest to support a more community driven approach to maintain a CI setup.
I was fortunate enough to be on the GitHub beta for quite some time and I have been using it very heavily since then. So let me try to address some concerns that have been raised in this thread (in no particular order): 1. Oracle: Possible 2. Should we move await for an open source solution? How open is our current solution really? Jenkins is, but our configuration isn't. I'd personally prefer to have open configuration of an open system. That being said, most of GitHub actions is open source. 3. Server capacity and concurrency. I think this could be a big advantage. We could also reach out to GitHub if we have any concurrency issues. 3. GitHub actions beyond CI. That's a very good point. Here is where I see the long term benefit for community. Automated code annotations, triage automation, welcome messages. You name it. I know that Heroku has a done a lot of work on automating compliance. I believe no one would mind, if we make the lives of our fellows a bit easier. Next steps: Since there seems to be a consensus to at least give it a try, I opened a ticket on track: https://code.djangoproject.com/ticket/30962#ticket It might make sense to have both systems run in parallel for a while to see how they compete. I'd like to get feedback from the fellows on that, since it's their daily life we are messing with. Tom I believe we don't need a separate fork, since GitHub actions are enabled on the Django GitHub orga. I can't wait to see where this goes! Best -Joe On Thursday, November 7, 2019 at 10:16:46 AM UTC+9, Tom Forbes wrote: > > 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 <matema...@gmail.com <javascript:>> > wrote: > > > > > On Wed, Nov 6, 2019 at 3:51 AM Carlton Gibson <carlto...@gmail.com > <javascript:>> 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-d...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/e509afbc-21ea-4b3b-9e23-18718594fa49%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/e509afbc-21ea-4b3b-9e23-18718594fa49%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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-d...@googlegroups.com <javascript:>. > 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 > > <https://groups.google.com/d/msgid/django-developers/CA%2BFDnh%2BTMwfRNTWQiK_gtFjJ-A4wTLsSofv_DV3hPgqcmU7D_g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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/bab35320-65c9-4170-9b1b-fc1472ba2c6b%40googlegroups.com.
