freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Chris Bandy <bandy.chris AT gmail.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] Travis CI merge request
- Date: Fri, 15 Nov 2013 23:24:05 -0600
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
On Thu, Nov 14, 2013 at 10:59 AM, Marc Abramowitz <msabramo AT gmail.com>wrote:
> 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 <freddy77 AT gmail.com> 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 <msabramo AT gmail.com>:
> >> 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
> >> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
-
[freetds] Travis CI merge request,
Marc Abramowitz, 11/14/2013
-
Re: [freetds] Travis CI merge request,
Frediano Ziglio, 11/14/2013
-
Re: [freetds] Travis CI merge request,
Marc Abramowitz, 11/14/2013
- Re: [freetds] Travis CI merge request, Chris Bandy, 11/16/2013
-
Re: [freetds] Travis CI merge request,
Frediano Ziglio, 11/16/2013
-
Re: [freetds] Travis CI merge request,
Marc Abramowitz, 11/18/2013
-
Re: [freetds] Travis CI merge request,
Frediano Ziglio, 11/18/2013
-
Re: [freetds] Travis CI merge request,
Marc Abramowitz, 11/18/2013
- Re: [freetds] Travis CI merge request, Patrick McCoole, 11/18/2013
-
Re: [freetds] Travis CI merge request,
Marc Abramowitz, 11/18/2013
-
Re: [freetds] Travis CI merge request,
Frediano Ziglio, 11/18/2013
-
Re: [freetds] Travis CI merge request,
Marc Abramowitz, 11/18/2013
-
Re: [freetds] Travis CI merge request,
Marc Abramowitz, 11/14/2013
-
Re: [freetds] Travis CI merge request,
Frediano Ziglio, 11/14/2013
Archive powered by MHonArc 2.6.24.