This repository has been archived by the owner on Jan 5, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Allie Crevier <allie@freedom.press>
Signed-off-by: Allie Crevier <allie@freedom.press>
sssoleileraaa
force-pushed
the
support-dev-only-and-sync
branch
from
August 25, 2021 23:08
9083196
to
f3c876c
Compare
kushaldas
approved these changes
Aug 26, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: The dev-requirements.txt
file gets an update in the relatest tests here as importlib-metadata
has an update.
Test new venv
target:
- Create a dev env
-
make venv && source .venv/bin/activate
creates dev env with all dev deps installed
-
Test updating existing requirements.txt
file
- Run
make requirements
- Verify that you see no local changes since the dependency specification is already met (
redis==3.3.11
)
- Verify that you see no local changes since the dependency specification is already met (
- Update dependency specification to
redis>=3.3.11
and runmake requirements
- Verify that you see no local changes since the dependency specification is already met (3.3.11 is >= 3.3.11)
- Add a new dependency spec:
zipp<3
torequirements.in
and runmake requirements
- Verify that you see the new dependency pinned in
requirements.txt
- NEW SYNC BEHAVIOR Verify that you see the existing previously dev-only dependency downgraded in
dev-requirements.txt
to match what's in prod
- Verify that you see the new dependency pinned in
Test creating new requirements.txt
file
- Make sure to undo chnages from previous test
rm -r requirements/requirements.txt
make requirements
- Verify that you see no local changes since the only dependency specification is
redis==3.3.11
which matches what we have on remote
- Verify that you see no local changes since the only dependency specification is
rm -r requirements/requirements.txt
- Update dependency specification to
redis>=3.3.11
and runmake requirements
- Verify that you see the latest version of redis pinned in
requirements.txt
- NEW SYNC BEHAVIOR Verify that you see the same version of redis in
dev-requirements.txt
to match what's in prod
- Verify that you see the latest version of redis pinned in
Test updating a single dependency
- Update dependency specification to
redis>=3.3.11,<3.5
and runPACKAGE=redis make update-dependency
- Verify that you see version 3.4.1 of redis pinned in
requirements.txt
- NEW SYNC BEHAVIOR Verify that you see the same version of redis in
dev-requirements.txt
to match what's in prod
- Verify that you see version 3.4.1 of redis pinned in
- Try to add a new dependency that doesn't exist in
requirements.in
by runningPACKAGE=pytest make update-dependency
- Verify that you see no local changes
Test updating all dev-only dependencies
make update-dev-only-dependencies
- Verify that you see no local changes since the only dev dependency is already the latest
- Add
six<1
andredis
(with no==
,<=
, or>=
) todev-requirements.in
and runmake update-dev-only-dependencies
- Verify that redis is still pinned to the same version as prod
- Verify
six==0.9.2
is pinned indev-requirements.txt
- Update
six<1
to justsix
and runmake update-dev-only-dependencies
- Verify latest version of
six
is pinned indev-requirements.txt
- Verify latest version of
conorsch
pushed a commit
to freedomofpress/securedrop-builder
that referenced
this pull request
Sep 1, 2021
Recent nightlies of `securedrop-proxy` were broken, due to missing imports [0]. In a recent PR [1], the requirements files within the securedrop-proxy repo (and therefore tarball) were moved, and the package build logic depends on those locations. To my great surprise and disappoint, dh_virtualenv evidently will not complain if a `--requirements` file does not exist. The build will be called successful. That's unacceptable, so I've modified the debian/rules file to test for existence as a workaround. If folks agree this is a sane solution, we should update the rules files for the other packages to match. [0] https://github.com/freedomofpress/securedrop-proxy/issues/94 [1] freedomofpress/securedrop-proxy#92
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Closes #153
See test plan: freedomofpress/securedrop-log#24