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

[Refactor] Decouple config and execution in nb-tester #2410

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

frankharkins
Copy link
Member

Pre-work for #2405.

This PR refactors nb-tester to decouple the config logic, which decides which notebooks to run and how to patch them, from the notebook execution logic, which runs the notebooks.

The config logic is already the most complicated part of the program. This PR decouples config and execution by moving them to separate files and having them communicate only by a single NotebookJob interface. Each NotebookJob contains a notebook path and instructions on how to run that notebook. This means the config logic can be scoped to creating a list of NotebookJob objects. This also makes the config logic easier to test.

There should be no behaviour changes in this PR.

Comment on lines +70 to +76
@dataclass
class Result:
ok: bool
reason: str | None = None

def __bool__(self) -> bool:
return self.ok
Copy link
Member Author

Choose a reason for hiding this comment

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

Aside from separating the code and introducing the NotebookJob interface, this is the only other change. It's useful to know "why" a bool is set so we can give feedback to users. This was introduced for the write option but I've switched most functions that return a bool to return a Result object.

return notebook_warnings


async def execute_notebook(job: NotebookJob) -> Result:
Copy link
Member Author

Choose a reason for hiding this comment

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

This function is logically the same, but it gets its information from the NotebookJob rather than the separate arguments.


print(
f"⚠️ Cancelling {len(jobs)} job(s) created after {start_time}.\n"
"Add any notebooks that submit jobs to `notebooks-that-submit-jobs` in "
f"`{config_path}`."
f"`scripts/config/notebook-testing.toml`."
Copy link
Member Author

Choose a reason for hiding this comment

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

Hardcoded for now but will make more general in a follow-up

@frankharkins frankharkins marked this pull request as ready for review December 2, 2024 12:59
Copy link
Collaborator

@arnaucasau arnaucasau left a comment

Choose a reason for hiding this comment

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

Awesome work Frank! I like the communication between scripts using NotebookJob a lot!

Comment on lines -552 to -565
if paths and args.is_fork:
print(
"⛔️ We can't run notebook tests on pull requests from forks becaus of how GitHub Secrets work."
"\n\n"
"If you have write access to Qiskit/documentation, push to a new "
"branch there and make your pull request from that branch instead."
"\n\n"
"If you don't have write access, you should locally test out the notebooks you're modifying "
"by using the instructions in "
"https://github.com/Qiskit/documentation#execute-notebooks. "
"When this PR is approved, a maintainer will merge it to a new "
"branch in Qiskit/documentation, then make a PR from that branch "
"into main so it can pass CI.\n",
)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wasn't able to find this conditional after the refactor. Do we still use it?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Good catch. It'd be helpful to keep this.


for path in config.notebooks_to_execute():
backend_patch = None
if config.should_patch(path):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Very nice having this part here rather than in _execute_in_kernel 🚀




def get_args() -> argparse.Namespace:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe we can keep this function in __init__.py to reduce the complexity of the config.py script. Although, I think it's fine either way if you like it more here :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it makes sense here since it's about config

Copy link
Collaborator

@Eric-Arellano Eric-Arellano left a comment

Choose a reason for hiding this comment

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

Thanks!




def get_args() -> argparse.Namespace:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it makes sense here since it's about config

"""


def post_process_notebook(nb: nbformat.NotebookNode) -> nbformat.NotebookNode:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nit: should this go in execute? It's not configurable. Or even a new version_info.py or post_process.py?



def cancel_trailing_jobs(start_time: datetime, config_path: str) -> bool:
def cancel_trailing_jobs(start_time: datetime) -> Result:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd probably expect this to be in execute.py or a post_process.py so that __init__.py is only the very high-level business logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

3 participants