Home → Questions →

How to combine multiple yaml files (multiple build images, OS, compilers and scripts) into one

• Edit

human

01 Sep, 2019 02:02 PM

I'm currently using three projects because I found no good way to setup one project for the three build environments used. One of the projects has a manually build-matrix already and after trying to add to them and check the environment in each shell those became quite complex - and as one project uses a shell-script while the others use cmd-scripts it seems to be not possible as-is in any case.
I *guess* it may help to change all the scripts to powershell and by that removing this part, but I'm not sure this has a chance to work out at all.
Another issue is that the artifacts are not always the same...

I can totally live with removing the tags and with the special "skip mingw-rebuild" (the main issue here is that the artifact used must match the same version)

Ideally the end result would be:
* one appveyor.yml for all the three projects (which I then can commit to version control; filtering the branch can then be done in the yml file [this is currently completely missing])
* Ubuntu builds first with support for more than one CPU core (to allow testing multiple jobs during make)
* MinGW/Cygwin build later (they'd use an artifact of Ubuntu)
* ideally I get a clue how to add the missing MinGW64 environment to the set
* the notification mails include the actual environment that changed its state (if mingw and cygwin failed before [all others passed] and now all but mingw worked then a mail should be send out listing the working/broken environments)

I hope to find a good suggestion how to do this or even better a nearly working yml file.
Thank you very much.

• appveyor.yml 3.27 KB
• appveyor-2.yml 3.46 KB
• appveyor-3.yml 3.07 KB

1. 1 Posted by Wasa Pleshakov on 02 Sep, 2019 08:05 PM

   

   Let me try to address some of our questions:

   1. There is no need to combine all yamls into one for committing it to version control. you can commit them with different names and then set "Custom configuration .yml file name" setting in your projects.
      
   2. It is possible though quite tricky to set up several build jobs to wait for each other.
      

   3. Instead, may I suggest you split your build process between two projects:
      a. first one builds artifact in Ubuntu images and on success starts the second project via Appveyor REST API. b. the second project build with MinGW/Cygwin

      You may find working example in https://github.com/appveyor/build-images: a. first project is configured to use https://github.com/appveyor/build-images/blob/master/appveyor-conta.... It builds a docker image and on success starts a project named "build-images" and even pass a couple of variables to it. b. second project "build-images" uses https://github.com/appveyor/build-images/blob/master/appveyor.yml

   4. In appveyor-2.yml you can use Matrix job configuration and get rid of if "%BUILD_TYPE%" clauses.

   5. for notification emails have you looked into this little trick?

   • Edit

2. 2 Posted by human on 12 Sep, 2019 09:48 PM

   

   Thank you Wasa for the hints. I think I'm going with the approach of one "master" project and started build via API. One thing that I'm not sure about: how to pass the complete URL from an artifact in project A to project B?

   • Edit

3. 3 Posted by Owen McDonnell on 13 Sep, 2019 05:08 PM

   

   Can you clarify what you mean by "pass the complete URL from an artifact in project A to project B". Do you mean you want to download an artifact from one build into another?

   • Edit

4. 4 Posted by human on 13 Sep, 2019 06:37 PM

   

   > Do you mean you want to download an artifact from one build into another?

   Yes, totally. The only option I found so far is to always download the latest artifact (which always is translated to the actual url internally), but this results in multiple problems. It is important to have the URL that came from the original build in "project a" (especially for the case of rebuilds - where the same old artifact generated by the rebuild must be used, not the current one).

   @Owen: I guess $env:APPVEYOR_JOB_ID is part of the solution for this.

   • Edit

5. 5 Posted by Owen McDonnell on 14 Sep, 2019 04:14 AM

   

   There are several ways to do this depending on what differentiates the job from which you are trying to download an artifact.

   Here is the script from our docs. Here is a customized version for a user wanting to get the artifact from an Ubuntu build job. Here is a non powershell example.

   • Edit

6. Feodor Fitsner closed this discussion on 03 Apr, 2020 06:44 PM.