Yes, that's the implication of this change.
Ismael
On Thu, Mar 6, 2025 at 12:38 AM Chia-Ping Tsai wrote:
> hi David
>
> It appears we can't push reverted commits to trunk from our local
> repository. See the following error message.
>
> remote: Resolving deltas: 100% (15/15), completed with 11
Ok, I think everything is working as expected now.
On Friday, I worked with Infra to set up rulesets for our repo. These are
different from the branch protections that can be configured with
.asf.yaml. Rulesets are quite a bit more flexible than the legacy branch
protections. The rulesets we have
Sorry, let me clarify that point.
There are two proposed rulesets (full details in the INFRA ticket):
1) No force push on trunk or release branches
2) Commits require a PR with a passing status check
Ruleset 1 cannot be bypassed. Ruleset 2 can be bypassed by committers. This
means we should stil
Thanks David. I think you're saying that the second check only applies to
PRs and not to direct pushes to trunk. If so, I understand now.
Ismael
On Thu, Mar 6, 2025 at 9:26 AM David Arthur wrote:
> Sorry, let me clarify that point.
>
> There are two proposed rulesets (full details in the INFRA
Hi David,
I don't follow the following:
* Require all changes to trunk to flow through a PR
That's exactly the case Chia-Ping was asking about that you said is _not_
expected.
Ismael
On Thu, Mar 6, 2025 at 8:01 AM David Arthur wrote:
> Indeed, what I was trying to achieve is not possible w
hi David
It appears we can't push reverted commits to trunk from our local repository.
See the following error message.
remote: Resolving deltas: 100% (15/15), completed with 11 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/trunk.
remote:
remote: - Changes m
Indeed, what I was trying to achieve is not possible with the legacy branch
protections that are configured via asf.yaml. I have reverted that change.
I filed https://issues.apache.org/jira/browse/INFRA-26603 which should let
us accomplish the following:
* Protect trunk and release branches from
Hm, this wasn't my intention with this change. I was expected two things to
change:
1) PRs could only be merged if a required check passed
2) Forced pushes were disabled
I was not expecting regular push to be disabled since there is a separate
config for that (Screenshot from a different repo)
[
Ok looks like Infra’s manual GitHub config change got undone. I see that
this PR https://github.com/apache/kafka/pull/19120 is approved, but can't
be merged :(
I filed https://issues.apache.org/jira/browse/INFRA-26601, hopefully
someone gets to it soon.
On Wed, Mar 5, 2025 at 23:19 David Arth
The up-to-date requirement should not be there (for the reasons you
mentioned). There was a bug with the Infra asf.yaml parser, so Infra
manually removed the up-to-date requirement.
If the checks all pass and the PR is approved, it should be mergeable
up-to-date or not. Let me know if this isn’t t
hi David
Thank you for this protection, and I fully agree that we need to avoid
exceptional merges as much as possible.
For another, It seems we also require PRs to be up-to-date, which is good.
However, the side effect is cache misses. I recall you've done a lot of
work on improving the cache, s
We had a hiccup today where a PR was merged due to a false positive "All
checks have passed" message in the UI. This message was displayed because
the labelling workflows had run and were successful. So, really the message
was correct -- all checks that had been run were successful. The problem
was
12 matches
Mail list logo
