Re: GitHub Actions

[Matemática A3K]

On Thu, Nov 7, 2019 at 11:31 AM Johannes Hoppe 
wrote:

> Hey Tom,
>
> Good to hear for you and very good points. I'll leave you a couple of
> inline comments:
>
> On Friday, November 8, 2019 at 1:04:50 AM UTC+9, Tom Forbes wrote:
>>
>> This is fantastic! Thank you Johannes! Regarding sqlite MacOS and Windows
>> tests, this is historical AFAIK (we don’t have the resources). With this we
>> should test MacOS and Windows as part of the Sqlite matrix (i.e all python
>> versions).
>>
>> A few notes:
>>
>> 1. We need to change the test runner output to be verbose when running
>> inside actions, as GitHub actions uses line buffered output.
>>
> Yes, 100%
>
>>
>> 2. We can’t run Oracle in actions for a number of reasons. We could
>> consider exposing the test database instance to Github actions via a proxy
>> or a whitelisted IP address, and we could implement the current “Buildbot,
>> test on oracle” command in GitHub actions pretty trivially.
>>
> You could use the official docker image, but it's going to be painfully
> slow.
>
>>
>> 3. We should have separate stages for Chrome and Firefox, but Firefox
>> should be set to allow failures for now. We can use the selenium hub
>> feature of the test runner in combination with the “services” actions
>> option to make this a bit simpler.
>>
> We currently use borwserhub on our CI system, if I am not mistaken. So
> using the headless version, was just a PoC. We should connect it to
> browserhub too I guess.
>

Browserhub == Browserstack == Selenium hub? If so, there should be the 3,
with Chrome and Firefox the main focus, and if some device fails in the
Selenium hub it wouldn't be a merge-blocker.


>
>> 4. Regarding the databases, I think the more correct way would be to use
>> a “service” rather than apt-installing it. See here for example:
>> https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml#L20-L30.
>> This would enable us to test the matrix of database versions, which is as
>> important as python versions IMO.
>>
> I am not sure if this is really the best move. I decided against
> "services" on other projects, mainly because of performance reasons. My
> current understanding is, that the containers are executed inside the
> virtual machine. Besides that you are stuck with stock images. In the case
> of Postgres, you will not get any extensions, like PostGIS.
> Then again, we should try and verify if any of my points are valid.
>

According to
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners,
you can run Docker containers besides the stock images


>
>> 5. Developers hate duplication, but I think a readable CI definition that
>> includes duplication is better than a de-duplicated one that’s a mess of
>> YAML anchors and special cases (see my attempts in docker-box!). I might
>> even suggest a separate actions file per test-group (linting/each
>> database/selenium).
>>
> Hm... I think I undestand where you want to go with this, but will having
> separate files really avoid duplication? Anyhow, a file has a meaning. It
> is a workflow. You can have multiple jobs in a workflow. Jobs can depend on
> one anohter, but only if they belong to the same workflow. So you can't
> build stages across workflows. Therefore, I would stick with a single file
> approach and wait until GitHub fully supports YAML.
> It's not that much duplication and steps cloud be bundled using another
> strategy, but I won't go for that just now.
>

Seems reasonable to me also, conditional and stages functionality is more
important in this case.


