Re: GitHub Actions

[Carlton Gibson]

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

-- 
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.

Re: GitHub Actions

[Florian Apolloner]

On Wednesday, November 6, 2019 at 8:43:21 AM UTC+1, Shai Berger wrote:
>
> Is there benefit enough in GitHub Actions (over Jenkins) to justify a 
> move from an open-source based solution? 
>

Yes, less server costs (even if sponsored). Less things to maintain for us 
(Jenkins is a beast). Better and more reliable integration with github. 

-- 
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/d34795bc-7490-43b0-bdcb-8a3023939c9b%40googlegroups.com.

Re: GitHub Actions

[Preeti Sharma]

Can we use pythongui library for that and then use selenium for testing .

On Wed 6 Nov, 2019, 2:21 PM Carlton Gibson, 
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
>
> --
> 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/CAMzw02VN8jt1BLB%2B-pSmcM6YQ%2BdKhTE7aA%3D5tj09fQZds1P9GQ%40mail.gmail.com.

Re: GitHub Actions

[Preeti Sharma]

Right, but there has to be some changes done i think.

On Wed 6 Nov, 2019, 6:05 PM Florian Apolloner, 
wrote:

>
>
> On Wednesday, November 6, 2019 at 8:43:21 AM UTC+1, Shai Berger wrote:
>>
>> Is there benefit enough in GitHub Actions (over Jenkins) to justify a
>> move from an open-source based solution?
>>
>
> Yes, less server costs (even if sponsored). Less things to maintain for us
> (Jenkins is a beast). Better and more reliable integration with github.
>
> --
> 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/d34795bc-7490-43b0-bdcb-8a3023939c9b%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/CAMzw02X%2BqLKO6hKKh6bT0JzVBUubeO4AaW4o3YQAXnCpxcJvYw%40mail.gmail.com.

Re: GitHub Actions

[Tom Forbes]

Yes there will be. Now Github has added caching I think we are good to go.

I will send a link here with the longer running on my fork and we can look at 
starting there. Once (if?) that’s merged then we can enable the “allow forks to 
run actions” option and we can iteratively add more tests as merge requests.

Regarding Jenkins: it’s a beast that’s often unreliable. We save on effort 
there, get a more reliable CI tool and have our CI files versioned alongside 
our code.

 I’m not sure open vs closed source comes into play here, and it should be 
mentioned that Github actions (the steps and the runner) is almost completely 
open source. And believe me when I say the source is a lot easier to 
follow/debug than the reams of often incomprehensible code a Jenkins plugin 
typically has!

Tom

> On 6 Nov 2019, at 12:56, Preeti Sharma  wrote:
> 
> 
> Right, but there has to be some changes done i think.
> 
>> On Wed 6 Nov, 2019, 6:05 PM Florian Apolloner,  wrote:
>> 
>> 
>>> On Wednesday, November 6, 2019 at 8:43:21 AM UTC+1, Shai Berger wrote:
>>> Is there benefit enough in GitHub Actions (over Jenkins) to justify a 
>>> move from an open-source based solution? 
>> 
>> Yes, less server costs (even if sponsored). Less things to maintain for us 
>> (Jenkins is a beast). Better and more reliable integration with github. 
>> -- 
>> 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/d34795bc-7490-43b0-bdcb-8a3023939c9b%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/CAMzw02X%2BqLKO6hKKh6bT0JzVBUubeO4AaW4o3YQAXnCpxcJvYw%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/1C0ECC83-D6F9-4F7E-8B00-A6A00C783DC1%40tomforb.es.

Re: GitHub Actions

[Tom Forbes]

Here it is: 
https://github.com/orf/django-github-actions/tree/master/.github/workflows 


There are two actions I’ve added here: a lint step and a matrix of sqlite tests 
(Windows, MacOS and Ubuntu * py36 and py37). It’s all vanilla Django on the 
latest master, however I did remove the pylibmc dependency for now as that’s 
slightly tricky to include (and there are no 3.8 wheels available).

I’ve got four example PR’s for you:

1. Linting failures: https://github.com/orf/django-github-actions/pull/1 

2. A failing test: https://github.com/orf/django-github-actions/pull/2 

3. Nothing failing: https://github.com/orf/django-github-actions/pull/3 

4. Modifying the CI to test on Python 3.8: 
https://github.com/orf/django-github-actions/pull/4 


