Re: Appveyor Builds & Testing

2015-07-22 12:25 GMT+01:00 Ramiro Morales <[email protected]>:
> On Tue, Jul 21, 2015 at 5:53 PM, Frediano Ziglio <[email protected]> wrote:
>> 2015-07-20 16:46 GMT+01:00 Randy Syring <[email protected]>:
>>> 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.
>

I did some progress, see
https://ci.appveyor.com/project/FreeTDS/freetds/build/41
Basically:
- account setup correctly;
- odbc tests now works (one left does not pass);
- registration with regsvr32 now works (strange);
- iconv (the one you compile) is now linked in

> 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.)
>

I don't know if I did everything in the right way but works.

> 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.
>

Done

> 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.)
>

Done

> 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.
>

I'll try it. Is quite weird the linker warnings about libraries (mix
of debug and release)

> 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
>

Yes, fixed in master

> 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.
>

Obviously it will be merged.

> 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.
>

Not clear here what you mean.

> 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

Frediano