Build failing on master due to isort issues
Closed this issue · 5 comments
This repository is currently marked "build: failing" because commit f4806f3 broke the CI regarding isort: https://travis-ci.org/philipn/django-rest-framework-filters/jobs/503911313#L237
Would be cool to be fixed. I can provide a pull request if needed
Thanks for the report. It looks like this was an issue with isort that has since been fixed. I was wrong - forgot that I had fixed this in #297.
If not from isort, master is red again on CI side though. I suggest to let more things go through pull requests so that CI can have a say about them before hitting master, rather than pushing to master directly this much.
If not from isort, master is red again on CI side though.
There was a separate bug in the tox.ini that triggered when Django 2.2 was released. Fixed in #300.
rather than pushing to master directly this much.
If you look at the commit history, you'll see that I almost always use PRs. What's happening here is kind of interesting - it's a weird interaction between Travis's commit statuses and Travis's cron builds. Basically, the PR succeeds, but then something down the road changes and cron builds start failing. The latest commit is now marked as having failed, even though it passed at the time. This gives the impression that failing PRs were merged, which isn't the case.
You can see this with #297. If you view the details for the PR, you'll see that CI succeeded. However, the commit log shows a build failure. Opening that, you'll notice that it's a cron build from ~6 days ago, not the original build from back in March.
Interesting!
Error sqlite3.OperationalError: no such table: auth_user might have to do with use of AUTH_USER_MODEL without setting its value anywhere and without creating its tables in https://github.com/philipn/django-rest-framework-filters/blob/master/tests/testapp/migrations/0001_initial.py , just a guess.
Yep - that was the issue. The reason the test suite started failing was due to bad version specifiers. All of the 2.x builds were running against Django 2.2 (released in April), instead of their respective 2.0 and 2.1 builds.