Skip to content

Issue 2125 broken selenium tests #2129

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

Merged

Conversation

hansthen
Copy link
Collaborator

@hansthen hansthen commented Apr 8, 2025

Version fix for jupytext to fix broken selenium tests. Closes #2125 .

@hansthen hansthen requested a review from Conengmo April 8, 2025 09:14
@hansthen
Copy link
Collaborator Author

hansthen commented Apr 8, 2025

I am annoyed by these breaking CI's.

Each time this happens it takes me quite some time to figure out exactly what package causes the issue. Is it an idea to add the output of pip freeze to the repository whenever we make a release? We can then create update our workflows so that on failure they compare the stored versions to the actual versions. This will help us identify breaking issues much faster.

@hansthen hansthen force-pushed the issue_2125_broken_selenium_tests branch from 9c7b2b1 to a4e3a53 Compare April 8, 2025 14:56
@hansthen hansthen requested a review from ocefpaf April 8, 2025 15:06
@ocefpaf
Copy link
Member

ocefpaf commented Apr 8, 2025

Is it an idea to add the output of pip freeze to the repository whenever we make a release? We can then create update our workflows so that on failure they compare the stored versions to the actual versions. This will help us identify breaking issues much faster.

We can have a "locked" CI and an unlocked one. That may help? However, I like to test against unlocked CIs to be sure we are hitting these errors and not the users.

@hansthen
Copy link
Collaborator Author

hansthen commented Apr 8, 2025

We can have a "locked" CI and an unlocked one. That may help? However, I like to test against unlocked CIs to be sure we are hitting these errors and not the users.

By a locked CI you mean something like npm's lock files? I agree with you that we need to run the CI without version fixes as much as possible.

That was not what I had in mind, though.

My idea is to (after a successful release and as part of the CI), store the output of pip freeze somewhere for documentation purposes. Then, when a CI fails we can diff the current versions against the versions that produced the last successful CI run.

Another idea is to periodically schedule a CI run. That way we notice it earlier when the CI is broken and not on the next PR.

@ocefpaf
Copy link
Member

ocefpaf commented Apr 8, 2025

I'm OK with any of those ideas. Mine is kind of costly, it would always run 1 matrix item with a lockfile, in theory always passing with regards to dependency changes, b/c there none, plus what we have now. Then, if the locked one passes but the unlocked doesn't, we know to look for dependency changes.

@hansthen
Copy link
Collaborator Author

hansthen commented Apr 8, 2025

@ocefpaf I understand. I will create a new branch to experiment with those ideas. Easiest is probably to start with scheduled workflows. In the meantime, can you have a look at the current PR? It is just a version fix until I can figure out what changed in the jupytext package.

@hansthen hansthen merged commit e767481 into python-visualization:main Apr 8, 2025
25 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.

The selenium tests in the CI are broken
2 participants