I went down the path some time in the past when we added the new guides, that also led to severe CI resource exhaustion. IIRC there were some bumps hindering us to go further with the "conditionally execute stuff based on files touched" approach:

• we have branch protection on main, and some actions are marked as required before a merge is possible.
• This effectively could leave an open PR in an "unmergeable" state, because the required CI steps would never run when we leave them out on specific conditions.
• GitHub Actions does not provide proper support for this scenario, yet.
• Ref to old GitHub discussions:
  • https://github.community/t/feature-request-conditional-required-checks/16761
  • Required actions workflows from branch protections should only be required if run community/community#13690 (seems to be the follow-up of the link above, have to scan through that one myself, just found it this morning)

Example: for a docs-only change, e.g. a typo, a (simplified) idea was to have something around the lines of:

on:
  push:
    paths-ignore:
      - 'docs/guides/**'
  pull_request:
    paths-ignore:
      - 'docs/guides/**'

and a specific job that just runs only the steps needed to see if the guides can be parsed correctly. Now our matrix testsuite is required, but not executed. This leads to an unmergeable state for a purely docs-related PR.

That being said, consider this just a point of information why I stopped looking into improving it back then. The idea makes total sense, I have not keepen track of the latest developments around this topic on the GHa side and hope it is somehow possible to achieve this.

edit: the github discussions follow-up links to a documentation bit that states that it is possible with a workaround (for now) that is having a "return true" dummy workflow with the same name and the inverse filtering logic. This feels very hacky and would pollute our CI script quite a bit, but might work unless there's better support. In the meantime, feel free to give the thread a vote, so hopefully we will have better support in the future.

Some more options (maybe not solutions, yet):

• Some parts like the "test-cluster" already look into the most recent git diff to figure out if they should run. If not, they complete early, see GIT_DIFF here:
  

  keycloak/.github/workflows/ci.yml

  Lines 295 to 313 in a1c0e5b

  	test-cluster:
  	name: Test Clustering
  	needs: build
  	runs-on: ubuntu-latest
  	steps:
  	- uses: actions/checkout@v3
  	with:
  	fetch-depth: 2
  	- name: Check whether this phase should run
  	run: echo "GIT_DIFF=$[ $( git diff --name-only HEAD^ | egrep -ic 'crossdc|infinispan' ) + $( git diff HEAD^ pom.xml | egrep -ic '\+\s+<wildfly.version>' ) ]" >> $GITHUB_ENV
  	- uses: actions/setup-java@v3
  	if: ${{ github.event_name != 'pull_request' || env.GIT_DIFF != 0 }}
  	with:
  	distribution: 'temurin'
  	java-version: ${{ env.DEFAULT_JDK_VERSION }}
  	cache: 'maven'

  
  This could be a workaround for the problem with the required actions that @DGuhr describes.

• There is the Maven extension / plugin https://github.com/gitflow-incremental-builder/gitflow-incremental-builder that is used for example in Quarkus. Despite its name "gitflow", it allows incremental builds for Maven projects by looking at the changes committed in a given branch. It might be able to determine the dependencies between modules where we don't want to run some of the tests.

• Using the gitflow-incremental-builder it might be possible to speed up the Unit Test build as follows (it's a one-liner once that maven extension is active):

  • identify all changes modules
  • build all upstream modules for the changed modules, but skip the tests for those
  • build all changed modules and the downstream modules and run the unit tests on those

  Depending on the results, one could even skip downloading the pre-built keycloak which takes ~2 min to download.

BTW: I'd assume the gitflow-incremental-builder comes in quite handy when working on the Quarkus distribution of Keycloak, as one would regularly build the non-Quarkus-modules. Maybe someone with Quarkus development experience can comment on that.

Thank you, @DGuhr @ahus1 and @andreaTP for the feedback. Those are interesting ideas to explore. As short-term solution and an immediate step. Would make sense to have a PR based on the simplified idea suggested by @DGuhr ? I don't think it will solve all the issues, but it's a small and important improvement from my perspective, and we can iterate over it.

For now, I'm thinking about prevent our workflows to run on pull-requests for docs and translation files. Something like:

on:
  pull_request:
    paths-ignore:
      - 'docs/**' (we don't need to run tests when a markdown file changes)
      - 'themes/**/*.properties' (from what I checked we don't have integration tests for our translations. That means no tests for pt_BR messages for example.)
      - 'examples/**' (those are old examples, eventually updated but can run as part of the nightly jobs)
      - 'adapters/**/jetty/**' (OIDC and SAML adapters were deprecated and can run as part of the nightly jobs)
      - 'adapters/**/tomcat/**' (OIDC and SAML adapters were deprecated and can run as part of the nightly jobs)
      - 'adapters/adapters/oidc/wildfly/**' (deprecated and can run as part of the nightly jobs)

As a second step, explore the options suggested with GIT_DIFF, and also the approach from Quarkus. Does it make any sense?