search

jupyterhub / jupyter-server-proxy

Jupyter notebook server extension to proxy web services.
https://jupyter-server-proxy.readthedocs.io
BSD 3-Clause "New" or "Revised" License
347 stars 148 forks source link

ci: schedule test runs twice a week #452

Closed consideRatio closed 6 months ago

consideRatio commented 6 months ago

We had test failures in main branch (#449), and realizing that something has started failing is often something that goes with tracking what dependencies has changed.

If I think there is a test that has started failing for some reason outside a code change in repo, I do the following:

  1. Look at workflows run recently to identify when they last worked and when they started failing
  2. Compare pip freeze output between succeeding tests and failing tests by copy pasting into ok.txt and fail.txt and doing git diff --no-index -U0 -- ok.txt fail.txt (-U0 means 0 lines of context surrounding changes observed)

This is troublesome if there isn't a workflow run recently though, but having regular runs, for example twice a week, would do the trick.

consideRatio commented 6 months ago

In https://github.com/jupyterhub/jupyter-server-proxy/issues/449#issuecomment-1954714794 @manics wrote:

I think this could be a good case for using dependabot to pin some dependencies for CI testing. Keep the dev dependencies unrestricted in pyproject.toml, but use a separate dev-ci-requirements.txt file for CI only and let dependabot tell us when there's a UI change in lab or notebook.

@manics I prefer settling for doing this (ensure more regular runs of tests) over adding dependabot to work on a CI specific dependency file as it avoids some complexity and maintenance chore. What do you think?