How to auto build App Y when Library X builds (and upgrade App Y's reference to Library X before)?
Folks -
Whats the best way to structure appveyor projects to handle a situation where we want a successful build of a common library to trigger a couple of other projects that actually consume this library? I have borrowed from the Deployment Project approach and now have the ability to trigger other projects but before those builds are initiated, I want them to upgrade their <PackageReference> to the latest version of this common library (which is being exposed via a private nuget account feed on appveyor).
In other words, I would like:
1) a successful build of Library X (generating version N+1) to trigger the build of App Y and App Z
2) but make sure that App Y and App Z have both upgraded their
<PackageReference Include="Library X" Version="N"/>
to <PackageReference Include="Library X" Version="N+1"/>
All the projects in question are targeting .netcoreapp2.0. And of course App Y and App Z should also do a normal build if any of their direct code base has changed.
Has anyone dealt with this situation and if so - what's the recommended way of handling this?
Thanks very much
Rajiv
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
1 Posted by Ilya Finkelshte... on 13 Jul, 2018 06:49 PM
Per my knowledge
<PackageReference Include="Library X" Version="*"/>
should always restore latest package, can you try"*"
instead of"N"
?2 Posted by rajiv on 15 Jul, 2018 07:44 PM
Thanks Ilya! While '*' doesn't seem to work, other format variations such as Major.minor work. The full reference: https://docs.microsoft.com/en-us/nuget/reference/package-versioning#version-ranges-and-wildcards
rajiv closed this discussion on 15 Jul, 2018 07:45 PM.
rajiv re-opened this discussion on 24 Jul, 2018 01:41 AM
3 Posted by rajiv on 24 Jul, 2018 01:41 AM
Re-opening this because although the native PackageReference capabilities of including version N or higher (instead of a precise version) work fine, the overall solution isn't working.
The expected mechanics here are:
a) Library X is currently at Version 2.1.73
b) App Y and App Z both include <PackageReference Include="LibraryX" Version="[2.1.73+]"/>
c) Library X build is triggered and this generates a new version 2.1.74
d) Library X build completion triggers the build of App Y and App Z
e) I would expect App Y and App Z to resolve to Library X Version 2.1.74
f) But it does not. It still resolves to 2.1.73
Is there some sort of delay in Version 2.1.74 to become visible in the private Nuget feed for our Appveyor account? Could that be the reason why its not resolving to the latest version?
Thanks very much
Rajiv
4 Posted by Ilya Finkelshte... on 24 Jul, 2018 11:36 AM
Yes it can be a delay. Sorry I should have mention this earlier. AppVeyor uploads nuget artifacts to feed asynchronously. So successful artifact upload does not mean that package is available in account feed immediately.
I recommend first rerun builds for App Y and App Z manually and if you see that they now take Version 2.1.74, then indeed problem is a delay. In this case I propose the following workaround:
pass expected new version to newly created build as environment variable. Please see this sample
Add a blocking script to
init
stage which will wait this version to appear innuget list
output. Something like this:Where
ExpectedVersion
is environment variable passed when starting build. You also will probably make this script more verbose and add some timeout to avoid infinite loop, but you got the idea.Let us know if this works for you.
5 Posted by rajiv on 24 Jul, 2018 12:47 PM
Thanks Ilya. Since this is obviously a private nuget feed, how would we pass the credentials in a non-interactive mode to that nuget list -source command? And preferably not as clear text.
6 Posted by Ilya Finkelshte... on 24 Jul, 2018 01:26 PM
I do not think you need to pass them as you should have already configured nuget feed for App Y and App Z projects. But for other cases like this it is useful to be aware of secure variables.
7 Posted by rajiv on 26 Jul, 2018 05:08 PM
Thanks Ilya. After trying a few things - I managed to get that working. Now the only issue left is that these builds of App Y and App Z are being triggered even if the build of Library X fails. I am using on_success. Is there a different key to use in the yaml ?
Thanks
Rajiv
8 Posted by Ilya Finkelshte... on 26 Jul, 2018 05:19 PM
on_success
should not be called if build fails. When you are saying "build of Library X fails", does this mean that AppVeyor build is "red"? Or maybe script building Library X fails but swallows error somehow and AppVeyor build is actually "green"?9 Posted by rajiv on 26 Jul, 2018 05:30 PM
Never mind - I tried to reproduce what I saw yesterday and unable to do so. All is well. Thanks again for your help!
10 Posted by Ilya Finkelshte... on 26 Jul, 2018 05:40 PM
You are welcome! Also App Y and App Z can be triggered in case they are in the same repo as X, simple by webhook. In this case, you can use commit files filtering.
11 Posted by rajiv on 26 Jul, 2018 07:53 PM
Thanks Ilya. In this case they are not in the same repo. A related question: Just like we can trigger an appveyor build using Start-Appveyor-Build, is there an equivalent Cancel-Appveyor-Build which we could use to stop any already running builds (since they will be triggered again by Start-Appveyor-Build anyway)?
12 Posted by Ilya Finkelshte... on 26 Jul, 2018 10:36 PM
There is no such command (and build worker API), but you can this with service REST API. However you have to know build version of the build you need to cancel. What is bigger scenario here? Maybe you can simple set up rolling builds?
13 Posted by rajiv on 26 Jul, 2018 10:52 PM
Thanks again! I wasn't aware of the Rolling Builds feature - thats exactly the behavior I was looking for i.e. if multiple back to back commits are resulting in the same projects being built, cancel everything except the latest commit.
Also Build Prioritization is a nice feature that I'm trying out to ensure stuff in a dependency chain that's auto triggered gets built in the right order.
Ilya Finkelshteyn closed this discussion on 27 Aug, 2018 06:22 PM.