[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
|
EclipseMost of this has nothing to do with Github in general so there is
no "canonical place" for everything but maybe this still helps:
> rebuild a PR unchanged
1) Jenkins Build: You need to log into the Jenkins instance with your
Eclipse account for the Jenkins build and then you can restart the job
if you are a commiter of the project
2) EMO Checks: You need to click on the Check, login with your Eclipse
account and choose "recheck ECA"
3) Github Actions: You click on the action and choose "rerun" from the
menu:
https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs
4) something else: Depends on what you want
> - rebase a PR on HEAD and rebuild
Simply rebase your change and push it, if enabled and you have
appropriate access right, you can use the "rebase button":
https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/
> In GitHub it seems to be popular to just force-push the latest and
greatest, which seems like reviewers will have to start reviewing from
scratch, or is there some magic incantation that will show them
differences between the current branch and one that no longer exists?
This is a pure committers choice, you can push several commits and
easily compare them and later on squash an merge them
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits
But you can also compare between force-pushed commits:
https://github.blog/changelog/2018-11-15-force-push-timeline-event/
Am 08.09.22 um 15:06 schrieb Stephan Herrmann:
It feels like I asked this before, but as I can't find this info in any
canonical place I will keep asking:
How can I tell github to
- rebuild a PR unchanged
(e.g., when a failure was intermittent, when a period check is outdated)
- when a jenkins build is still available
- after the jenkins build has been deleted
- rebase a PR on HEAD and rebuild
Please don't just answer here, but provide a link to the persistent,
canonical location where such information can be found. Hopefully, that
location can be remembered easily and will answer all related questions.
thanks,
Stephan
PS: Are there other tidbits committers should observe when working with
github? In the bugzilla era there was a lot of information we recorded
in each bug report, like Version and Target Milestone. Is JDT planning
to apply similar discipline in github? Are labels to be used in some
coordinated style?
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev