Add workflow_dispatch and schedule events to ci_cd workflow and constraint jax<0.4.25 to be

[traversaro]

Changes:

• The CI/CD job use a rolling release distribution for dependencies, if I am not wrong. That is fine, but in that case to track regressions it is convenient to build periodically, and permit to trigger CI jobs run manually.
• Pin jax to be < 0.4.25, as there have current jaxsim does not work fine with jax==0.4.25
• Revert Run pytest in CI only in PRs that update either sources or tests #80, as we are currently installing dependencies from a rolling release distribution (PyPI) and so it is possible that there is a test failure even if nothing changed in source files. We can introduce something similar if we start using a lockfile of some kind, if we add the logic also to check changes in the lockfile.

---

📚 Documentation preview 📚: https://jaxsim--93.org.readthedocs.build//93/

[traversaro]

I also added a step to print pip list and easily compare pip packages used for different jobs.

[flferretti]

It looks good to me, thanks! Yet, I believe that activating a dependabot might be useful for this aim. What do you think about that?

[traversaro]

It looks good to me, thanks! Yet, I believe that activating a dependabot might be useful for this aim. What do you think about that?

I guess dependabot needs to work on some kind of lockfile or similar used for testing. Probably we need to add something similar before adding dependabot? One thing that I would pay attention to is to avoid conflating "presumed compatibiltiy ranges of dependencies" and "version of the dependencies used for tests".

[flferretti]

I guess dependabot needs to work on some kind of lockfile or similar used for testing. Probably we need to add something similar before adding dependabot? One thing that I would pay attention to is to avoid conflating "presumed compatibiltiy ranges of dependencies" and "version of the dependencies used for tests".

Yes, it makes sense. Let me cc @diegoferigo

[traversaro]

Cool, anyhow it seems that tests seem to work fine with jax==0.4.24, I guess this is a good enough solution to fix the CI, we can enable back compatibility with jax==0.4.25 once we migrate tests to the functional interface.

[diegoferigo]

The conditional logic to run pytest was to reduce CI time on PRs that were not touching any .py file. They were running in all other non-PR events. I don't see why the CI of a PR running on non-.py should fail if dependencies are out of sync. In the previous behavior, CI on the merged commit would fail, and that's what I would expect.

Any other reason to remove previous logic? I still don't get the motivation. For the other changes, I agree on both the dispatch and the pinning.

[diegoferigo]

Ahn ok I see, you were maybe referring to changes of setup.cfg? It could have made sense adding also that file to the exclusion logic alongside the .py files.

[flferretti]

Ahn ok I see, you were maybe referring to changes of setup.cfg? It could have made sense adding also that file to the exclusion logic alongside the .py files.

Yes, and also to check if using the latest versions of the dependencies make the build fail, like in this case

[diegoferigo]

Yes but the failure is not due to the changes of this PR specifically, I'd expect to see CI green here. I expect a new PR to fix the problem if the CI of main fails due to new dependencies.

[traversaro]

Yes but the failure is not due to the changes of this PR specifically, I'd expect to see CI green here. I expect a new PR to fix the problem if the CI of main fails due to new dependencies.

The problem we experienced is that the tests also depends on:

• .github/workflows/ci_cd.yaml
• pyproject.toml
• setup.cfg

Then idea is that if you open a PR to check if the CI works, it is a bit counterintuitive if the CI is green even if the test did not run. However, then we added also the schedule and workflow_dispatch triggers to detect this, so indeed we can add back this check if you think it is worth.