I’ve had some experience with actions but all this took me about half an hour 
(on very poor airport WiFi). It’s really simple and really effective. The devil 
is obviously in the details but based on my work with docker-box we can make 
good progress with our test matrix really fast. And we can do it step-by-step.

The usage limits are documented here: 
https://help.github.com/en/github/automating-your-workflow-with-github-actions/about-github-actions#usage-limits
 
.
 I’m not sure how they apply to organisations (maybe just “free”?), but I think 
Github would allow us an increased limit.

What do we think?

Tom


> On 6 Nov 2019, at 13:58, Tom Forbes  wrote:
> 
> Yes there will be. Now Github has added caching I think we are good to go.
> 
> I will send a link here with the longer running on my fork and we can look at 
> starting there. Once (if?) that’s merged then we can enable the “allow forks 
> to run actions” option and we can iteratively add more tests as merge 
> requests.
> 
> Regarding Jenkins: it’s a beast that’s often unreliable. We save on effort 
> there, get a more reliable CI tool and have our CI files versioned alongside 
> our code.
> 
>  I’m not sure open vs closed source comes into play here, and it should be 
> mentioned that Github actions (the steps and the runner) is almost completely 
> open source. And believe me when I say the source is a lot easier to 
> follow/debug than the reams of often incomprehensible code a Jenkins plugin 
> typically has!
> 
> Tom
> 
>> On 6 Nov 2019, at 12:56, Preeti Sharma  wrote:
>> 
>> 
>> Right, but there has to be some changes done i think.
>> 
>> On Wed 6 Nov, 2019, 6:05 PM Florian Apolloner, > > wrote:
>> 
>> 
>> On Wednesday, November 6, 2019 at 8:43:21 AM UTC+1, Shai Berger wrote:
>> Is there benefit enough in GitHub Actions (over Jenkins) to justify a 
>> move from an open-source based solution? 
>> 
>> Yes, less server costs (even if sponsored). Less things to maintain for us 
>> (Jenkins is a beast). Better and more reliable integration with github. 
>> 
>> -- 
>> 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/d34795bc-7490-43b0-bdcb-8a3023939c9b%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/CAMzw02X%2BqLKO6hKKh6bT0JzVBUubeO4AaW4o3YQAXnCpxcJvYw%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/1BB1752C-4408-4B8F-9A3B-E7B502FA6E19%40tom

Re: GitHub Actions

[Florian Apolloner]

On Wednesday, November 6, 2019 at 4:48:11 PM UTC+1, Tom Forbes wrote:
>
> The usage limits are documented here: 
> https://help.github.com/en/github/automating-your-workflow-with-github-actions/about-github-actions#usage-limits.
>  
> I’m not sure how they apply to organisations (maybe just “free”?), but I 
> think Github would allow us an increased limit.
>

If not we can still work towards using our own workers, we have the 
capacity for it. 
 

> What do we think?
>

Fantastic! 

-- 
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/9e728efd-a8ca-4cdf-98e0-b99dc91c83c9%40googlegroups.com.

Re: GitHub Actions

[Matemática A3K]

On Wed, Nov 6, 2019 at 3:51 AM Carlton Gibson 
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.

Re: GitHub Actions

[Tom Forbes]

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  wrote:
> 
> 
> 
> 
>> On Wed, Nov 6, 2019 at 3:51 AM Carlton Gibson  
>> 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 vi

Re: GitHub Actions

[Johannes Hoppe]

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 > 
> wrote:
>
> 
>
>
> On Wed, Nov 6, 2019 at 3:51 AM Carlton Gibson  > 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 sam

Re: GitHub Actions

[Johannes Hoppe]

@Florian, dependent builds or build stages are possible, seealso: 
https://github.com/codingjoe/django/commit/eeefc83a85ba5e91b98c4e29fb9b20896612cc8c/checks?check_suite_id=299641652

--
Johannes Hoppe

www.johanneshoppe.com

Want to chat? Let's get a coffee!
https://calendly.com/codingjoe/call

Lennéstr. 19
14469 Potsdam

USt-IdNr.: DE284754038
On 7. Nov 2019, 10:16 +0900, 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  wrote:
> >
> >
> >
> > > On Wed, Nov 6, 2019 at 3:51 AM Carlton Gibson  
> > > 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 m