|
Jonah,
+1 for fast-forward-only
In principle that could force one to rebase and then kick off
another CI Bot verification job, but that's not so likely to occur
much in practice.
Cheers,
Ed
On 13.11.2018 09:55, Jonah Graham
wrote:
Hi Ed,
If you want you can do a "Rebase" in the Gerrit UI before
doing the Submit.
Alternatively, and what I personally prefer is to set
gerrit's merge strategy to either Fast forward only, or
rebase. The Eclipse platform uses fast forward only. This
prevents any merge commits and ensures that the gerrit tests
the same version as is pushed. The merge strategy is a admin
preference on the repo, so something that webmaster/Fred would
have to change IIRC.
HTH,
Jonah
Hi
Ah! It never occurred to me that "Reply" meant "Commit" /
"Push" / "Merge" or even "Review". I saw only "Cherry
Pick" / " Cancel" which did not match my requirements.
What a truly awful UI.
What if I don't want to "Merge" since it leads to double
history entries that on normal projects are difficult to
disentangle? Ok, SimRel commits are highly orthogonal. But
Push gives a nice clean history and forces a Rebase that
just occasionally Merge can fail to replicate. IMHO if a
Merge is necessary the Gerrit Review should iterate.
Regards
Ed Willink
On
13/11/2018 05:46, Ed Merks wrote:
Ed,
Normally you would use the Gerrit review link to finish
the processing. E.g., for the last commit I used this
link:
https://git.eclipse.org/r/#/c/132049/
After the initial commit, I waited for the build to
finish so that CI Bot (one of the automatic reviewers)
adds a +1. That takes about 5 minutes. Then I used the
Reply... (or the Review +2 button, which will be there
after the successful build) to make it possible to
"Submit" the changes to master, i.e., the Submit button
will be there once all the reviewers (CI Bot and you)
have voted the changes up to the necessary level.
So the chain of events looks like this in the review:
![]()
After submitting, when I do a pull on the repo, my
changes are pulled and the repo is up-to-date (no longer
one commit behind master).
I believe a non-dilegent user could remove CI Bot from
the review to submit their changes even when those did
not pass the aggregation build but it appears to me that
there really is no good reason to allow direct push to
master as a way to completely bypass the CI Bot review.
Regards,
Ed
On
12.11.2018 22:04, Ed Willink wrote:
Hi
Sorry I must have missed something. My no doubt flawed
recollection was that we were assured (again) that
direct push would continue to be allowed.
I certainly use it every time since I see no other way
to do it.
I push to Gerrit, check for build success, then Push to
master.
Given that the bulk of failures are surely due to those
updating magic 'latest' contributions without any
commit, why change the rules for more diligent users?
Regards
Ed Willink
On 12/11/2018 17:34, Frederic Gurr wrote:
Hi,
As discussed before, direct push to master for the
SimRel aggregation
build repository
(https://git.eclipse.org/r/simrel/org.eclipse.simrel.build)
has been
disabled. So, all future commits have to go through a
Gerrit review and
should get a +1 from the CI server before being
merged.
The reasoning behind this is, that commits directly
pushed to master
caused build failures and delays in the past.
Please let me know, if you have any questions or
concerns.
Regards,
Fred
---
This email has been checked for viruses by Avast
antivirus software.
https://www.avast.com/antivirus
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
