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

Support workdir venv #1548

Merged
merged 2 commits into from
Dec 5, 2024
Merged

Support workdir venv #1548

merged 2 commits into from
Dec 5, 2024

Conversation

nirs
Copy link
Member

@nirs nirs commented Sep 9, 2024

Support creating venv per workdir:

git worktree add ~/ramen-foobar
cd ~/ramen-foobar
hack/make-venv .venv/ramen
source venv

With this you can test drenv changes in the ramen-foobar worktree without affecting the main worktree, using the standard venv (~/.venv/ramen).

Use this in the CI to ensure that every build uses a fresh venv instead of installing drenv on the runner host.

@nirs nirs marked this pull request as draft September 9, 2024 13:27
@nirs nirs marked this pull request as ready for review September 9, 2024 13:48
@nirs nirs marked this pull request as draft September 19, 2024 14:28
@nirs
Copy link
Member Author

nirs commented Sep 19, 2024

Needs rebase after main changed.

@nirs nirs marked this pull request as ready for review September 19, 2024 17:47
Copy link
Member

@raghavendra-talur raghavendra-talur left a comment

Choose a reason for hiding this comment

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

Needs a rebase but other than that I agree with the change.

@nirs
Copy link
Member Author

nirs commented Nov 20, 2024

Should be ready, but lets wait for the build:
https://github.com/RamenDR/ramen/actions/runs/11939408219

nirs added 2 commits November 21, 2024 16:52
When using CI, we want to use a fresh venv for every build so bad venv
created by one job does not break the next job, or bad change in a PR is
not hidden by good venv created by a previous job.

When using local development, you may want to have venv per ramen source
directory. One case is using git worktree to have multiple ramen trees.
With this change you can create a venv per ramen worktree.

Example usage:

    hack/make-venv .venv/ramen

Since this is the expected usage, add this path to gitignore, so using
`git clean dxf` does not remove the directory.

Signed-off-by: Nir Soffer <[email protected]>
Create venv inside the ramen checkout directory to have fresh venv for
every build.

Since drenv is not installed on the runner, we need to enter the venv in
any step script. I hope we can find a way to enter the venv once for the
entire job, but this is good enough for now.

Signed-off-by: Nir Soffer <[email protected]>
@raghavendra-talur
Copy link
Member

@nirs Do you think the e2e failure is related?

@nirs
Copy link
Member Author

nirs commented Nov 21, 2024

@nirs Do you think the e2e failure is related?

No, this is a known issue with cephfs. Sometimes we fail to clean up after the volsync file test, since the cpehfs snapshot is not deleted. When this happens, retrying the e2e job will continue to fail because we are using the same namespaces and resources names, so stuck snapshot will continue to fail without manual cleanup.

If there was an issue with the venv, deleting the cluster would fail and we would not reach the step of starting the clusters.

@nirs
Copy link
Member Author

nirs commented Nov 21, 2024

The next failure: https://github.com/RamenDR/ramen/actions/runs/11955746683/job/33336392815
is also not related, looks like another instance of #1659

@nirs
Copy link
Member Author

nirs commented Dec 2, 2024

@raghavendra-talur this is ready for merge, the random failures in the ci should be fixed by #1689

@raghavendra-talur raghavendra-talur merged commit 29a8caa into RamenDR:main Dec 5, 2024
22 checks passed
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