publish_wap_octopus affect only artifacts packaging, not actual deployment. You need to look into conditional deployment.
This will leave you with artifacts packaged on every branch build but deployed only on specific ones. If you do not like it, use branch specific configuration so artifact will not be even packaged on branches you do not want (and save our storage by the way :)).
on 01 Apr, 2019 10:28 PM
We still want to deploy in both cases, so we need to generate the artifact in both cases. With publish_wap_octopus the artifact gets renamed from "Website.zip" to "Website.##.##.#.####.zip" and the Type is "Octopus package", which is causing the downstream build process to fail.
If there isn't a way to set publish_wap_octopus to false for some builds, can I prevent the artifact from getting renamed?
This should work... Can you share full YAML? Also more details about your scenario will not hurt. Specifically I do not understand in which case "Website.zip" renamed to "Website.##.##.#.####.zip" and how this affects downstream build process.
Both PR and merge to the develop will have branch property set to develop, so branch name is not a way to distinguish between them.
We have number of APPVEYOR_PULL_REQUEST_*environment variables which can be used as a condition, but in your case it seems to lead to many IFs and manual scripting.
What I would propose you is not ideal, but can work. Create 2 projects, each target the same repository, but specific custom YAML file. Check Do not build on "Push" events for one of those projects and Do not build on "Pull request" events for another. All those settings (including custom YAML file) are UI-only and located on the General Settings tab.
Disadvantage of this is 2 separate build histories and configuration duplication, but this is the only thing we can propose you without manual scripting.
P.S. We will think about for.pullrequests construct.
No... We have matrix.for but it is other way around, can work for variables declared in the matrix. When for construct is being used, build configuration is formed before build starts and at that moment it has no idea about what can be set at init stage. Please watch this issue, but we cannot do any promises about ETA.
Do you believe two projects will work for you for now?