build: experimental PR speed improvement: filter PR change folder

[dave-gray101]

There's no need to run tests or build images when the changes are docs-only or exclusive to the examples/** directories

In particular I expect this to speed up the numerous dependabot PRs to python dependencies down in examples.

Netlify should probably be configured in a similar way, but I am not sure how to do that so one thing at a time.

In the future, it may be possible to take this farther and only run extras tests when grpc / core/backend code changes... but that is also out of scope for now.

[netlify]

✅ Deploy Preview for localai ready!

Name	Link
🔨 Latest commit	3053f77
🔍 Latest deploy log	https://app.netlify.com/sites/localai/deploys/66e8994e24c6e10008d82fc1
😎 Deploy Preview	https://deploy-preview-3477--localai.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[dave-gray101]

@mudler This one will probably need a manual approval / merge on your part: I think there's github repo-side changes you'll need to make as the project admin to support this - let me know how I can help figure out what we need to allow conditionally-required checks.

I may be wrong here - I'm also seeing some info that indicates a skipped check may automatically count as passed, so I think the true test here is to see what happens upon approval, and then fix or revert quickly based on that result.

It's just somewhat weird to see "14 expected" down there 😆

[mudler]

@mudler This one will probably need a manual approval / merge on your part: I think there's github repo-side changes you'll need to make as the project admin to support this - let me know how I can help figure out what we need to allow conditionally-required checks.

I'd really like to move in this direction, however to my knowledge there is no way for GitHub to set 'conditionally' required checks unless I'm missing something.. afaik GitHub just let you select required status checks, and the only way around it would be to mark them to pass as part of the test itself by conditionally returning 'success' even if no real tests are being run; ignoring workflow would impede the PR to be merged as status checks can be just set as 'required'

[dave-gray101]

Given that this branch is actually reporting green now - I think that my 2nd theory (skipped checks count as passed) may be true.

Do you mind tossing a review on it to see if it just auto-merges? I think that's the best experiment.

[dave-gray101]

@mudler I missed this while reading docs yesterday - it's absolutely the case that skipped checks count as passed:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks

Note: A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.

[mudler]

👍 💯

[dave-gray101]

Interesting. It has not auto-merged.

It seems that based on https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-jobs-in-a-workflow#defining-prerequisite-jobs we'll need to add a "report status" stage at the very end with needs: and if: always().

Given that I'm not sure exactly what you've set up in the project settings, would it be more helpful to "rename" our current checks, and use the existing names for the "required status reporting" stage? Or would you prefer I create simpler "status-check-result" stages for each workflow and leave the existing ones as-is? The latter is probably a bit cleaner and simpler to maintain, but will require some changes on your side to update what checks are and are not required.

[mudler]

Interesting. It has not auto-merged.

It seems that based on https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-jobs-in-a-workflow#defining-prerequisite-jobs we'll need to add a "report status" stage at the very end with needs: and if: always().

huh, that's very annoying :( also because if we start to do changes in the workflow we have to keep an eye on updating that step, that's really annoying that GHA doesn't have native support for such a common problem.

Given that I'm not sure exactly what you've set up in the project settings, would it be more helpful to "rename" our current checks, and use the existing names for the "required status reporting" stage? Or would you prefer I create simpler "status-check-result" stages for each workflow and leave the existing ones as-is?

The latter is probably a bit cleaner and simpler to maintain, but will require some changes on your side to update what checks are and are not required.

No problem with that 👍 we can force merge at that point and I'll update the settings

[dave-gray101]

Looks like another draft is in order. I'll update this soon.