Yeah. I don’t like that really. I’ll live with it. I think I can trigger from Travis, if I want to.
Are we looking to move over to azure pipelines permanently or do we want to try and see what can be done on the Travis side. I’m hoping the first WWDC I’ve missed in 4 years will reveal some kind of CI improvement from their purchase of buddy build. It might be all iOS though, and while that helps me at work, it does me no good here. —Mark On Sun, May 19, 2019 at 5:59 PM Saagar Jha <saa...@saagarjha.com> wrote: > If you have commit access to MacPorts and the pull request author allows > it > <https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork>, > you can rebase their fork's branch (for example, with git commit --amend > --no-edit) and trigger a new CI build. I’d ask before doing this though, > since it’ll kill their Git history. > > Saagar Jha > > On May 19, 2019, at 14:21, Rainer Müller <rai...@macports.org> wrote: > > On 19.05.19 20:45, Christopher Chavez wrote: > > On 5/19/2019 1:40 PM, Mark Anderson wrote: > > making it possible to re-run CI from GitHub commits. > > > As a PR submitter, one workaround I'm aware of is rebasing the PR > commit(s). I'm not sure that's something members can/should try though, > so a better solution is probably still preferred… > > > I would not consider this a workaround, but the best choice we have. > > Re-running the build with the exact same revision would not be that > useful. Without changes to the source, I would expect the same result. > As the ports tree and therefore the dependencies have usually advanced > since the PR was submitted, it makes sense to do a rebase first before > attempting another build. > > In theory it is possible to restart a build on the Travis CI web > interface with the same revision, but I am not even sure if all members > have access to that? > > Rainer > > > -- Sent from Gmail Mobile on iPhone