Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

safety: ignore py vulnerabiility #129

Merged
merged 2 commits into from
May 10, 2024
Merged

safety: ignore py vulnerabiility #129

merged 2 commits into from
May 10, 2024

Conversation

skshetry
Copy link
Member

It's a test dependency, so it's safe to ignore.

Revert when celery/pytest-celery#305 gets merged.

It's a test dependency, so it's safe to ignore.
@skshetry skshetry requested a review from shcheklein May 10, 2024 10:34
@skshetry skshetry merged commit 0e26d1d into main May 10, 2024
17 checks passed
@skshetry skshetry deleted the ignore-py-vuln branch May 10, 2024 12:05
@Nusnus
Copy link

Nusnus commented Jul 16, 2024

@skshetry

Revert when celery/pytest-celery#305 gets merged.

See celery/pytest-celery#305 (comment)

@shcheklein
Copy link
Member

@Nusnus thanks! do you plan to release it soon?

@Nusnus
Copy link

Nusnus commented Jul 17, 2024

@Nusnus thanks! do you plan to release it soon?

Done @skshetry

@shcheklein
Copy link
Member

thanks @Nusnus . looked into this, but it seems actually 1.0 is a significant change compared to the previous wrapper around celery.contrib.pytest. We are using "Kombu filesystem transport as the message broker, and the standard filesystem Celery results backend" in production (README). Not sure if we should just migrate to celery.contrib.pytest, if it's pretty much the same as installing the 0.0.0 version of the package.

Or does 1.0+ support basic setup (no Docker, basic file based backend from Celery, Kombu)?

@Nusnus
Copy link

Nusnus commented Aug 3, 2024

@shcheklein

thanks @Nusnus . looked into this, but it seems actually 1.0 is a significant change compared to the previous wrapper around celery.contrib.pytest. We are using "Kombu filesystem transport as the message broker, and the standard filesystem Celery results backend" in production (README). Not sure if we should just migrate to celery.contrib.pytest, if it's pretty much the same as installing the 0.0.0 version of the package.

Or does 1.0+ support basic setup (no Docker, basic file based backend from Celery, Kombu)?

v1.x.x basically adds a new layer on top of the legacy QA infrastructure for simulating production-like Celery environments to enable tests the legacy infra was unable to allow. It does that by creating docker containers for all of the architecture entities (workers, brokers, etc.) and making sure they can interact with each other on one side while providing an API to control each entity in a pytest test function. This was developed to allow adding a new smoke tests layer to the QA tests of Celery. For more info, see the official docs.

As a client of pytest-celery you may choose to avoid all of the new infrastructure by sticking with the v0.0.0 release, which is configured to take the implementation from the celery repo itself (the plugin itself on v0.0.0 has no code practically).

To elaborate on that a bit, because I understand it may be confusing, the v0.0.0 plugin is basically installing a subset of the celery repo itself, the celery.contrib.pytest code specifically. This allows the QA infrastructure there to be developed alongside Celery itself, as part of the same codebase. It is used internally for the unit & integration tests but is also limited in its capability of testing complicated scenarios, which includes restarting or killing a Celery worker. This is where v1.x.x comes in, by adding a completely new codebase in the plugin repo itself, that adds testing infrastructure for creating docker containers and managing them throughout the test, thus allowing killing and restarting of components like a Celery worker, broker, or backend, to tests scenarios where the integration tests are limited due to the nature of running a single worker in a thread and no control at all over the rest of the environment itself (broker/backend).

If you’re planning to use these new features, but also have tests that are using the celery.contrib.pytest infrastructure, you can install v1.x.x as it also maintains all of the celery.contrib.pytest API when installed. If you don’t need any of the new capabilities, you may remain with the v0.0.0 and keep relying only on the code in celery.contrib.pytest. Installing v1.x.x will install additional dependencies so if they are not used the v0.0.0 may be enough.

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.

3 participants