APPVEYOR configuration problem in Seamly build

@schwowsers I was looking into the appveyor configuration. It wasn’t working when I tried my first push in August. I have not followed up to find out what exactly needs to be changed. I believe it has something to do with the 2017 version of the visual studio tool becoming the default for the pipeline environment. I think it should be fixed by adding an environment variable to the appveyor.yml file but I have not had the time to figure out a precise fix.

2 Likes

There are a couple issues with the Appveyor script. The switch to Visual Studio 2017 is one of them. I know what that problem is and can fix it tomorrow. The other issue is that it appears the wrong password is being used to extract the encrypted seamly.7z file. Whomever has access to the Appveyor project settings, please verify the PFX7z_PASSW password works and that it is entered correctly in the Appveyor project’s encrypted variables.

3 Likes

I will watch for the change in the visual studio 2017 setup in the appveyor script and I will then take a look at the PFX7z_PASSW information. When I looked at this back in August, I noticed both problems as well, but when I did a quick and dirty workaround for the environment variable I noticed that there seemed not to be a problem with the password. I did not have the time then to chase this down to completion but I will help do so now.

thank you for your help with this issue

2 Likes

I know Visual Studio 2017 changed the directory structure, so the tools for setting the environment variables for the command line were moved. I thought that was the only issue with the move to VS 2017, but it’s not :frowning: . The 64-bit version will compile successfully if I remove checkWarnings from the build command, which can be fixed / worked around, but the 32-bit version appears to have an issue with Qt versions less than 5.9.7. Appveyor’s current version of Qt 5.9 is 5.9.5.

So, I figured I’d switch the config to use VS 2015 again. That didn’t work, either. Warnings are treated as errors for the purposes of the Appveyor builds. Microsoft added a warning to help protect against the Spectre vulnerability, and it appears some parts of the codebase trigger this. Someone should check the flagged areas to see if they are actually flawed or if they’re false positives. I can look into it this weekend. In the meantime, I can temporarily disable the warning by adding it to the list in the common.pri. I’ll submit a pull request with the temporary fix in the morning.

2 Likes

thanks for working on this. I had intended to switch the environment to use vs 2015 and also to look into any other things that may have changed. I plan on meeting with some folks involved in the initial builds right after the main Seamly2d fork from Valentina to see what else might bear investigation. this will be on Sunday afternoon (Oct 7). I believe there were successful builds in January 2017 and unsucessful builds any time after I started looking at is (July 2017). I have not had the time to devote to find out everything that may have changed. I believe the changes that make the appveyor build fail are all in the appveyor environment, but the Visual Studio version is the only change that I was sure of. I will also have insight into the password issue after Sunday.

2 Likes

I created a pull request to switch back to Visual Studio 2015. I’ve tested the builds on my personal account (without the things specific to the Seamly account) and they succeed (MinGW build had no issues other than the 7z file, so I skipped it for testing).

The builds now fail due to the seamly.7z issue, and I’m really not sure what that is exactly. It’s not a password problem as I previously thought. The encrypted password has not changed, nor has the encrypted seamly.7z file. As you said, there were successful builds before, and there have not been any changes to the appveyor.yml file since then that would cause this issue. Could the SSL certificate have expired?

2 Likes

Ah, encrypted variables are not decrypted during pull request builds, so our current setup will always fail when checking a pull request, but could succeed when building commits to the main repository. I’ll look into changing the appveyor script to only do the signing stuff on non pull request builds. We’re almost there.

2 Likes

but could succeed when building commits to the main repository.

that makes sense because once I got added to the Seamly2D team officially, I pushed a commit that triggered a build in the develop branch (I had commented out the main branch so that I would “do no harm”). The build still failed on appveyor (studio 2017 vs 2015 issue) but the use of the zip signing stuff was successful and much more of the build worked. (logs showing this have disappeared because only the last 6 builds are kept)

You can still see on the github repository that my last successful build was triggered by: @KimMF

KimMF Merge pull request #164 from KimMF/investigate-appveyor

You can also see the artifacts in BINTRAY. The windows and Mac builds get stored there. The successful “Seamly2d-mac_release” “Seamly2d-win_release” files from January 2017 are still there. The “Seamly2d-mac_auto-upload” and “Seamly2d-win_auto-upload” files that I accidentally created from the develop branch build August 6 2018 are also there. I created place holders “Seamly2D-Mac-Daily-build” and “Seamly2D-Win-Daily-build” packages in bintray.

My intent was to use those daily build packages as a place to hold new builds from the appveyor pipeline so that we have a way to test changes before they get released in the auto-upload packages which is where the develop branch builds go.

I have an in person meeting at the home of @slspencer tomorrow where we intend to discuss the workflow for the builds. I hope we can finalize the process tomorrow.

I expect we will end up with a process that lets contributors such as yourself trigger a “daily-build” to get a testable package and hopefully there will be a designated integration tester who will merge all of the individual changes into “auto-upload” packages in the development branch. Then, eventually, changes will get released into the main branch and distributed.

2 Likes

@schwowsers you might want to take a look at this file

table-of-flows-pg2.pdf (22.4 KB)

I put this together as a tool to understand how all of the pipelines and builds fit together. I also have private copies of the seamly2d git repository on my personal machine (as you probably do as well)

I would love your input on the process so we can get this set up and someone who wants to work on code can do so without having to figure out how all the build mechanics work

2 Likes

I don’t really know much about these larger project management and distribution issues, so it’s all a bit overwhelming to me. I don’t know that I have any valid input on this stuff without first doing some serious research. And truthfully, I’d rather dive into fixing some bugs in the code :wink: . That said, I did update my pull request for issue 163 and appveyor is now working.

3 Likes

@slspencer and I are working on fixing the password issue. Also we are putting together some procedures to help make is clearer how to pull, fix, and push code. @schwowsers, could you please verify that you use the username ZoncaD on github. I hope that is true because otherwise I am confused. thanks

Also, do you run Ubuntu, Windows, or Mac? what operating system version?

1 Like

Yeah, that’s me on GitHub. Sorry, I didn’t think to menion that. I already included the password issue in my pull request for issue 163. It reverts back to using VS 2015, disables the spectre warning (temporarily), and works around the encrypted passwords for builds triggered by pull requests.

2 Likes

I forgot to mention that I am using Ubuntu 18.04.

2 Likes

no problem. It was actually fairly easy for my to figure out you were using the name because I read the content of your pull requests and the content of your forum messages. Just a check to make sure. thanks

1 Like

I’m talking with Appveyor right now, should have our apveyor settings defined properly within a few days. We’re emailing, so the round-trip time for answers takes a bit of time. :smiley:

1 Like

I will renew our yearly code signing certificate with Comodo ($167). It is due for renewal on Dec 14, but if I renew it now we can start clean with the appveyor passwords,

2 Likes

Ouch! but won’t you lose the 2 months still left on this year?

@grace It’s a tradeoff that we’ll just have to accept. My focus is to get the Appveyor build working.

1 Like

@slspencer do you have a date yet for the Comodo renewal? I will be back in town after an unexpected trip to deal with family issues. I will call you when I get back (before Oct 26)

1 Like

I decided to wait til this week to renew. The SSL certificate for seamly.cloud expires in 2 weeks. I will combine the SSL and Code Signing certificates in the same order.

1 Like