Only rebuild images that could have changed

[scottwittenburg]

The goal here is to only rebuild images that might actually need to be rebuilt, based on what files changed. I suggested I would do this here, see that discussion for more background.

[scottwittenburg]

I tested this stuff with a different workflow and rules since the way we have this workflow now, it only runs when pushing to main. Here's an example workflow: https://github.com/spack/spack-infrastructure/actions/runs/6179687042/job/16775011917

In there if you look through the jobs, you can see that the gh-gl-sync build ran the conditional step, while others, like the gitlab-api-scrape one skipped that step.

I wish there were an early exit option for jobs, instead of having to put an if on every step after the check, but it seems not to exist. A lot of people want it though, based on the popularity of this issue.

[mvandenburgh]

LGTM. It might be worth looking into whether we can use https://github.com/dorny/paths-filter instead (maybe that was the action you were referring to earlier). And then use the output from that action to build the job matrix dynamically. Sort of how it's done here https://stackoverflow.com/a/65434401. Might be something to put on the backlog at least depending on how high of a priority this is, but I think this solution is sufficient for our purposes now

[scottwittenburg]

It might be worth looking into whether we can use https://github.com/dorny/paths-filter instead (maybe that was the action you were referring to earlier).

It was actually this one I meant, which looks really active, is used by a lot of people, and has more features.

And then use the output from that action to build the job matrix dynamically

Yeah, I wanted to do that too, once I saw this workflow in change-actions repo, I wondered how we could do that in our case. Just need to figure out how to continue using our manually incremented tags in that scenario, but I didn't really try yet. I'll give it a go, as it would be nice to skip altogether the jobs we don't need.