[engine] Linux Fuchsia and Linux Fuchsia FEMU don't have runif logic

[CaseyHillers]

https://github.com/flutter/engine/blob/master/.ci.yaml#L160-L176

This causes these builds to always be run on presubmit, even if the change was just a markdown.

See flutter/engine#29566 where these were run on a darwin only change.

Adding some paths in the runif for where Fuchsia code is would help prevent unnecessary testing

[CaseyHillers]

\cc @chandarrengoog

[dnfield]

I started drafting a runIf block for Fuchsia and it looks like this:

      - .ci.yaml
      - BUILD.gn
      - DEPS
      - assets/**
      - benchmarking/**
      - build/**
      - ci/**
      - common/**
      - flow/**
      - flutter_frontend_server/**
      - fml/**
      - lib/**
      - runtime/**
      - shell/common/**
      - shell/gpu/**
      - shell/platform/BUILD.gn
      - shell/Platform/config.gni
      - shell/platform/common/**
      - shell/platform/fuchsia/**
      - shell/platform/embedder/**
      - testing/**
      - version/**
      - vmservice/**
      - sky/**
      - third_party/tonic/**
      - third_party/txt/**
      - tools/const_finder/**
      - tools/font-subset/**
      - tools/fuchsia/**

Which seems kind of brittle and scary to me. It's basically saying don't run if you changed files that are only under shell/platform/(darwin|android|linux|windows|glfw). Maybe there's some better way to express that?

Ideally we'd be using something like gn analyze to figure out whether the git ls-files changed anything that's part of the target(s) we plan to build, and ideally before scheduling the bot.

[chandarrengoog]

CC: @arbreng maybe you would have a better idea?

[arbreng]

This seems like a pretty good way to free up some CI resources, nice catch :)

[zanderso]

@arbreng It sounds like @dnfield's suggestion could be pretty brittle. Do you know of any more robust way of doing this?

[arbreng]

I like this suggestion: "Ideally we'd be using something like gn analyze to figure out whether the git ls-files changed anything that's part of the target(s) we plan to build, and ideally before scheduling the bot."

The fuchsia embedder uses all of the engine, just like the other embedders do. So, this " It's basically saying don't run if you changed files that are only under shell/platform/(darwin|android|linux|windows|glfw)." is the correct pattern.

Darwin would have " It's basically saying don't run if you changed files that are only under shell/platform/(android|fuchsia|linux|windows|glfw)." and the same goes for the other embedders.

[godofredoc]

Closing because the bug has not been updated for more than one year.

Feel free to reopen any bugs that you believe are important but please provide updates on how to resource the fix of the bug and what can be done to prevent the issue from not getting updates for another year.

[zanderso]

This is still a valid issue. Reopening.

[godofredoc]

Removing infra-team as it lacks the context to define the right filters and filtering is already supported in the .ci.yaml file.

[dnfield]

@godofredoc - based on my question in #93261 (comment), does ci.yaml support some way of saying "run if not"?

The problem for this target is that it should not be run if the changes are exclusive to a few directories. If we craft a regular "run-if" it will regress over time when someone adds a new directory.

[godofredoc]

The filtering logic runs server side and is limited to use the pull request data returned by github.

Not sure I understand how the "run if not" will be used, @dnfield can you please provide an example to see if it can be calculated from the data available to backend?

[dnfield]

Right now we can say:

"Run if any files have changed in the following directories."

I want to be able to say:

"Run if there are any changes to files not in the following directories"

[godofredoc]

@dnfield run_if_not has been implemented moving this bug back to you for the final filters.

[zanderso]

@matanlurey @johnmccutchan This is relevant to our conversation the other day.

[matanlurey]

I'm happy to take this issue.

[zanderso]

Thanks, Matan!

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.