Re: Appveyor Builds & Testing
Ramiro Morales <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <CAO7PdF9DWv_04-W+ThGRWurNgGaVSkg5E9pyXr5F3Fxfy_=1OA@mail.gmail.com> |
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. 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