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

Create reusable workflows for scheduled and regular tests #4227

Open
kratman opened this issue Jun 28, 2024 · 1 comment
Open

Create reusable workflows for scheduled and regular tests #4227

kratman opened this issue Jun 28, 2024 · 1 comment
Assignees
Labels
difficulty: easy A good issue for someone new. Can be done in a few hours priority: low No existing plans to resolve

Comments

@kratman
Copy link
Contributor

kratman commented Jun 28, 2024

Followup to #4172 since the focus of that ticket was making sure all the tests work.

Several of our CI workflows can be reworked into reusable workflows to avoid duplication. After #4172 it is pretty easy for unit/integration tests, but there are probably more that can be reworked. This will do a lot to simplify our CI process

@kratman kratman self-assigned this Jun 28, 2024
@agriyakhetarpal agriyakhetarpal added difficulty: easy A good issue for someone new. Can be done in a few hours priority: low No existing plans to resolve labels Jun 28, 2024
@agriyakhetarpal
Copy link
Member

agriyakhetarpal commented Jun 28, 2024

The idea will be to call the reusable workflow in other workflows, i.e., to add a setup-pybamm workflow with workflow_call:, which takes in the following inputs:

  1. caching: true/false (will control the caching for pybamm-requires and for pip in setup-python jobs),
  2. idaklu: true/false (to not clone pybind11 if false),
  3. and any other inputs that I may have missed

We can then call the workflow in a step in the scheduled tests and PR tests workflows, and then trigger nox as needed.

Longer term, this will be removed and we will switch to OS-specific workflows anyway in the coming months, so I have added a "low" priority label for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty: easy A good issue for someone new. Can be done in a few hours priority: low No existing plans to resolve
Projects
None yet
Development

No branches or pull requests

2 participants