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

Introduce new CI that has plots after trigger cuts #1516

Open
tvami opened this issue Jan 17, 2025 · 1 comment
Open

Introduce new CI that has plots after trigger cuts #1516

tvami opened this issue Jan 17, 2025 · 1 comment

Comments

@tvami
Copy link
Member

tvami commented Jan 17, 2025

Is your feature request related to a problem? Please describe.

Right now all the CI show plots before any selection.

Describe the solution you'd like

I'd like to have another CI that has it after the trigger

Additional context

In a recent PR we concluded that the changes would prob be washed out after cuts, so that brought up that it would make sense to have a version of a CI that does that

@tomeichlersmith
Copy link
Member

I think the biggest issue that prevents us from accomplishing this is the time necessary to create a large enough trigger-skimmed sample. The GitHub CI runners have a time limit of 6 hours (last time I checked, this could be changed at anytime by Micros**t) and so we have two options.

  1. Get crafty with the sample generation. Either using multiple jobs that are then merged or by biasing/filtering so that the generation of the trigger-skimmed sample takes less than the time limit imposed.
  2. Have self-hosted runner(s) for these CI jobs.

I think option (2) is the better approach. We already have two self-hosted runners at UMN for building the ARM images of the development image and I think it is more maintainable given that we already have cluster-familiar folks who can help keep an eye on these runners. I think it is possible to have GitHub self-hosted runners exist without any administrative privileges but that would almost certainly require rewriting how the workflows run in order to use tools that are already installed (apptainer for example) rather than installing tools into a VM (like is provided by GitHub).

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

No branches or pull requests

2 participants