You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "slachiewicz (via GitHub)" <gi...@apache.org> on 2026/08/09 09:39:26 UTC

[PR] Build the site through the fail-fast job instead of a one-cell matrix [maven-doxia-site]

slachiewicz opened a new pull request, #71:
URL: https://github.com/apache/maven-doxia-site/pull/71

   `Verify` asks for a single `ubuntu-latest` / `jdk-17` matrix cell and switches the fail-fast job off. That combination leaves the matrix job ungated.
   
   The shared workflow runs `setup-maven-version` only for a `push`, or for a `pull_request` whose head is a **fork**:
   
   ```yaml
   if: >
     (github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.pull_request.head.repo.fork)) && ...
   ```
   
   `verify` is guarded by:
   
   ```yaml
   if: >
     (!cancelled()) && inputs.matrix-enabled && ( !inputs.ff-run || needs.fail-fast-build.result == 'success' ) && ...
   ```
   
   With `ff-run: false` the second clause is true no matter what the other jobs did, and `!cancelled()` keeps a skipped dependency from propagating. So for a pull request opened from a branch **in this repository** `verify` still starts, and its matrix reads
   
   ```yaml
   maven: ${{ fromJSON( needs.setup-maven-version.outputs.maven-matrix ) }}
   ```
   
   from a job that never ran. Fork PRs are unaffected, which is why this has not shown up so far.
   
   Asking for the fail-fast job and turning the matrix off expresses the same "one build" intent through the path that *is* gated on `setup-maven-version`. `ff-os` and `ff-jdk` already default to `ubuntu-latest` and `17`, so the build is unchanged; only `ff-goal` has to carry `clean site`.
   
   `maven-parent`, `apache-parent` and `maven-shared-resources` configure their single-job builds the same way.
   
   Alternatively this could be fixed centrally in `maven-gh-actions-shared` by adding `needs.setup-maven-version.result == 'success'` to `verify`'s condition, which would cover every caller that sets `ff-run: false`. Happy to open that instead or as well.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Build the site through the fail-fast job instead of a one-cell matrix [maven-doxia-site]

Posted by "slachiewicz (via GitHub)" <gi...@apache.org>.
slachiewicz commented on PR #71:
URL: https://github.com/apache/maven-doxia-site/pull/71#issuecomment-5230875223

   Closing this — CI proved the approach wrong, and usefully so.
   
   Routing the build through `fail-fast-build` does not just run `ff-goal`. That job has a second, **unconditional** step:
   
   ```yaml
         - name: Build with Maven
           run: ./mvnw ... ${{ inputs.ff-goal }}
   
         - name: Build Maven Site
           run: ./mvnw ... ${{ inputs.ff-site-goal }}
   ```
   
   `ff-site-goal` defaults to `-DskipTests -P reporting compile site site:stage` and there is no input to suppress it. So this PR silently switched that on. `clean site` passed; `site:stage` then failed:
   
   ```
   [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.22.0:stage (default-cli)
           on project doxia-site: Error uploading site: Error copying directory structure:
           Unknown file type: .../target/site/doxia-tools-archives
   ```
   
   That is a pre-existing problem in this repository's site output, unrelated to the gating question, but it means there is no caller-side configuration here that both keeps the current single `clean site` build and gets the correct skip behaviour.
   
   The underlying issue is still real: with `ff-run: false`, `verify`'s condition
   
   ```yaml
   (!cancelled()) && inputs.matrix-enabled && ( !inputs.ff-run || needs.fail-fast-build.result == 'success' )
   ```
   
   is satisfied regardless of `setup-maven-version` having been skipped, and its matrix then reads `fromJSON(needs.setup-maven-version.outputs.maven-matrix)` from a job that never ran. It only bites pull requests opened from a branch in this repository, not from a fork.
   
   So it belongs in `maven-gh-actions-shared` instead, as `needs.setup-maven-version.result == 'success'` in `verify`'s condition. Opening that there.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Build the site through the fail-fast job instead of a one-cell matrix [maven-doxia-site]

Posted by "slachiewicz (via GitHub)" <gi...@apache.org>.
slachiewicz closed pull request #71: Build the site through the fail-fast job instead of a one-cell matrix
URL: https://github.com/apache/maven-doxia-site/pull/71


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Build the site through the fail-fast job instead of a one-cell matrix [maven-doxia-site]

Posted by "slachiewicz (via GitHub)" <gi...@apache.org>.
slachiewicz commented on PR #71:
URL: https://github.com/apache/maven-doxia-site/pull/71#issuecomment-5230880946

   Correction to my previous comment: I was wrong that the site step cannot be suppressed. It is gated, and there is an input for it:
   
   ```yaml
         - name: Build Maven Site
           run: ./mvnw ... ${{ inputs.ff-site-goal }}
           if: inputs.ff-site-run
   ```
   
   `ff-site-run` defaults to `true`, which is why this PR switched the step on, but `ff-site-run: false` would have kept it off. So a caller-side configuration does exist here:
   
   ```yaml
       with:
         matrix-enabled: false
         ff-goal: 'clean site'
         ff-site-run: false
   ```
   
   I am still leaving this closed, because apache/maven-gh-actions-shared#300 fixes the gating centrally and leaves this repository's configuration untouched, which is the smaller change here. Happy to reopen with the three-input version if the caller-side route is preferred.
   
   The `site:stage` failure this run surfaced is unrelated to either fix and still worth a look on its own:
   
   ```
   Error copying directory structure: Unknown file type: .../target/site/doxia-tools-archives
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org