[freetds] Travis CI merge request

Discussion:

Marc Abramowitz

2013-11-14 16:21:16 UTC

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/

Frediano Ziglio

2013-11-14 16:28:50 UTC

Permalink

Yes, you are right.
- 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

Post by Marc Abramowitz
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
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Marc Abramowitz

2013-11-14 16:59:52 UTC

Permalink

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

Post by Frediano Ziglio
Yes, you are right.
- 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

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Chris Bandy

2013-11-16 05:24:05 UTC

Permalink

That's a very good explanation, Marc. I have used Travis CI's secure
environment variables[1] in a small project of mine as well. I invite
others to look at it to see how these variables work:

1. The .travis.yml file contains an "env" entry that is a key/value pair
(rather than a string)[2]. The value is encrypted as Marc described.
2. In my case, the value contains two environment variables. During the
build, Travis CI logs these as "[secure]"[3].
3. All scripts, commands, software, etc of the build are run with these
environment variables set (in plaintext). In my case, download.js fetches
the values from the "env" object.

[1]
http://about.travis-ci.org/docs/user/build-configuration/#Secure-environment-variables
[2] https://github.com/cbandy/travis-oracle/blob/master/.travis.yml
[3] https://travis-ci.org/cbandy/travis-oracle/builds/9338163 (see lines 6
and 7)

-- Chris

Post by Marc Abramowitz
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

Post by Frediano Ziglio
Yes, you are right.
- TDSVER=7.2

asqyeUGDEf1oYutUMfhz2t48SKXW/oNd3i29W/csPZaxJbv9Sx1kZbpSqd6LYPtOLB3yNyVNjzFe08fmN84i4Szq/NCtmIwOKBjdbZbT4G1+CH0apQ4HlqdKmZKyrrwtL5twcx1lLNk6YQyDZrSqgUr5FGUAZmNH1eCkdOLCOuk=

Post by Frediano Ziglio
How does it work? You have a key in the server which decrypt the secure

stuff ?

Post by Frediano Ziglio
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

Post by Marc Abramowitz
https://gitorious.org/freetds/freetds/merge_requests/14
?
Personally, I?d love to see this merged, because Travis CI is not

perfect

Post by Frediano Ziglio

Post by Marc Abramowitz
but it?s better than nothing and because I invested a good bit of time

into

Post by Frediano Ziglio

Post by Marc Abramowitz
making this work.
Marc
http://marc-abramowitz.com/
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Frediano Ziglio

2013-11-16 15:37:07 UTC

Permalink

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

Post by Marc Abramowitz
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

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Marc Abramowitz

2013-11-18 16:55:10 UTC

Permalink

Cool! Here you go:

https://gitorious.org/freetds/freetds/merge_requests/20

Cheers,
Marc

Post by Frediano Ziglio
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

Post by Marc Abramowitz
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.

Post by Marc Abramowitz
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).

Post by Marc Abramowitz
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.

Post by Marc Abramowitz
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.

Post by Marc Abramowitz
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.

Post by Marc Abramowitz
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.

Post by Marc Abramowitz
Hope that made sense :-)
-Marc
http://marc-abramowitz.com
Sent from my iPhone 4S

Post by Frediano Ziglio
Yes, you are right.
- TDSVER=7.2

asqyeUGDEf1oYutUMfhz2t48SKXW/oNd3i29W/csPZaxJbv9Sx1kZbpSqd6LYPtOLB3yNyVNjzFe08fmN84i4Szq/NCtmIwOKBjdbZbT4G1+CH0apQ4HlqdKmZKyrrwtL5twcx1lLNk6YQyDZrSqgUr5FGUAZmNH1eCkdOLCOuk=