Need to Dynamically Set publish_wap_octopus

Chris Harbert's Avatar

Chris Harbert

01 Apr, 2019 10:05 PM

I need the ability to run the octopus deploy on some branches, but not others. To do this, I think I need to be able to set publish_wap_octopus dynamically using an environment variable. I've also tried using "for:" but that doesn't seem to support adding a custom "build:" section. Any help here would be appreciated!

  publish_wap_octopus: # TRUE or FALSE depending on Environment variable
  1. Support Staff 1 Posted by Ilya Finkelshte... on 01 Apr, 2019 10:16 PM

    Ilya Finkelshteyn's Avatar

    Hi Chris,

    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 :)).


  2. 2 Posted by Chris Harbert on 01 Apr, 2019 10:28 PM

    Chris Harbert's Avatar

    Hello Ilya,

    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 "" to "" 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?



  3. 3 Posted by Chris Harbert on 01 Apr, 2019 11:28 PM

    Chris Harbert's Avatar

    I tried adding this to the bottom of my appveyor.yml and it doesn't seem to be working. What am I missing?

          - <branchName>
        publish_wap_octopus: true
  4. Support Staff 4 Posted by Ilya Finkelshte... on 01 Apr, 2019 11:33 PM

    Ilya Finkelshteyn's Avatar

    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 "" renamed to "" and how this affects downstream build process.

  5. 5 Posted by Chris Harbert on 02 Apr, 2019 05:02 PM

    Chris Harbert's Avatar

    I'm unfortunately not able to publish the full YML here.

    What we are trying to do is (1) run Octopus deploys on pull requests and (2) run Web Deploys on the merged builds. Any example you could provide of how this is supposed to work would be great.

    Should the following apply to both pull request builds and merge builds to develop? Is there any way to indicate it should only happen for PR or non-PR builds?

          - develop
        publish_wap_octopus: true
  6. Support Staff 6 Posted by Ilya Finkelshte... on 02 Apr, 2019 05:57 PM

    Ilya Finkelshteyn's Avatar

    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.

  7. 7 Posted by Chris Harbert on 02 Apr, 2019 06:45 PM

    Chris Harbert's Avatar

    Thanks. A for.pullrequests would be helpful here. Is there a environments condition? Something like?

      - ... set env variable
        env_var_key: env_var_value
  8. Support Staff 8 Posted by Ilya Finkelshte... on 02 Apr, 2019 07:30 PM

    Ilya Finkelshteyn's Avatar

    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?

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? 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