>
>> However for now I propose this as a course of action:
>>
>> 1. We add Flake8, isort and docs to the main Github repository (basically
>> this:
>> https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml#L1-L31).
>> I think this is good to go as-is and is low risk. We leave this running in
>> parallel with Jenkins for a period of time to evaluate it, and after that
>> we remove those Jenkins jobs entirely when we are happy.
>>
>
> Me likey!
>
>>
>> 2. We add SQLite tests one at a time: first Ubuntu, then Windows and
>> finally MacOS. We can experiment with these in separate repositories if
>> needed until we are happy with the configuration. After this we should
>> become comfortable with developing CI changes as merge requests, and should
>> not need separate repositories.
>>
> We can also use the Sqlite definitions as a template for future databases.
>> We also need to add specific test settings files to the repository, even
>> for SQlite which needs memcached configured (see django-docker-box for
>> examples).
>>
> MacOS fails right now. On my local machine too, we should really test
> aginst it. But it will require fixing some tests.
>
>>
>> 3. We add a full-matrix MariaDB build. This is our newest supported
>> database and there have been a few failures on master on specific untested
>> versions.
>>
> Ye

Re: GitHub Actions

[Johannes Hoppe]

Good idea Carlton, here you go 
https://code.djangoproject.com/ticket/30964#ticket

On Friday, November 8, 2019 at 3:03:58 AM UTC+9, Carlton Gibson wrote:
>
> Please open an issue for the macOS failure. It’s been passing for me all 
> week so... 🤔
>
> On Thu, 7 Nov 2019 at 17:31, Johannes Hoppe  > wrote:
>
>> Hey Tom,
>>
>> Good to hear for you and very good points. I'll leave you a couple of 
>> inline comments:
>>
>> On Friday, November 8, 2019 at 1:04:50 AM UTC+9, Tom Forbes wrote:
>>>
>>> This is fantastic! Thank you Johannes! Regarding sqlite MacOS and 
>>> Windows tests, this is historical AFAIK (we don’t have the resources). With 
>>> this we should test MacOS and Windows as part of the Sqlite matrix (i.e all 
>>> python versions).
>>>
>>> A few notes:
>>>
>>> 1. We need to change the test runner output to be verbose when running 
>>> inside actions, as GitHub actions uses line buffered output.
>>>
>> Yes, 100% 
>>
>>>
>>> 2. We can’t run Oracle in actions for a number of reasons. We could 
>>> consider exposing the test database instance to Github actions via a proxy 
>>> or a whitelisted IP address, and we could implement the current “Buildbot, 
>>> test on oracle” command in GitHub actions pretty trivially.
>>>
>> You could use the official docker image, but it's going to be painfully 
>> slow.
>>
>>>
>>> 3. We should have separat stages for Chrome and Firefox, but Firefox 
>>> should be set to allow failures for now. We can use the selenium hub 
>>> feature of the test runner in combination with the “services” actions 
>>> option to make this a bit simpler.
>>>
>> We currently use borwserhub on our CI system, if I am not mistaken. So 
>> using the headless version, was just a PoC. We should connect it to 
>> browserhub too I guess.
>>
>>>
>>> 4. Regarding the databases, I think the more correct way would be to use 
>>> a “service” rather than apt-installing it. See here for example: 
>>> https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml#L20-L30.
>>>  
>>> This would enable us to test the matrix of database versions, which is as 
>>> important as python versions IMO.
>>>
>> I am not sure if this is really the best move. I decided against 
>> "services" on other projects, mainly because of performance reasons. My 
>> current understanding is, that the containers are executed inside the 
>> virtual machine. Besides that you are stuck with stock images. In the case 
>> of Postgres, you will not get any extensions, like PostGIS. 
>> Then again, we should try and verify if any of my points are valid.
>>
>>>
>>> 5. Developers hate duplication, but I think a readable CI definition 
>>> that includes duplication is better than a de-duplicated one that’s a mess 
>>> of YAML anchors and special cases (see my attempts in docker-box!). I might 
>>> even suggest a separate actions file per test-group (linting/each 
>>> database/selenium).
>>>
>> Hm... I think I undestand where you want to go with this, but will having 
>> separate files really avoid duplication? Anyhow, a file has a meaning. It 
>> is a workflow. You can have multiple jobs in a workflow. Jobs can depend on 
>> one anohter, but only if they belong to the same workflow. So you can't 
>> build stages across workflows. Therefore, I would stick with a single file 
>> approach and wait until GitHub fully supports YAML.
>> It's not that much duplication and steps cloud be bundled using another 
>> strategy, but I won't go for that just now.
>>
>>>
>>> However for now I propose this as a course of action:
>>>
>>> 1. We add Flake8, isort and docs to the main Github repository 
>>> (basically this: 
>>> https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml#L1-L31).
>>>  
>>> I think this is good to go as-is and is low risk. We leave this running in 
>>> parallel with Jenkins for a period of time to evaluate it, and after that 
>>> we remove those Jenkins jobs entirely when we are happy.
>>>
>>
>> Me likey! 
>>
>>>
>>> 2. We add SQLite tests one at a time: first Ubuntu, then Windows and 
>>> finally MacOS. We can experiment with these in separate repositories if 
>>> needed until we are happy with the configuration. After this we should 
>>> become comfortable with developing CI changes as merge requests, and should 
>>> not need separate repositories. We can also use the Sqlite definitions as a 
>>> template for future databases. We also need to add specific test settings 
>>> files to the repository, even for SQlite which needs memcached configured 
>>> (see django-docker-box for examples).
>>>
>> MacOS fails right now. On my local machine too, we should really test 
>> aginst it. But it will require fixing some tests. 
>>
>>>
>>> 3. We add a full-matrix MariaDB build. This is our newest supported 
>>> database and there have been a few failures on master on specific untested 
>>> versions.
>>>
>> Yes, please I need a helping hand here. I'm a Postgres kind a guy. 
>>
>>>
>>> 4. We t

Re: GitHub Actions

[Johannes Hoppe]

@Tom, I stared to adapt some of your suggestions. Not done yet, I need to
wait for more log output from PostgeSQL to identify why it's stuck.

I'll put in more work later today (UTC+9). I'll also open up a pull-request
somewhere to allow line wise comments and suggestions.

@Matematica, good points, I added some comments inline.

On Fri, Nov 8, 2019, 09:42 Matemática A3K  wrote:

>
>
> On Thu, Nov 7, 2019 at 11:31 AM Johannes Hoppe 
> wrote:
>
>> Hey Tom,
>>
>> Good to hear for you and very good points. I'll leave you a couple of
>> inline comments:
>>
>> On Friday, November 8, 2019 at 1:04:50 AM UTC+9, Tom Forbes wrote:
>>>
>>> This is fantastic! Thank you Johannes! Regarding sqlite MacOS and
>>> Windows tests, this is historical AFAIK (we don’t have the resources). With
>>> this we should test MacOS and Windows as part of the Sqlite matrix (i.e all
>>> python versions).
>>>
>>> A few notes:
>>>
>>> 1. We need to change the test runner output to be verbose when running
>>> inside actions, as GitHub actions uses line buffered output.
>>>
>> Yes, 100%
>>
>>>
>>> 2. We can’t run Oracle in actions for a number of reasons. We could
>>> consider exposing the test database instance to Github actions via a proxy
>>> or a whitelisted IP address, and we could implement the current “Buildbot,
>>> test on oracle” command in GitHub actions pretty trivially.
>>>
>> You could use the official docker image, but it's going to be painfully
>> slow.
>>
>>>
>>> 3. We should have separate stages for Chrome and Firefox, but Firefox
>>> should be set to allow failures for now. We can use the selenium hub
>>> feature of the test runner in combination with the “services” actions
>>> option to make this a bit simpler.
>>>
>> We currently use borwserhub on our CI system, if I am not mistaken. So
>> using the headless version, was just a PoC. We should connect it to
>> browserhub too I guess.
>>
>
> Browserhub == Browserstack == Selenium hub? If so, there should be the 3,
> with Chrome and Firefox the main focus, and if some device fails in the
> Selenium hub it wouldn't be a merge-blocker.
>
I don't remember which one, but I don't want to toy with the current setup.
The headless once are good for a regular CI setup and could run on each PR,
since they are fast and more reliable.

I split them (in my sample branch) and disabled fast failing. So it's
easier to identify browser specific issues.

>
>
>>
>>> 4. Regarding the databases, I think the more correct way would be to use
>>> a “service” rather than apt-installing it. See here for example:
>>> https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml#L20-L30.
>>> This would enable us to test the matrix of database versions, which is as
>>> important as python versions IMO.
>>>
>> I am not sure if this is really the best move. I decided against
>> "services" on other projects, mainly because of performance reasons. My
>> current understanding is, that the containers are executed inside the
>> virtual machine. Besides that you are stuck with stock images. In the case
>> of Postgres, you will not get any extensions, like PostGIS.
>> Then again, we should try and verify if any of my points are valid.
>>
>
> According to
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners,
> you can run Docker containers besides the stock images
>
True, I missed that. Hm... We should definitely do a side by side. The
service config sure looks cleaner.

>
>
>>
>>> 5. Developers hate duplication, but I think a readable CI definition
>>> that includes duplication is better than a de-duplicated one that’s a mess
>>> of YAML anchors and special cases (see my attempts in docker-box!). I might
>>> even suggest a separate actions file per test-group (linting/each
>>> database/selenium).
>>>
>> Hm... I think I undestand where you want to go with this, but will having
>> separate files really avoid duplication? Anyhow, a file has a meaning. It
>> is a workflow. You can have multiple jobs in a workflow. Jobs can depend on
>> one anohter, but only if they belong to the same workflow. So you can't
>> build stages across workflows. Therefore, I would stick with a single file
>> approach and wait until GitHub fully supports YAML.
>> It's not that much duplication and steps cloud be bundled using another
>> strategy, but I won't go for that just now.
>>
>
> Seems reasonable to me also, conditional and stages functionality is more
> important in this case.
>
I agree, after some more thought, it also makes sense to me, to have a
single CI workflow. It also looks better, in terms of user feedback on
GitHub.

>
>
>>
>>> However for now I propose this as a course of action:
>>>
>>> 1. We add Flake8, isort and docs to the main Github repository
>>> (basically this:
>>> https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml#L1-L31).
>>> I think this is good to go as-is and is low risk. W

Re: Python version support for LTS Django (in particular v2.2)

[Johannes Hoppe]

I see. Well, I think I would be for supporting Python 3.8 in that case.
Maybe it makes sense to add Python nightly build tests to those braches to
make sure we catch issues early and it doesn't become an overwhelming task.

On Fri, Nov 1, 2019, 05:02 Jani Tiainen  wrote:

> Problem is that Python.org site always gives latest version as default
> download.
>
> When 3.8 was released one lib I work with suddenly got flood of help
> requests because there was not prebuilt packages for 3.8.
>
> So I think it's more issue for people that inadvertly upgrades Python.
>
> to 31. lokak. 2019 klo 11.39 Johannes Hoppe 
> kirjoitti:
>
>> I am trying to understand the motivation to use an "old" Django 2.2 but a
>> "bleading edge" Python version. I can understand Nicks logic of people
>> needing to upgrade form Python 2 to 3 and Debian by default gave them
>> Python 3.7.
>> Following that narrative, maybe we should check what the major operating
>> systems have in stall for us, right? Then again, there is not going to be a
>> big Python 2 to 3 change again *fingerscrossed*.
>>
>> --
>> 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/be847bcd-fff5-4672-8d1e-775d8fa7b429%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/SuOdHt2AWgs/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAHn91of%2B3oDEyb6cHcKtPG3gk61%3DucqpoRzUnPRpZ%2BS7ux2ZSg%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/CAPcC2ok%3DyJkTdwfn7OTsMUODA-Kzuz4G3xfuRWCrpP4ktL9WTw%40mail.gmail.com.

Re: Python version support for LTS Django (in particular v2.2)

[Mariusz Felisiak]

> I see. Well, I think I would be for supporting Python 3.8 in that case. 
> Maybe it makes sense to add Python nightly build tests to those braches to 
> make sure we catch issues early and it doesn't become an overwhelming task.
>

We have such jobs https://djangoci.com/view/Main/

-- 
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/42195e8e-a048-420a-a1d8-c700baa7bd83%40googlegroups.com.

Re: GitHub Actions

[Johannes Hoppe]

I put in a little effort and tried a couple of conceptual things.
1. YAML anchors, inheritance and includes are not yet supported by GitHub 
actions.
2. You can build dependent builds, or build stages, but you will need to 
keep everything in one file. (This gets messy without anchors & co).
3. You can give your jobs proper names and it works wonderful with a matrix 
too.
4. You can add lots of OS dependent steps (or other dependencies) to avoid 
duplication.
5. Fast failing is defined per job. So if a job inside a matrix fails, only 
runners in the same matrix will be killed. Further more, jobs that depend 
on this job will not be started. However, other will. (Very powerful stuff, 
love it.)

I put all my work and results into a branch. Here's what I implemented:
1. flake8, isort
2. sqlite3 all OSxPythonv versions
3. PostgreSQL
4. PostGIS
5. Selenium (headless) FF & Chrome (flaky as ever :/ )

Here is the config file:
https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml

The output is here:
https://github.com/codingjoe/django/commit/7a6fe4d7956caa6fb9a1ffe190310f48df031190/checks?check_suite_id=300072254

I use sphinx and libenchant on GH-actions in other projects, but I need to 
check out the sphinx is build in our current CI setup first.
I'll try to draft a solution for that too.

So far I am pretty happy. I haven't encountered anything that isn't 
possible yet. Concurrency is also great.
Regarding speed, I haven't looked much into caching yet, and I am not sure 
it's a big time saver, since Django doesn't have many dependencies.

On Thursday, November 7, 2019 at 1:44:00 PM UTC+9, Johannes Hoppe wrote:
>
> @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
>>
>

Re: GitHub Actions

[Johannes Hoppe]

Ok, I have one more insight.

I added all databases (except Oracle) and altered the job matrix to reflect 
the current setup (why don't we test on macOS again?)
Results can be found here: 
https://github.com/codingjoe/django/commit/386f5eb04dc0ae9424bcb1e1198ed7752cd9c10c/checks?check_suite_id=300325315

My main observations:
1. PostgreSQL is still running after 1.5h
2. I have no clue about MySQL or MariaDB

Since PostgreSQL is sill running I looked into the machine size that is 
used for the GitHub hosted runners. They use Azure's Standard_DS2_v2 
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-general#dsv2-series

I believe if we are to run Oracle (or PostgreSQL for that matter) we might 
need to use our own action runners. However, if we ask Microsoft very, very 
nicely, maybe they will sponsor some bigger machines for us ;)

BTW, PostgreSQL is running for almost 2h now. I wonder if I could run a 
major web service of a GitHub action :P

On Thursday, November 7, 2019 at 8:15:43 PM UTC+9, Johannes Hoppe wrote:
>
> I put in a little effort and tried a couple of conceptual things.
> 1. YAML anchors, inheritance and includes are not yet supported by GitHub 
> actions.
> 2. You can build dependent builds, or build stages, but you will need to 
> keep everything in one file. (This gets messy without anchors & co).
> 3. You can give your jobs proper names and it works wonderful with a 
> matrix too.
> 4. You can add lots of OS dependent steps (or other dependencies) to avoid 
> duplication.
> 5. Fast failing is defined per job. So if a job inside a matrix fails, 
> only runners in the same matrix will be killed. Further more, jobs that 
> depend on this job will not be started. However, other will. (Very powerful 
> stuff, love it.)
>
> I put all my work and results into a branch. Here's what I implemented:
> 1. flake8, isort
> 2. sqlite3 all OSxPythonv versions
> 3. PostgreSQL
> 4. PostGIS
> 5. Selenium (headless) FF & Chrome (flaky as ever :/ )
>
> Here is the config file:
>
> https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml
>
> The output is here:
>
> https://github.com/codingjoe/django/commit/7a6fe4d7956caa6fb9a1ffe190310f48df031190/checks?check_suite_id=300072254
>
> I use sphinx and libenchant on GH-actions in other projects, but I need to 
> check out the sphinx is build in our current CI setup first.
> I'll try to draft a solution for that too.
>
> So far I am pretty happy. I haven't encountered anything that isn't 
> possible yet. Concurrency is also great.
> Regarding speed, I haven't looked much into caching yet, and I am not sure 
> it's a big time saver, since Django doesn't have many dependencies.
>
> On Thursday, November 7, 2019 at 1:44:00 PM UTC+9, Johannes Hoppe wrote:
>>
>> @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

Re: GitHub Actions

[Tom Forbes]

This is fantastic! Thank you Johannes! Regarding sqlite MacOS and Windows 
tests, this is historical AFAIK (we don’t have the resources). With this we 
should test MacOS and Windows as part of the Sqlite matrix (i.e all python 
versions).

A few notes:

1. We need to change the test runner output to be verbose when running inside 
actions, as GitHub actions uses line buffered output.

2. We can’t run Oracle in actions for a number of reasons. We could consider 
exposing the test database instance to Github actions via a proxy or a 
whitelisted IP address, and we could implement the current “Buildbot, test on 
oracle” command in GitHub actions pretty trivially.

3. We should have separate stages for Chrome and Firefox, but Firefox should be 
set to allow failures for now. We can use the selenium hub feature of the test 
runner in combination with the “services” actions option to make this a bit 
simpler.

4. Regarding the databases, I think the more correct way would be to use a 
“service” rather than apt-installing it. See here for example: 
https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml#L20-L30
 
.
 This would enable us to test the matrix of database versions, which is as 
important as python versions IMO.

5. Developers hate duplication, but I think a readable CI definition that 
includes duplication is better than a de-duplicated one that’s a mess of YAML 
anchors and special cases (see my attempts in docker-box!). I might even 
suggest a separate actions file per test-group (linting/each database/selenium).

However for now I propose this as a course of action:

1. We add Flake8, isort and docs to the main Github repository (basically this: 
https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml#L1-L31
 
).
 I think this is good to go as-is and is low risk. We leave this running in 
parallel with Jenkins for a period of time to evaluate it, and after that we 
remove those Jenkins jobs entirely when we are happy.

2. We add SQLite tests one at a time: first Ubuntu, then Windows and finally 
MacOS. We can experiment with these in separate repositories if needed until we 
are happy with the configuration. After this we should become comfortable with 
developing CI changes as merge requests, and should not need separate 
repositories. We can also use the Sqlite definitions as a template for future 
databases. We also need to add specific test settings files to the repository, 
even for SQlite which needs memcached configured (see django-docker-box for 
examples).

3. We add a full-matrix MariaDB build. This is our newest supported database 
and there have been a few failures on master on specific untested versions.

4. We then add each database individually in a similar fashion, and think about 
Oracle right at the end.

If this plan sounds reasonable then let's create some smaller tickets. IMO the 
exact specifics of how the database tests will look is still fuzzy, but for the 
linting it’s perfectly clear. However if anyone is not happy with actions in 
the main repository then let's keep discussing.

Tom


> On 7 Nov 2019, at 15:33, Johannes Hoppe  wrote:
> 
> Ok, I have one more insight.
> 
> I added all databases (except Oracle) and altered the job matrix to reflect 
> the current setup (why don't we test on macOS again?)
> Results can be found here: 
> https://github.com/codingjoe/django/commit/386f5eb04dc0ae9424bcb1e1198ed7752cd9c10c/checks?check_suite_id=300325315
>  
> 
> 
> My main observations:
> 1. PostgreSQL is still running after 1.5h
> 2. I have no clue about MySQL or MariaDB
> 
> Since PostgreSQL is sill running I looked into the machine size that is used 
> for the GitHub hosted runners. They use Azure's Standard_DS2_v2 
> https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-general#dsv2-series
>  
> 
> 
> I believe if we are to run Oracle (or PostgreSQL for that matter) we might 
> need to use our own action runners. However, if we ask Microsoft very, very 
> nicely, maybe they will sponsor some bigger machines for us ;)
> 
> BTW, PostgreSQL is running for almost 2h now. I wonder if I could run a major 
> web service of a GitHub action :P
> 
> On Thursday, November 7, 2019 at 8:15:43 PM UTC+9, Johannes Hoppe wrote:
> I put in a little effort and tried a couple of conceptual things.
> 1. YAML anchors, inheritance and includes are not yet supported by GitHub 
> actions.
> 2. You can build dependent builds, or build stages, but you will need to keep 
> everything in one file. (This gets messy without anchors & co

Re: GitHub Actions

[Johannes Hoppe]

Hey Tom,

Good to hear for you and very good points. I'll leave you a couple of 
inline comments:

On Friday, November 8, 2019 at 1:04:50 AM UTC+9, Tom Forbes wrote:
>
> This is fantastic! Thank you Johannes! Regarding sqlite MacOS and Windows 
> tests, this is historical AFAIK (we don’t have the resources). With this we 
> should test MacOS and Windows as part of the Sqlite matrix (i.e all python 
> versions).
>
> A few notes:
>
> 1. We need to change the test runner output to be verbose when running 
> inside actions, as GitHub actions uses line buffered output.
>
Yes, 100% 

>
> 2. We can’t run Oracle in actions for a number of reasons. We could 
> consider exposing the test database instance to Github actions via a proxy 
> or a whitelisted IP address, and we could implement the current “Buildbot, 
> test on oracle” command in GitHub actions pretty trivially.
>
You could use the official docker image, but it's going to be painfully 
slow.

>
> 3. We should have separate stages for Chrome and Firefox, but Firefox 
> should be set to allow failures for now. We can use the selenium hub 
> feature of the test runner in combination with the “services” actions 
> option to make this a bit simpler.
>
We currently use borwserhub on our CI system, if I am not mistaken. So 
using the headless version, was just a PoC. We should connect it to 
browserhub too I guess.

>
> 4. Regarding the databases, I think the more correct way would be to use a 
> “service” rather than apt-installing it. See here for example: 
> https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml#L20-L30.
>  
> This would enable us to test the matrix of database versions, which is as 
> important as python versions IMO.
>
I am not sure if this is really the best move. I decided against "services" 
on other projects, mainly because of performance reasons. My current 
understanding is, that the containers are executed inside the virtual 
machine. Besides that you are stuck with stock images. In the case of 
Postgres, you will not get any extensions, like PostGIS. 
Then again, we should try and verify if any of my points are valid.

>
> 5. Developers hate duplication, but I think a readable CI definition that 
> includes duplication is better than a de-duplicated one that’s a mess of 
> YAML anchors and special cases (see my attempts in docker-box!). I might 
> even suggest a separate actions file per test-group (linting/each 
> database/selenium).
>
Hm... I think I undestand where you want to go with this, but will having 
separate files really avoid duplication? Anyhow, a file has a meaning. It 
is a workflow. You can have multiple jobs in a workflow. Jobs can depend on 
one anohter, but only if they belong to the same workflow. So you can't 
build stages across workflows. Therefore, I would stick with a single file 
approach and wait until GitHub fully supports YAML.
It's not that much duplication and steps cloud be bundled using another 
strategy, but I won't go for that just now.

>
> However for now I propose this as a course of action:
>
> 1. We add Flake8, isort and docs to the main Github repository (basically 
> this: 
> https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml#L1-L31).
>  
> I think this is good to go as-is and is low risk. We leave this running in 
> parallel with Jenkins for a period of time to evaluate it, and after that 
> we remove those Jenkins jobs entirely when we are happy.
>

Me likey! 

>
> 2. We add SQLite tests one at a time: first Ubuntu, then Windows and 
> finally MacOS. We can experiment with these in separate repositories if 
> needed until we are happy with the configuration. After this we should 
> become comfortable with developing CI changes as merge requests, and should 
> not need separate repositories. We can also use the Sqlite definitions as a 
> template for future databases. We also need to add specific test settings 
> files to the repository, even for SQlite which needs memcached configured 
> (see django-docker-box for examples).
>
MacOS fails right now. On my local machine too, we should really test 
aginst it. But it will require fixing some tests. 

>
> 3. We add a full-matrix MariaDB build. This is our newest supported 
> database and there have been a few failures on master on specific untested 
> versions.
>
Yes, please I need a helping hand here. I'm a Postgres kind a guy. 

>
> 4. We then add each database individually in a similar fashion, and think 
> about Oracle right at the end. 
>
Poor Oracle, but I absolutely agree.

>  
>

> If this plan sounds reasonable then let's create some smaller tickets. IMO 
> the exact specifics of how the database tests will look is still fuzzy, but 
> for the linting it’s perfectly clear. However if anyone is not happy with 
> actions in the main repository then let's keep discussing.
>
It does, but let's wait just a bit longer. I'd like others to evaluate the 
new insides. I'm sure t

Re: GitHub Actions

[Carlton Gibson]

Please open an issue for the macOS failure. It’s been passing for me all
week so... 🤔

On Thu, 7 Nov 2019 at 17:31, Johannes Hoppe  wrote:

> Hey Tom,
>
> Good to hear for you and very good points. I'll leave you a couple of
> inline comments:
>
> On Friday, November 8, 2019 at 1:04:50 AM UTC+9, Tom Forbes wrote:
>>
>> This is fantastic! Thank you Johannes! Regarding sqlite MacOS and Windows
>> tests, this is historical AFAIK (we don’t have the resources). With this we
>> should test MacOS and Windows as part of the Sqlite matrix (i.e all python
>> versions).
>>
>> A few notes:
>>
>> 1. We need to change the test runner output to be verbose when running
>> inside actions, as GitHub actions uses line buffered output.
>>
> Yes, 100%
>
>>
>> 2. We can’t run Oracle in actions for a number of reasons. We could
>> consider exposing the test database instance to Github actions via a proxy
>> or a whitelisted IP address, and we could implement the current “Buildbot,
>> test on oracle” command in GitHub actions pretty trivially.
>>
> You could use the official docker image, but it's going to be painfully
> slow.
>
>>
>> 3. We should have separat stages for Chrome and Firefox, but Firefox
>> should be set to allow failures for now. We can use the selenium hub
>> feature of the test runner in combination with the “services” actions
>> option to make this a bit simpler.
>>
> We currently use borwserhub on our CI system, if I am not mistaken. So
> using the headless version, was just a PoC. We should connect it to
> browserhub too I guess.
>
>>
>> 4. Regarding the databases, I think the more correct way would be to use
>> a “service” rather than apt-installing it. See here for example:
>> https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml#L20-L30.
>> This would enable us to test the matrix of database versions, which is as
>> important as python versions IMO.
>>
> I am not sure if this is really the best move. I decided against
> "services" on other projects, mainly because of performance reasons. My
> current understanding is, that the containers are executed inside the
> virtual machine. Besides that you are stuck with stock images. In the case
> of Postgres, you will not get any extensions, like PostGIS.
> Then again, we should try and verify if any of my points are valid.
>
>>
>> 5. Developers hate duplication, but I think a readable CI definition that
>> includes duplication is better than a de-duplicated one that’s a mess of
>> YAML anchors and special cases (see my attempts in docker-box!). I might
>> even suggest a separate actions file per test-group (linting/each
>> database/selenium).
>>
> Hm... I think I undestand where you want to go with this, but will having
> separate files really avoid duplication? Anyhow, a file has a meaning. It
> is a workflow. You can have multiple jobs in a workflow. Jobs can depend on
> one anohter, but only if they belong to the same workflow. So you can't
> build stages across workflows. Therefore, I would stick with a single file
> approach and wait until GitHub fully supports YAML.
> It's not that much duplication and steps cloud be bundled using another
> strategy, but I won't go for that just now.
>
>>
>> However for now I propose this as a course of action:
>>
>> 1. We add Flake8, isort and docs to the main Github repository (basically
>> this:
>> https://github.com/codingjoe/django/blob/30962/flake8/.github/workflows/ci.yml#L1-L31).
>> I think this is good to go as-is and is low risk. We leave this running in
>> parallel with Jenkins for a period of time to evaluate it, and after that
>> we remove those Jenkins jobs entirely when we are happy.
>>
>
> Me likey!
>
>>
>> 2. We add SQLite tests one at a time: first Ubuntu, then Windows and
>> finally MacOS. We can experiment with these in separate repositories if
>> needed until we are happy with the configuration. After this we should
>> become comfortable with developing CI changes as merge requests, and should
>> not need separate repositories. We can also use the Sqlite definitions as a
>> template for future databases. We also need to add specific test settings
>> files to the repository, even for SQlite which needs memcached configured
>> (see django-docker-box for examples).
>>
> MacOS fails right now. On my local machine too, we should really test
> aginst it. But it will require fixing some tests.
>
>>
>> 3. We add a full-matrix MariaDB build. This is our newest supported
>> database and there have been a few failures on master on specific untested
>> versions.
>>
> Yes, please I need a helping hand here. I'm a Postgres kind a guy.
>
>>
>> 4. We then add each database individually in a similar fashion, and think
>> about Oracle right at the end.
>>
> Poor Oracle, but I absolutely agree.
>
>>
>>
>
>> If this plan sounds reasonable then let's create some smaller tickets.
>> IMO the exact specifics of how the database tests will look is still fuzzy,
>> but for the linting it’s