Skip to content

chore(deps): update gradle/actions action to v6#1337

Merged
dbwiddis merged 1 commit intomainfrom
whitesource-remediate/gradle-actions-6.x
Mar 25, 2026
Merged

chore(deps): update gradle/actions action to v6#1337
dbwiddis merged 1 commit intomainfrom
whitesource-remediate/gradle-actions-6.x

Conversation

@mend-for-github-com
Copy link
Contributor

This PR contains the following updates:

Package Type Update Change
gradle/actions action major v5v6

Release Notes

gradle/actions (gradle/actions)

v6

Compare Source


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

@codecov
Copy link

codecov bot commented Mar 24, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.62%. Comparing base (dd2a5b2) to head (19884fc).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##               main    #1337   +/-   ##
=========================================
  Coverage     77.62%   77.62%           
  Complexity     1267     1267           
=========================================
  Files           106      106           
  Lines          5904     5904           
  Branches        612      612           
=========================================
  Hits           4583     4583           
  Misses         1025     1025           
  Partials        296      296           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@dbwiddis
Copy link
Member

The failing job is caused by a 400 Bad Request error from the following endpoint: PUT /_plugins/_security/api/resource/share. The error message is:

access_level must be one of:

This suggests that the test is trying to share resources (such as a workflow or its state) with an invalid access_level value.

In the code, the shareConfig and patchSharingInfo helper methods are used to construct the payload for resource sharing. The access_level is passed as a variable (such as WORKFLOW_READ_ONLY_AG, WORKFLOW_FULL_ACCESS_AG, etc.). If these constants do not match the accepted values expected by the API, you will get this error.

Solution:

  • Verify the valid access_level values expected by the resource sharing API.
  • Ensure that the following variables in FlowFrameworkResourceSharingRestApiIT.java match the allowed values:
    • WORKFLOW_READ_ONLY_AG
    • WORKFLOW_FULL_ACCESS_AG
    • WORKFLOW_STATE_READ_ONLY_AG
    • WORKFLOW_STATE_FULL_ACCESS_AG

For example, if the allowed values per API are "read_only" and "full_access", change their definitions at the top of FlowFrameworkResourceSharingRestApiIT.java from:

private static final String WORKFLOW_READ_ONLY_AG = "workflow_read_only";
private static final String WORKFLOW_FULL_ACCESS_AG = "workflow_full_access";
...

to:

private static final String WORKFLOW_READ_ONLY_AG = "read_only";
private static final String WORKFLOW_FULL_ACCESS_AG = "full_access";
...

Match the values to exactly what the resource sharing API accepts.

After correcting these values, your resource sharing operations should succeed and the failing integration tests should pass.

@dbwiddis
Copy link
Member

dbwiddis commented Mar 25, 2026

@cwperks @DarshitChanpura Was there a recent change in resource sharing setup?

I'm not sure I trust Copilot's change suggestion.

@dbwiddis
Copy link
Member

Here's the full chain:

  1. ShareRequest.Builder.parseContent() calls resourcePluginInfo.availableAccessLevels() to build the validator
  2. availableAccessLevels() returns the union of all values in typeToAccessLevels
  3. typeToAccessLevels is only populated by registerAccessLevels(), which takes a SecurityDynamicConfiguration<ActionGroupsV7>, meaning the valid access levels are loaded from action groups configuration, not hardcoded

So the question is: is registerAccessLevels() ever being called for the flow-framework resource types? If it isn't, typeToAccessLevels is empty, availableAccessLevels() returns an empty set, and the validator rejects everything with a blank error message (empty set formatted as [] or just nothing).

We need to find where flow-framework registers its resource types with the security plugin and whether it calls registerAccessLevels().

@dbwiddis
Copy link
Member

Seems the new validation code is more strict and caught an incorrect filename in the earlier version: resource-action-groups.yml --> resource-access-levels.yml

@dbwiddis dbwiddis force-pushed the whitesource-remediate/gradle-actions-6.x branch from 491ad5f to 5d48913 Compare March 25, 2026 01:19
Signed-off-by: mend-for-github-com[bot] <mend-for-github-com[bot]@users.noreply.github.com>
@mend-for-github-com mend-for-github-com bot force-pushed the whitesource-remediate/gradle-actions-6.x branch from 5d48913 to 19884fc Compare March 25, 2026 01:20
@dbwiddis dbwiddis merged commit 5504067 into main Mar 25, 2026
39 checks passed
@dbwiddis dbwiddis deleted the whitesource-remediate/gradle-actions-6.x branch March 25, 2026 01:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant