GitHub Actions

[Johannes Hoppe]

Hey there,

I saw that GitHub actions are already enabled for the Django organization.

Since general availability was announced starting Nov. 13. by GitHub, I wonder, should we use it?

I know we have a very complicated build setup, but maybe it makes sense to move some checks over to GitHub actions.

All the linters and docs build should be easy. Things like Oracle, might be a bit more difficult, but not impossible I guess.

Anyhow, I would be interested on your thoughts.

Cheers

-Joe

[Florian Apolloner]

Hi,

yes I had the same thought yesterday. I think trying with linters first should be an easy low hanging fruit (and to get a feeling for it). Tests in general might get a bit harder.

Cheers,

Florian

[Johannes Hoppe]

I would love to give Selenium a try. O god I hate it when selenium tests just randomly fail and I can't restart them.

I think the ability to just restart actions as a user is going to be a major improvement to the current workflow.

[Florian Apolloner]

I think Tom Forbes started working on it already, you might wanna sync up with him: https://github.com/orf/django-github-actions

[Tom Forbes]





Yep! My life has been unexpectedly busy the last few weeks so I’ve made no progress on it, but my idea is to prototype it in that repo before making a MR to Django itself. 

Starting with limiting would be easiest, but I actually don’t think it would be particularly hard to have the full suite running on actions.

There are a few open questions:

1. How do we support Oracle?

2. Can we (or do we want to?) unify it somehow with docker-box?

3. Will the standard github actions concurrency handle the number of builds we put through it in a reasonable time?

I’ve been experimenting with Github actions in a few repositories and I’m very impressed with their flexibility. It’s built to be much more than just a CI tool so if we wanted to automate anything about the repository we can do it with Actions: 

- workflow tags on merge requests, synchronized with Trac?

- messages to first time contributors, thanking them and giving them some advice on common issues new time contributors run into? (I really think we should do this)

- a comment with a link to the Django ticket if one is not already present?

- close MRs if the trac ticket is closed?

Side note: I’m also increasingly concerned about the lack of delivery on some Google groups messages. I had not been sent the first message from Johannes (it’s not in spam or any other place), and would have missed it if Felix has not replied. 

Tom

On 31 Oct 2019, at 09:49, Florian Apolloner <f.apo...@gmail.com> wrote:



--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/07a4594d-d2db-4ae2-a121-1d1bda3e649e%40googlegroups.com.

[Adam Johnson]

Nice, I've been playing with GitHub actions and I'm impressed. Will move my projects over from Travis at some point. Thanks for your work Tom

