Skip to content

Add CI test pipeline and Elasticsearch 7 setup with uv - #291

Merged
ulgens merged 3 commits into
ulgens:mainfrom
DhavalGojiya:feat/es-test-setup
Jul 21, 2026
Merged

Add CI test pipeline and Elasticsearch 7 setup with uv#291
ulgens merged 3 commits into
ulgens:mainfrom
DhavalGojiya:feat/es-test-setup

Conversation

@DhavalGojiya

@DhavalGojiya DhavalGojiya commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Description

Closes Issues: #249
Closes PR's: #226 and #189

Added support for Elasticsearch 7 in the package.
django-haystack supports up to Elasticsearch 7 version.

Other older Elasticsearch versions <7 have reached EOL (End of Life): see.

Summary

  • Removed obsolete test cases related to Django REST Framework versions below 3.7.
  • Removed tox.ini (super slow / unnecessary complexity)
  • Updated the test suite for Elasticsearch 7 compatibility.
  • Add uv support to manage workflows and project.
  • Added support for Python 3.8+ and the latest Python releases.
  • Removed Dockerfile (We are not using it, docker compose file did the every work)

Tests

  1. Docker setup
image

@DhavalGojiya

Copy link
Copy Markdown
Contributor Author

@ulgens
Finally, we did it
but it was so frustrating and difficult to get everything working properly. 🤧

@ulgens

ulgens commented Jun 12, 2026

Copy link
Copy Markdown
Owner

Congrats and thank you so much!

I can't promise an immediate review but I'll check it bit by bit when I have the time.

Comment thread .github/workflows/ci.yml Outdated
Comment thread .github/workflows/ci.yml Outdated
matrix:
django-version: ["4.2.*"]
python-version: ["3.8", "3.9", "3.10", "3.11", "3.12", "3.13", "3.14", "3.14t"]
elastic-version: ["7.17.29"]

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we plan to broaden the elastic entry? How many majors - minors elastic have supported at a given time?

@DhavalGojiya DhavalGojiya Jun 13, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

django-haystack (Primary dependency of this package) doesn't support Elasticsearch 8 or 9 yet.

All earlier Elasticsearch versions are already EOL. Elasticsearch 7 is also EOL, but it only reached EOL about four months ago, so it probably makes sense to keep testing against Elasticsearch 7 for now.

If django-haystack adds support for Elasticsearch 8 or 9 in the future, we can expand the test matrix accordingly.
More info here: https://endoflife.date/elasticsearch

Comment thread .github/workflows/ci.yml Outdated
Comment thread .github/workflows/ci.yml Outdated
fail-fast: false
matrix:
django-version: ["4.2.*"]
python-version: ["3.8", "3.9", "3.10", "3.11", "3.12", "3.13", "3.14", "3.14t"]

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4.2 doesn't support > Python 3.12 https://docs.djangoproject.com/en/4.2/faq/install/

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done :)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a new comment.

Comment thread pyproject.toml
{ name = "Rolf Håvard Blindheim", email = "rhblind@gmail.com" },
{ name = "Ülgen Sarıkavak", email = "foss@ulgenwanders.net" },
]
requires-python = ">=3.8,<3.11"

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't remove the upper limit. The project doesn't support all existing Python versions and not in a state that it can be installed with a new Python version when it's released.

@DhavalGojiya DhavalGojiya Jun 13, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get this.
Also, how do we know which Python versions this project supports and which it doesn't, other than relying on the test case results?

The test cases pass for all available Python versions.

According to you, what upper limit can we set? Just < 3.11?

Maybe we can use < 3.15?

Currently, there are 7 client projects in our company using this drf-haystack package. Our 8th and 9th projects use Django 5.2, and because of the Django constraints of this package, we can't use drf-haystack in those projects.

We just copy the whole drf-haystack folder and use it as a normal Django app in the new projects that use Django 5.2 with Python 3.13 and everything working fine.

@ulgens ulgens Jun 13, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, how do we know which Python versions this project supports and which it doesn't, other than relying on the test case results?

Yep. Just match the tested versions.

The project may work fine for a particular setup, that's nice, but that doesn't translate to "it works" yet. Please keep the support delegations limited to the tested versions for now.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go 🤞

@ulgens

ulgens commented Jun 13, 2026

Copy link
Copy Markdown
Owner

Merged

The branch will need a rebase - sorry.

Comment thread pyproject.toml
@DhavalGojiya

Copy link
Copy Markdown
Contributor Author

@ulgens
Also, can we just drop Python 3.8 and Python 3.9 support?

As you can see, in the Python 3.8 job matrix, the build backend is causing issues with some license key definition error.

I think it's more overhead and extra work that we're currently dealing with without any real benefit.
For now, we should not focus on supporting older Python versions.

@ulgens

ulgens commented Jun 13, 2026

Copy link
Copy Markdown
Owner

Dropping 3.8 - 3.9 sounds tempting but if we do that, we will have 0 backward compatibility with the next version, which I think we should fallback to as the very last resort.

The CI failure looks like an issue with uv - pyproject and I don't expect it to a require a complex solution.

@DhavalGojiya
DhavalGojiya requested a review from ulgens June 14, 2026 14:35
Comment thread .github/workflows/ci.yml Outdated
Comment thread setup.py
Comment thread tests/settings.py

BASE_DIR = Path(__file__).parent.resolve()

SECRET_KEY = "NOBODY expects the Spanish Inquisition!"

@ulgens ulgens Jun 14, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To keep the diff smaller and easy to review, please don't include things that are not directly in the scope defined by the commit message. Same goes for DEFAULT_AUTO_FIELD and MIDDLEWARE_CLASSES changes. If they are needed for the PR, a separate commit with the explanation would be nice.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The correct Django settings variable name is MIDDLEWARE, not MIDDLEWARE_CLASSES.

The Django Auto Field setting is used to silence the many warnings related to auto-created primary keys that appear when running runserver or executing test cases.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done :)

  • Added a new commit with a proper message explaining the middleware-related changes.
  • Reverted the secret key and Django Auto Field settings for now. will cover those changes in a separate PR.

Comment thread tests/test_filters.py
Comment on lines +36 to +48
def gdal_is_available():
"""
Return True if GDAL is installed.

We can't import Point without the GDAL/GEOS libraries, so we just try it
and treat any failure as "not available". Used to skip the geo tests on
machines that don't have GDAL.
"""
try:
from django.contrib.gis.geos import Point # noqa: F401
except ImproperlyConfigured:
return False
return True

@ulgens ulgens Jun 14, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did the old helper/utility have any issues?

@DhavalGojiya DhavalGojiya Jun 14, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old init code are unnecessary and complex also not optimized along with some Django REST Framework if/else logic and Elasticsearch version extraction.

Also, the message says that the GOES library needs to be installed, but it actually requires GDAL, and GOES is installed automatically as a dependency of GDAL.

@DhavalGojiya
DhavalGojiya requested a review from ulgens June 14, 2026 19:27
@DhavalGojiya

Copy link
Copy Markdown
Contributor Author

@ulgens

I think everything is clear now. 🫡

@DhavalGojiya

Copy link
Copy Markdown
Contributor Author

New change:
Add --quite-pull flag to Docker es setup to reduce the big image chunk download output in terminal.

docker-es-quite

@ulgens
ulgens merged commit 81e79b7 into ulgens:main Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants