Now have a configuration which works when parameters are “true” for both build and deploy.
This builds and deploys
Prior topic: Config.yml conditional for build and deploying multiple environments
Then I sequentially changed run_workflow_deploy: to false (change) (result) This seems to work properly and none of the multiple environments deploy to cloudsmith.
and then run_workflow_build: to false (change) (result)
This does not seem to be working properly for some reason. There are not individual builds showing, but errors.
The next thing I tried testing was enabling one of the environment buster-armhf build=true
(result) This still seems to have ‘schema’ errors again, and buster-armhf build does not work properly.
The next thing I tried testing was enabling environment buster-armhf build=true and enabling buster-armhf deploy=true (result) The environment does not deploy and there are lots of schema errors.
How do I fix these problems?
You need to add a “fallback step” that handles the case where none of the conditions are met; for example: a simple
Here’s what it’d be for the
- image: 'circleci/android:api-28-ndk'
- OCPN_TARGET: android-armhf
- run: chmod a+x ci/*.sh
- run: bash ci/circleci-build-android-armhf.sh
condition: << pipeline.parameters.run_workflow_deploy >>
- run: ci/cloudsmith-upload.sh
- run: echo "deploying"
- run: echo "None of the conditions are met"
Also, note that you can use the CircleCI CLI to validate your
config.yml before attempting to run the build.
Let me know if this helps.
Dear YannCI, Thank you for your suggestion. A colleague has taken this effort some steps further, with more changes and testing, please see this link.
He responded to me as follows after a considerable amount of effort learning how this works/doesnt.
I did use the validate service when I was trying to get “when:” statements working in workflows. It is quite cumbersome and doesn’t really help. I would have preferred better documentation with more complex examples. I could not find the reference manual (or any real details) of the yaml being used, there were only a few simplistic examples. I had to just try anything I could think of to make it work. I ended up having multiple workflows each with a single job and controlling each workflow with a “when:”. If I moved the “when:” to the jobs part the image would be instantiated before it worked out that there was nothing to do. Using the workflow method the job never even starts. However, the definition of the bits to run at the front is not very “user friendly”.
:I hope this will be useful to the development team and to others. If you have additional suggestions to make this work better we would be very interested.
We often have one or two builds that we need to get working and test, and want to turn the other builds off, along with all deployments, until we get everything working.