(Likewise on side note - I did not see Johannes' first message)

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/FE9D758A-F4EB-47A3-9964-FCDA36663387%40tomforb.es.

--

Adam

[Florian Apolloner]

On Thursday, October 31, 2019 at 11:08:49 AM UTC+1, Tom Forbes wrote:

1. How do we support Oracle?

For now we don't

2. Can we (or do we want to?) unify it somehow with docker-box?

If it makes sense yes, if it makes the actions horribly complex and it would be more action-like in another way, we maybe should split the two and just share settings files? All in all I'd like to use docker-box is feasible.

3. Will the standard github actions concurrency handle the number of builds we put through it in a reasonable time?

Good question, we can always ask for increases. But hence my idea of starting linting first, then maybe add sqlite tests and see how it goes

Cheers,

Florian

[Florian Apolloner]

On Thursday, October 31, 2019 at 2:33:29 PM UTC+1, Florian Apolloner wrote:

On Thursday, October 31, 2019 at 11:08:49 AM UTC+1, Tom Forbes wrote:

1. How do we support Oracle?

For now we don't

Ui, seems like we can start using our own runners: https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/ -- seems like github actions is becoming more and more a jenkins replacement :D

[Shai Berger]

On Tue, 5 Nov 2019 13:35:24 -0800 (PST)
Florian Apolloner <f.apo...@gmail.com> wrote:

>
> Ui, seems like we can start using our own runners:
> https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/
> -- seems like github actions is becoming more and more a jenkins
> replacement :D
>

Is there benefit enough in GitHub Actions (over Jenkins) to justify a
move from an open-source based solution?

[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

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

[Preeti Sharma]

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

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

[Preeti Sharma]

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

--

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

[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 <preeti...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMzw02X%2BqLKO6hKKh6bT0JzVBUubeO4AaW4o3YQAXnCpxcJvYw%40mail.gmail.com.

[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

[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!

[Matemática A3K]

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

[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 <matemat...@gmail.com> wrote:



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.

[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 <matema...@gmail.com> wrote:



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

[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

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/xDCmZPLTOQQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@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.

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



To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@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+unsubscribe@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 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/xDCmZPLTOQQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-developers+unsubscribe@googlegroups.com.

[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

[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

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a499aadf-1cd7-4000-b7a1-8ef4bca39364%40googlegroups.com.

[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 they have some good idea too.

Tom

On 7 Nov 2019, at 01:10, Matemática A3K <matema...@gmail.com> wrote:



On Wed, Nov 6, 2019 at 3:51 AM Carlton Gibson <carlto...@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+unsub...@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+unsub...@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 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/xDCmZPLTOQQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-developers+unsub...@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.

-- 
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+unsub...@googlegroups.com.

[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 <in...@johanneshoppe.com> 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.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@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-develop...@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 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/xDCmZPLTOQQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-develop...@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.

-- 
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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a499aadf-1cd7-4000-b7a1-8ef4bca39364%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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a3e81cca-e658-4b73-80ba-48fd92ef697c%40googlegroups.com.

[Matemática A3K]

On Thu, Nov 7, 2019 at 11:31 AM Johannes Hoppe <in...@johanneshoppe.com> 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.

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 they have some good idea too.

The plan sounds right to me, taking away the linting from Jenkins would alleviate a bit the overload on it and not hit the capacity limit.

As it seems that it will take some time to evaluate it, why don't we VC the Jenkins config in the meantime to help Mariusz?

 

Tom



To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@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-develop...@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 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/xDCmZPLTOQQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-develop...@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.

-- 
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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a499aadf-1cd7-4000-b7a1-8ef4bca39364%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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a3e81cca-e658-4b73-80ba-48fd92ef697c%40googlegroups.com.

[Johannes Hoppe]

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

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsub...@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+unsub...@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 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/xDCmZPLTOQQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-developers+unsub...@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.

-- 
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+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a499aadf-1cd7-4000-b7a1-8ef4bca39364%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-d...@googlegroups.com.

[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 <matemat...@gmail.com> wrote:

On Thu, Nov 7, 2019 at 11:31 AM Johannes Hoppe <in...@johanneshoppe.com> 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. 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 they have some good idea too.

The plan sounds right to me, taking away the linting from Jenkins would alleviate a bit the overload on it and not hit the capacity limit.

I slept a night on that. I believe we should run the actions back to back with the current config for a while and exclude it from any branch restrictions. Having it run back to back allows for a better comparison.

I would also not limit it to just the linters. If we have a config that works and that mirrors a current test run, we should deploy it to gain more experience.

If we name the workflow something like BETA or DO-IGNORE, it also won't cause too much confusion, to have two sets of tests. But on that I'd like to hear an opinion from our fellows.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhJ7xchX2%3DcEQVx4XCUTv_KcxMJrpyO_%2BQwhH3TrCt7vwQ%40mail.gmail.com.

[Matemática A3K]

Then why not use all the work already done in django-docker-box there? Then this would be "Run Django CI with Docker in the Azure cloud via Github Actions instead of Jenkins via the Jenkins-Github integration (plugin?)"

 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPcC2onP%2BKt0U0fr5w-U5ZnPq74PioDFD6xFnkzquAV%3DsyhoZA%40mail.gmail.com.

[Johannes Hoppe]

> Then why not use all the work already done in django-docker-box there? Then this would be "Run Django CI with Docker in the Azure cloud via Github Actions instead of Jenkins via the Jenkins-Github integration (plugin?)”

@Matematica that sounds promising is there a PR for that, that I have missed? I’d love to not reinvent the wheel :)

[Tom Forbes]

No there isn’t. Right now Docker-box is optimized for local development and exists outside of the main repository, and for now I’d suggest not trying to integrate it. That can be some future work though!

Regarding services vs apt, docker services is the only realistic way to do it. We cannot rely on all versions of every database we run to be packaged, installable and configurable in Ubuntu in a timely + simple manner, and it will quickly become a mess (different configurations between different versions for example). 

Just supplying a matrix of database versions that pull and start stock database images via “services” is simple and effective. This is basically how docker-box works. Postgis is annoying, but we publish a docker image as part of docker-box that we can use.

Tom

On 9 Nov 2019, at 08:40, Johannes Hoppe <in...@johanneshoppe.com> wrote:



--

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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fdcbfc00-977c-4587-a823-8e806cddf280%40Spark.

[Johannes Hoppe]

I have some really good news! I managed to almost map our entire Jenkins suite to GitHub actions, except Oracle.

Check out the output of the entire suite here.

And the config here: .github/workflows/ci.yml

Furthermore, I followed Tom’s great advice and switched everything to services. The execution time is perfectly fine.

The only exception is PostGIS, for the lack of an official container. It works good though, no an issue for me personally.

I would suggest to open a PR to GitHub now and to get the Fellows involved. Ask them how to best integrate a trial without disturbing their workflow. What do you guys think?

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/xDCmZPLTOQQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/17BD40A2-6A1B-4B44-8F49-11F2520F9898%40tomforb.es.

[Mariusz Felisiak]

I would suggest to open a PR to GitHub now and to get the Fellows involved. Ask them how to best integrate a trial without disturbing their workflow. What do you guys think?

I'm going to play with GitHub actions in this week (or in the next one) but I'm still not convinced. It's fine to use them for linters, but for more complicated jobs it generates output that is less readable, IMO. You don't get a formatted table but a raw output, so you have to scroll down ~20k lines to check what went wrong. This can be really frustrating especially with more then one failure. Nevertheless I'm going to play with it.

Best

Mariusz

[Johannes Hoppe]

Hi Mariusz,

Cool, let me know if you have any questions about the config file that I wrote. I am happy to help :)

Regarding the output, yes I can feel you. However I don’t know if we really need to run tests at verbosity level 2 on CI. One can always do that online or enable it if need be.

At list of tests that failed in a human readable output format would be nice. GitHub supports annotation on checks, but it's not really convenient yet to be used.

Using it for linters is a good start. We could also do the docs build and limit that one to be only build if the docs actually changed. You can trigger builds based on file condition, which is pretty neat.

Something that we also haven’t explored are scheduled builds. Those could be helpful to do regression tests on especially on dependencies.

Anyhow, love to see where this is going.

-Joe

--
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/xDCmZPLTOQQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6692d50f-b02d-4824-aa12-be22a20c3f0f%40googlegroups.com.

[Tom Forbes]

Sorry for bumping such an old thread, but I've created a github actions POC and written it up here: https://forum.djangoproject.com/t/improving-the-contribution-experience-with-github-actions/5964