I have pushed a fix in PR https://github.com/apache/pulsar/pull/17723 , please
review.
-Lari
On 2022/09/19 15:26:14 Lari Hotari wrote:
> Unfortunately a PR approval isn't currently detected by the solution
> Until this is fixed, the reviewer will have to add a "ready-to-test" label
> before add
Unfortunately a PR approval isn't currently detected by the solution
Until this is fixed, the reviewer will have to add a "ready-to-test" label
before adding a comment "/pulsarbot rerun-failure-checks" to the PR so that the
PR can be eventually merged.
I'm sorry about this inconvenience.
-Lari
I'll now merge the changes to master. The contributor docs will be updated in a
separate pull request. Current in progress pull requests will get the changes
when they are updated.
-Lari
On 2022/09/16 12:43:44 Lari Hotari wrote:
> On 2022/09/16 10:09:51 PengHui Li wrote:
> > After I go through
On 2022/09/16 10:09:51 PengHui Li wrote:
> After I go through all the comments here.
> Do we really need a new label?
Good suggestion. It was also suggested yesterday by Matteo that a PR approval
should be sufficient. I have modified the solution in
https://github.com/apache/pulsar/pull/17693 so
Thanks, Lari
After I go through all the comments here.
Do we really need a new label?
It looks like if a committer thinks we should trigger the CI in the Pulsar
repo
- Passed in the fork repo
- No request change for this PR.
- ...
Just run the "/pulsarbot ready-to-test" or "/pulsarbot trigger-c
I have created a draft PR for making the changes in Pulsar CI:
https://github.com/apache/pulsar/pull/17693
I'm looking forward to further practical improvements. I'd like to remind
everyone that we must make this change to address the CI slowness. After this
change, the experience of Pulsar CI w
Hi Lari,
This is a good idea, I agree with that.
Once the committer added a "ready-to-test" label to a PR, then the
contributor can run the Pulsar CI.
Thanks,
Zixuan
Lari Hotari 于2022年9月15日周四 23:30写道：
> On 2022/09/15 15:09:59 Yubiao Feng wrote:
> > Hi Lari:
> >
> > That is really a good way.
On 2022/09/15 15:09:59 Yubiao Feng wrote:
> Hi Lari:
>
> That is really a good way.
> I think it is possible to add another button to cancel the running task.
> because after the user submits the PR, he finds other problems that need to
> be fixed. In this case, he can cancel the task by himself.
Hi Lari:
That is really a good way.
I think it is possible to add another button to cancel the running task.
because after the user submits the PR, he finds other problems that need to
be fixed. In this case, he can cancel the task by himself.
Hi tison:
> we can start with all "authorized" users
Good explanation! I agree.
Thanks,
Yunze
> On Sep 15, 2022, at 19:42, Lari Hotari wrote:
>
>> I’m a little confused about what will CI do in this case? I think the
>> “ready-to-test” label should
>> be removed in this case because the new code might not pass the tests. I
>> thought the aut
> I’m a little confused about what will CI do in this case? I think the
> “ready-to-test” label should
> be removed in this case because the new code might not pass the tests. I
> thought the author
> should request committers to add this label again after the tests passed in
> his own repo.
Th
> If there are later changes in the PR after the "ready-to-test" label has been
> added, we could simply let the Pulsar CI handle the builds.
I’m a little confused about what will CI do in this case? I think the
“ready-to-test” label should
be removed in this case because the new code might not
> In short, IIUC, each contributor should:
> 1. Follow https://pulsar.apache.org/contributing/#ci-testing-in-your-fork to
> 2. Paste the link of the same PR in contributor’s fork to the PR in Apache
> repo
>
> Then a committer should run `/pulsarbot ready-to-test` after the PR in
> contributor's
Hi Lari,
This proposal LGTM. But I have some questions about the details.
In short, IIUC, each contributor should:
1. Follow https://pulsar.apache.org/contributing/#ci-testing-in-your-fork to
2. Paste the link of the same PR in contributor’s fork to the PR in Apache repo
Then a committer should
> One more comment: you should take `/pulsarbot run-failure-checks` into
> consideration. It's now triggered by any actors and signals a rerun on
> behalf of @codelipenghui. Following your proposal I suggest this manner
> should be restricted also. And it actually means that our committers should
>
Thanks for the comment.
The question isn't about trusting PRs.
The CI resource consumption problem is also caused by current committer PRs.
That's why it
is necessary to handle all PRs in the same way.
The benefit of the proposed solution is that we could decide to run some light
checks automati
One more comment: you should take `/pulsarbot run-failure-checks` into
consideration. It's now triggered by any actors and signals a rerun on
behalf of @codelipenghui. Following your proposal I suggest this manner
should be restricted also. And it actually means that our committers should
be more a
Hi Lari,
Thanks for starting this discussion. The overall proposal looks good and
it's really great that you can spend some time on such a significant
infrastructure.
One comment here is that we can start with all "authorized" users to
trigger the CI in the committer group instead of introducing
18 matches
Mail list logo
