[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] what exactly does the PR job on jenkins build?
|
> What is the advantage of that? I see only disadvantage.
As with the other topic, there might be different views. So saying there
are "only disadvantages" might be claimed for nay of the solution
depending on who you ask.
For example you have some advantages/disadvantage for the one strategy
over the other:
1) The previous strategy triggered a rebuild of PRs on each and every
change on master, especially if there are a lot of (long standing) PRs
this considerably can block the build pipeline.
2) If there is a conflict you can't build the PR and need to
rebase/resolve/... first
3) Maybe more Pro/Cons
So as always it depends specially on the time a PR is lingering around,
I personally don't see any problem in keeping a PR on the "old" master
for the time of review (with many comments, commits, ...) and if we are
done squash and rebase and merge afterwards after the "final" build has
passed, the comments will still be retained in the PR history (with
original code).
Am 18.06.24 um 22:03 schrieb Stephan Herrmann via jdt-dev:
Am 18.06.24 um 21:30 schrieb Jörg Kubitz via jdt-dev:
Its a configuration that was changed by Andrey ~1 year ago, because he
wanted to see a tests on what exactly was submited.
What is the advantage of that? I see only disadvantage.
I assume every contributor tests locally exactly what he/she is going to
submit. Afterwards I want to know how the change will behave in master.
What is wrong with that?
As long as you
rebase to head - as we usually do - there is no rebase anyway.
I knew someone would say that :)
I know that people keep preaching this, but such repetition doesn't
improve github's support to work with review histories across force
push, which is lousy if you ask me.
But let's simply agree to disagree in this regard. I will continue to
require no-force-push on a PR while I'm reviewing, and let you do
whatever you think good. Let's keep the truce.
Perhaps the strategy for PR builds can still be discussed regardless of
the issue of force-push?
thanks,
Stephan
Am 18.06.2024 um 21:03 schrieb Stephan Herrmann via jdt-dev:
Some time I ago I checked that each PR build actually builds the
result of locally merging the PR with master (or whatever target
branch).
Re-checking today, it looks like the HEAD of the PR is built directly.
This would imply that a successful PR build does not inform us about
the result after the PR is eventually merged, which looks risky to me.
Has any such change been applied intentionally?
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev