Skip to main content

[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


Back to the top