FreeTDS Development Group

[Ramiro Morales <cramm0 AT gmail.com>]

On Tue, Jul 21, 2015 at 5:53 PM, Frediano Ziglio <freddy77 AT gmail.com> wrote:
> 2015-07-20 16:46 GMT+01:00 Randy Syring <randy AT thesyrings.us>:
>> Ha!  I forgot I opened that.
>>
>> Are you making any progress on FreeTDS windows binaries?  FYI, we have a
>> paid AppVeyor account which makes the builds go much faster vs the free
>> version.  I could set up FreeTDS and pymssql on our account if you think
>> that would be helpful.
>>
>
> Actually I was waiting for you. If you refer to my tries with MingW I
> usually use it to do some test, I was just trying to compile under
> Fedora using static win-iconv instead of dynamic one to avoid having
> to copy dll while doing tests.
>

[wall of text warning :)]

The FreeTDS AppVeyor builds aren't perfect but are perfectly usable
(and IMHO useful).

My problem is that if I'm a a bit when twisted when explaining things
in Spanish, then even much more in English so it seems until now I
haven't been able to convey a full description of the status of this.

I will try to itemize so to be more clear:

1. What is missing?

a) The ability to link in an implementation of iconv under Windows, b)
The ability of uploading the artifacts/builds somewhere else e.g.
GitHub and c) Fix the problem by which the test_script section of
appveyor.yml can't install the ODBC driver and so get the ODBC tests
to run successfully.

2. Are these missing things critical? IMHO not. The setup can be
useful right now. See item 5 below.

3. What pieces have been merged in already into FreeTDS?

Most of it. Frediano merged my PR a few weeks ago to the master branch
and the misc/appveyor.yml file plus its helper files are already part
of the tree.

4. What the FreeTDS project needs do to get the CI setup to actually
trigger builds on AppVeyor?

a) An owner of the GitHub organization/project (Frediano?) should
create a free account on AppVeyor for the FreeTDS organization/user.
This can be done easily as AppVeyor allows one to use GitHub
federated/oauth auth. The result will be the ability to create a
https://ci.appveyor.com/project/FreeTDS/freetds URL/project associated
with the FreeTDS/freetds GitHub repo (similar to how I have
https://ci.appveyor.com/project/ramiro/freetds which is the one I use
to work on this.)

What would this achieve? This GitHub-Appveyor association will allow
that every commit to master branch in GitHub triggers a git checkout
and a build from an AppVeyor build slave.

b) Important: Once the freetds project is created on AppVeyor then the
web UI for editing its settings should be used to configure so it
lookups appveyor.yml in misc/ instead of in the root of the tree (the
default.)

c) Merge in the https://github.com/FreeTDS/freetds/pull/17 PR which is
the first fixup to the AppVeyor infrastructure. It modifies
appveyor.yml so it can detect automatically the version of the Windows
OpenSSL binaries published by Shining Light Productions at
https://slproweb.com/products/Win32OpenSSL.html. Currently the version
needs to be updated manually by editing the OPENSSL_VER envvar and for
instance it's value is now 1.0.2c but the available binaries are
1.0.2d.

5. What's the current CI status?

AFAICT the last commit that built successfully on AppVeyor (Windows +
Visual C compilers (x86/x64) + OpenSSL + SQL Server 2008) is
https://github.com/ramiro/freetds/commit/b70875f6ffad487e82300f8813a2ebc4f019029b.
See https://ci.appveyor.com/project/ramiro/freetds/build/220

OTOH a later master revision
(https://github.com/ramiro/freetds/commit/d170981ad449ff845d8482c84cef4e01e816af64)
fails when trying to compile the first .c file:

https://ci.appveyor.com/project/ramiro/freetds/build/230/job/hecy80f0pnghbxko#L404

So it seems some of the changes in master between
b70875f6ffad487e82300f8813a2ebc4f019029b and
d170981ad449ff845d8482c84cef4e01e816af64 broke building on Windows
with MS toolchains.

6. How did I set up things to work on this?

a) I created an 'appveyor' Git branch in my GitHub fork of freetds.

b) I set up Appveyor as explained in item 4 above, every new
'appveyor' branch commit I pushed to GitHub while working on the
AppVeyor integration feature triggered a new build.

c) In order to be able to also get changes committed to the FreeTDS
official repository to be built I periodically merged in changes from
master or simply rebased my 'appveyor' branch on top of master.

If at this point anyone creates an AppVeyor account and performs these
steps (plus item 4 above) then he/she can have a Windows CI
environment for FreeTDS but reusing the work already done.

This works for an an individual contributor, but not so much for a
project like FreeTDS because it depends on a manual step (the
merge/rebase one) which needs to be performed periodically by a human.
This goes against one basic characteristic of CI which is to
automatically attempt building the project after every change.

This causes for example that once a regression occurs there is no
granularity to know which of the intermediate commit (between the
merges/rebases) is the culprit. See item 5 above for an example.

This is why IMHO it would be great if Frediano can implement what's
described in item 4 above.

HTH and keep the good work!

Regards,

-- 
Ramiro Morales
@ramiromorales