chore: update manifest commit SHAs#3768
Open
odh-release-bot[bot] wants to merge 1 commit into
Open
Conversation
odh-release-bot
Bot
force-pushed
the
sync/upgrade-manifest-shas
branch
from
634009d to
3fe63d2
Compare
ugiordan
approved these changes
Jul 7, 2026
ugiordan
force-pushed
the
sync/upgrade-manifest-shas
branch
from
3fe63d2 to
641048c
Compare
ugiordan
approved these changes
Jul 7, 2026
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ugiordan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
rinaldodev
added a commit
to rinaldodev/opendatahub-operator
that referenced
this pull request
Jul 7, 2026
author_association misreports opendatahub-io members with private org visibility, so maintainers were having to re-add run-xks-e2e after every commit even for people who are actually trusted. Until a reliable org membership check is in place, accept the label as long as it is present on the PR instead of only on the labeled event. Bot-authored PRs (odh-release-bot, jira-autofix, dependabot) hit the same gap: author_association reports CONTRIBUTOR for them regardless of the app's actual permissions, confirmed on opendatahub-io#3768, opendatahub-io#3760, and opendatahub-io#3756. Trust those exact logins the same way trusted human associations are trusted. lgtm is trusted too, but only at the exact labeled event, not whenever it's present. Prow strips lgtm from a PR on every new commit by default in this repo (no sticky_lgtm_team or store_tree_hash configured), so a malicious synchronize commit never carries the labeled action lgtm needs, even if Prow hasn't removed the stale label yet. Scoping it that way keeps this signal from reopening the TOCTOU window the label gate exists to close. Given that author_association gap, running the ODH xKS workflow on every PR relies too much on a trust signal that fails for most of the org. This workflow only exercises the kserve component on a Cloud Manager- provisioned cluster (make e2e-test-xks sets E2E_TEST_COMPONENT=kserve), so scope its trigger to kserve and cloudmanager paths instead of running on every PR. The cloudmanager workflow already has its own path filter and keeps the label-and-authorization gate as its primary check, since that is where the actual secret risk is.
8 tasks
|
@odh-release-bot[bot]: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
rinaldodev
added a commit
to rinaldodev/opendatahub-operator
that referenced
this pull request
Jul 7, 2026
author_association misreports opendatahub-io members with private org visibility, so maintainers were having to re-add run-xks-e2e after every commit even for people who are actually trusted. Until a reliable org membership check is in place, accept the label as long as it is present on the PR instead of only on the labeled event. Bot-authored PRs (odh-release-bot, jira-autofix, dependabot) hit the same gap: author_association reports CONTRIBUTOR for them regardless of the app's actual permissions, confirmed on opendatahub-io#3768, opendatahub-io#3760, and opendatahub-io#3756. Trust those exact logins the same way trusted human associations are trusted. lgtm and approved are trusted too, but only at the exact labeled event, not whenever present. Prow strips lgtm from a PR on every new commit by default in this repo (no sticky_lgtm_team or store_tree_hash configured), so a malicious synchronize commit never carries the labeled action either label needs, even if Prow hasn't removed the stale lgtm yet. approved isn't auto-revoked on push, but that doesn't matter here since the check never inspects current label state, only the labeling event itself. Given that author_association gap, running the ODH xKS workflow on every PR relied too much on a trust signal that fails for most of the org. This workflow only exercises the kserve component on a Cloud Manager- provisioned cluster (make e2e-test-xks sets E2E_TEST_COMPONENT=kserve), so scope its trigger to kserve, cloudmanager, and config/rhaii paths (the manifests make deploy-rhaii-local deploys for this test) instead of running on every PR. The cloudmanager workflow already has its own path filter and keeps the label-and-authorization gate as its primary check, since that is where the actual secret risk is.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR updates the manifest commit SHAs to the latest available commits.