Home → Problems →

Need to Dynamically Set publish_wap_octopus

• Edit

chris.harbert

Apr 01, 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!

build:
  publish_wap_octopus: # TRUE or FALSE depending on Environment variable
  ...

1. 1 Posted by Ilya Finkelshte... on Apr 01, 2019 @ 10:16 PM

   

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

   Ilya.

   • Edit

2. 2 Posted by chris.harbert on Apr 01, 2019 @ 10:28 PM

   

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

   Thanks!

   Chris

   • Edit

3. 3 Posted by chris.harbert on Apr 01, 2019 @ 11:28 PM

   

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

   for:
   -
     branches:
       only:
         - <branchName>
     build:
       publish_wap_octopus: true
   

   • Edit

4. 4 Posted by Ilya Finkelshte... on Apr 01, 2019 @ 11:33 PM

   

   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.

   • Edit

5. 5 Posted by chris.harbert on Apr 02, 2019 @ 05:02 PM

   

   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?

   for:
   -
     branches:
       only:
         - develop
     build:
       publish_wap_octopus: true
   

   • Edit

6. 6 Posted by Ilya Finkelshte... on Apr 02, 2019 @ 05:57 PM

   

   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.

   • Edit

7. 7 Posted by chris.harbert on Apr 02, 2019 @ 06:45 PM

   

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

   init:
     - ... set env variable
   
   for:
   -
     environment:
       env_var_key: env_var_value
   
     build:
       ....
   

   • Edit

8. 8 Posted by Ilya Finkelshte... on Apr 02, 2019 @ 07:30 PM

   

   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?

   • Edit

9. Ilya Finkelshteyn closed this discussion on Jun 02, 2019 @ 09:01 PM.