Addressing Port submission failures on Travis
Ken Cunningham
ken.cunningham.webuse at gmail.com
Wed Dec 20 08:04:44 UTC 2017
keep the master branch up to date, but leave your PR branch alone until it's merged, then delete the branch.
> On Dec 19, 2017, at 11:54 PM, Andrew L. Moore <slewsys at gmail.com> wrote:
>
> I’m thinking that rebasing against my GitHub fork of MacPorts is what sent my pull request into a tail spin (second question below). If so, then it appears that I need to maintain two MacPorts clones: a private one for rebasing that only I see, and another on GitHub for submitting pull requests. Is there a more efficient workflow?
> -AM
>
>> On Dec 20, 2017, at 2:22 AM, Andrew L. Moore <slewsys at gmail.com> wrote:
>>
>> Hi,
>> A couple weeks ago, I made a couple Port submissions (devel/libwebsockets and net/mosquitto). Travis is reporting build failures for Xcode 7 and 8. I don’t, unfortunately, have the resources to easily test on other systems, and the Travis report doesn’t seem to offer much guidance what the issue is, at least that I could see. How to proceed?
>>
>> On a separate note, I notice that my pull request appears to be tracking my entire macports-ports fork, which includes changes to several other ports. Should I create a new fork for each pull request?
>>
>> For reference, here’s what i did:
>>
>> * Created a fork of macports-ports on GitHub
>>
>> * Cloned that fork to my local system
>>
>> * Added an upstream reference (https://github.com/macports/macports-ports.git)
>>
>> * Then to sync with upstream, I use:
>>
>> git fetch upstream
>> git rebase upstream/master
>>
>> * And to push to my GitHub fork, I just use:
>>
>> git push
>>
>> Got now my pull request appears to have picked up all that activity. Where did I go wrong?
>> -AM
>>
>>
>
More information about the macports-dev
mailing list