Re: Travis CI merge request

Well... I see no other solutions to make future people happy. Can you
make a single commit request and rebase to master? I think I'll merge
it.

Frediano

2013/11/14 Marc Abramowitz <[email protected]>:
> Yeah, Travis creates a public/private key pair for each repo it does builds for. They provide a command line utility that will take ENVVAR=VALUE pairs and then it will append the encrypted strings (which hides both the name and the value) to the .travis.yml file.
>
> This encrypted stuff is hard-coded to work with the private key in the FreeTDS/FreeTDS GitHub mirror that I created. It will not work with forks that other people create and it will not work with PRs (this is intentional on Travis's part - otherwise folks could send PRs that do nasty things with the stuff you're trying to protect).
>
> So if people want to fork the GitHub repo...well this is sort of a dubious thing to do because usually people fork repos to send PRs and we do not want to accept GitHub PRs since GitHub is a read-only mirror and Gitorious is the canonical repo...but that aside, if people wanted to have forks on GitHub and have Travis CI run on them, they need to have their own SQL Server accessible in the cloud somewhere (which again will discourage people from going this route) but still...they will need to edit the .travis.yml in their fork and delete my encrypted stuff and replace it with their own.
>
> In other words, I expect no one to go through the trouble of setting up a GitHub fork and an accompanying SQL Server in the cloud, because it's a pretty big barrier to entry, but if they do, they can tweak their .travis.yml (potentially having to deal with an occasional merge conflict if there are upstream changes) and it should work.
>
> I'm not too worried about this use case, because I don't think there are many people crazy enough (aside from myself :-)) to set up SQL Server in the cloud just so they can have automated tests.
>
> People that want to have CI on their own forks might be better off using their own private Jenkins server. I have this as well. I see Travis as being valuable for being the "official" CI for FreeTDS because the work of setting up the SQL Server in the cloud was done once and because Travis makes it easy to show your test results to the world.
>
> Hope that made sense :-)
>
> -Marc
> http://marc-abramowitz.com
> Sent from my iPhone 4S
>
>
> On Nov 14, 2013, at 8:28 AM, Frediano Ziglio <[email protected]> wrote:
>
>> Yes, you are right.
>>
>> From the file:
>>
>> - TDSVER=7.2
>> - secure: asqyeUGDEf1oYutUMfhz2t48SKXW/oNd3i29W/csPZaxJbv9Sx1kZbpSqd6LYPtOLB3yNyVNjzFe08fmN84i4Szq/NCtmIwOKBjdbZbT4G1+CH0apQ4HlqdKmZKyrrwtL5twcx1lLNk6YQyDZrSqgUr5FGUAZmNH1eCkdOLCOuk=
>>
>> How does it work? You have a key in the server which decrypt the secure stuff ?
>>
>> I noted there is no name specified so perhaps other people can just
>> add their key and expect to work as it cannot conflict with your. What
>> does documentation say about it ?
>>
>> Frediano
>>
>>
>>
>> 2013/11/14 Marc Abramowitz <[email protected]>:
>>> Where are we with:
>>>
>>> https://gitorious.org/freetds/freetds/merge_requests/14
>>>
>>> ?
>>>
>>> Personally, I’d love to see this merged, because Travis CI is not perfect
>>> but it’s better than nothing and because I invested a good bit of time into
>>> making this work.
>>>
>>> Marc
>>> http://marc-abramowitz.com/
>>> _______________________________________________
>>> FreeTDS mailing list
>>> [email protected]
>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds