{"id":2936,"date":"2019-09-19T10:30:10","date_gmt":"2019-09-18T22:30:10","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2936"},"modified":"2019-09-19T10:38:05","modified_gmt":"2019-09-18T22:38:05","slug":"azure-devops-iterative-insertion-fixed","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2936\/","title":{"rendered":"Azure DevOps &#8211; Iterative Insertion Fixed!"},"content":{"rendered":"<span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">[Estimated Reading Time: <\/span> <span class=\"rt-time\">4<\/span> <span class=\"rt-label rt-postfix\">minutes]<\/span><\/span>\n<p>In <a href=\"https:\/\/www.deltics.co.nz\/blog\/posts\/2931\">yesterday&#8217;s post<\/a> I mentioned that I had been unsuccessful in using <a href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/devops\/pipelines\/process\/templates?view=azure-devops#iterative-insertion\"><strong>Iterative Insertion<\/strong><\/a> to simplify building for multiple <strong>Delphi<\/strong> versions.  Well, as so often happens, I had a flash of insight overnight and found the solution this morning!<\/p>\n\n\n\n<!--more-->\n\n\n\n<p class=\"has-drop-cap\">In the foot note of that previous post, I mentioned having used a different trick to preserve per-Delphi version specific build steps in my build jobs (to ease the process of identifying build failures in that eventuality).<\/p>\n\n\n\n<p>The &#8216;trick&#8217; was to create a local template for my builds.  This template is specific to my project build needs so doesn&#8217;t form part of the <a href=\"https:\/\/github.com\/deltics\/azure-pipeline-templates\">azure-pipeline-templates<\/a> library but sits in my repo alongside my main build pipeline:<\/p>\n\n\n\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"language-yaml\">parameters:\n  delphiVersion: &#039;&#039;\n  platform: &#039;x86&#039;\n\nsteps:\n- template: delphi-build.yml@templates\n  parameters:\n    delphiVersion: ${{ parameters.delphiVersion }}\n    platform: ${{ parameters.platform }}\n    project: tests\\Tests\n    preBuildInline: duget restore --noUnpack\n    postBuildInline: .bin\\Tests -f=.results\\Delphi.${{ parameters.delphiVersion }}.xml\n<\/code><\/pre>\n\n\n\n<p>This template in turn references the main <strong><a href=\"https:\/\/github.com\/deltics\/azure-pipeline-templates\/blob\/master\/delphi-build.yml\">delphi-build.yml<\/a><\/strong> template in GitHub.  It provides most of the parameters I need that do not vary regardless of the different Delphi versions I am building for.  It achieves variability in parameter values where needed by using template substitution.<\/p>\n\n\n\n<p>This is most obvious in the <strong><code>delphiVersion<\/code><\/strong> parameter, which is passed through from this template to the <strong>delphi-build<\/strong> template.  But it is also used to ensure that test results produced after a successful build are named for that <strong>delphiVersion<\/strong> also.<\/p>\n\n\n\n<p>This simple template already would allow me to greatly simplify my main <strong>build.yml<\/strong> for this project:<\/p>\n\n\n\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"language-yaml\">trigger:\n- develop\n- master\n\nresources:\n  repositories:\n    - repository: templates\n      type: github\n      name: deltics\/azure-pipeline-templates\n      ref: refs\/heads\/develop\n      endpoint: GitHubTemplates\n\npool:\n  name: &#039;The Den&#039;\n\nsteps:\n- template: gitversion.yml@templates\n\n- script: |\n    duget init\n    duget restore --path tests\n  displayName: &#039;Initialise DuGet&#039;\n\n# x86 builds ---------------------------------\n\n- template: build-with-version.yml\n  parameters:\n    delphiVersion: 7\n\n- template: build-with-version.yml\n  parameters:\n    delphiVersion: 2010\n\n- template: build-with-version.yml\n  parameters:\n    delphiVersion: xe4\n\n- template: build-with-version.yml\n  parameters:\n    delphiVersion: 10.3\n\n# x64 builds ---------------------------------\n\n- template: build-with-version.yml\n  parameters:\n    delphiVersion: xe4\n    platform: x64\n\n- template: build-with-version.yml\n  parameters:\n    delphiVersion: 10.3\n    platform: x64<\/code><\/pre>\n\n\n\n<p>Still pretty verbose, but a vast improvement on the original and much easier to maintain.<\/p>\n\n\n\n<p class=\"has-background has-luminous-vivid-amber-background-color\">You may note that my reference to the <strong>azure-pipeline-templates<\/strong> GitHub repository in this pipeline includes a <code>ref<\/code> property which results in this pipeline using the latest version from the <strong>develop<\/strong> branch, as I am developing this pipeline alongside making refinements to that GitHub template.  Once finalised (i.e. <strong>develop<\/strong> merged to <strong>master<\/strong>), this <code>ref<\/code> will be removed from this pipeline.<\/p>\n\n\n\n<p><strong>x86<\/strong> and <strong>x64<\/strong> builds still have to be specified separately as there is no assumption by the downstream templates that I wish to build for both architectures even if the specified Delphi compiler version supports <strong>x64<\/strong>.<\/p>\n\n\n\n<p>The next step is to introduce a further template which can &#8216;stamp out&#8217; these individual build steps for me.<\/p>\n\n\n\n<p class=\"has-drop-cap\">It turns out that the required template is itself very simply.  I had made two mistakes yesterday when first attempting this.  The first was not double-checking my (still developing) knowledge of YAML and ensuring that my array syntax was correct.  The second was over-looking a trivial but significant element in my iterative insertion syntax.<\/p>\n\n\n\n<p class=\"has-background has-very-light-gray-background-color\">In my defence, the errors these mistakes resulted in (e.g. <em>mapping not allowed here<\/em>) were again not especially helpful.<\/p>\n\n\n\n<p>Here&#8217;s the template I ended up with:<\/p>\n\n\n\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"language-yaml\">parameters:\n  delphiVersions: []\n  platform: &#039;x86&#039;\n\nsteps:\n- ${{ each version in parameters.delphiVersions }}:\n  - template: build-with-version.yml\n    parameters:\n      delphiVersion: ${{ version }}\n      platform: ${{ parameters.platform }}<\/code><\/pre>\n\n\n\n<p>This template assumes that I am building for <strong>x86<\/strong> but allows me to specify some other <code>platform<\/code> in a parameter.  It also expects that I will provide an <em>array<\/em> of <code>delphiVersions<\/code> that I wish to build.<\/p>\n\n\n\n<p>It then uses the iterative insertion feature of Azure DevOps pipelines to add a step for each of those <code>delphiVersions<\/code>.  Each of these steps uses the <strong>build-with-version.yml<\/strong> local template.<\/p>\n\n\n\n<p>I could have &#8216;bypassed&#8217; the <strong>build-with-version<\/strong> template and instead directly referenced the <strong>delphi-build.yml<\/strong> template, but this would only make sense if I were to then git rid of the <strong>build-with-version.yml<\/strong> entirely, otherwise I would have to keep both templates in sync if I ever needed to change the build properties for this project.  This way, I know that <strong>build-with-version.yml<\/strong> is the one place where my project build is essentially configured.<\/p>\n\n\n\n<p>With that done, here&#8217;s what my final build pipeline looks like for this project:<\/p>\n\n\n\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"language-yaml\">trigger:\n- develop\n- master\n\nresources:\n  repositories:\n    - repository: templates\n      type: github\n      name: deltics\/azure-pipeline-templates\n      ref: refs\/heads\/develop\n      endpoint: GitHubTemplates\n\npool:\n  name: &#039;The Den&#039;\n\nsteps:\n- template: gitversion.yml@templates\n\n- script: |\n    duget init\n    duget restore --path tests\n  displayName: &#039;Initialise DuGet&#039;\n\n- template: build-all.yml\n  parameters:\n    delphiVersions: [ 7, 2006, 2007, 2009, 2010, xe, xe2, xe3, xe4, xe5, xe6, xe7, xe8, 10, 10.1, 10.2, 10.3 ]\n\n- template: build-all.yml\n  parameters:\n    delphiVersions: [ xe2, xe3, xe4, xe5, xe6, xe7, xe8, 10, 10.1, 10.2, 10.3 ]\n    platform: x64\n<\/code><\/pre>\n\n\n\n<p>I still need to specify <strong>x86<\/strong> and <strong>x64 <\/strong>builds separately but can now specify <em>all<\/em> Delphi versions for each platform in a single step.<\/p>\n\n\n\n<p class=\"has-background has-pale-pink-background-color\">You may be wondering why the <code>&lt;strong&gt;resources&lt;\/strong&gt;<\/code> section is not also needed in the <strong>build-with-version<\/strong> template.  The answer is that <strong><code>resources<\/code><\/strong> can <em>only<\/em> be declared in the initial pipeline, and not in a template.  i.e. a pipeline must declare up-front any resources that any referenced templates need <em>and that&#8217;s still the case even if the pipeline itself does not directly reference those resources itself!<\/em><\/p>\n\n\n\n<p>When the build actually runs, those two steps are transformed into multiple, individual build steps, <em>one for each Delphi version<\/em>.  Each step is helpfully named in the build logs for the Delphi version and target platform, so if a change breaks this project only for specific versions of Delphi, I can see at a glance which version is affected!<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" loading=\"lazy\" width=\"640\" height=\"340\" src=\"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2019-09-19-at-10.22.35.png?resize=640%2C340&#038;ssl=1\" alt=\"\" class=\"wp-image-2937\" srcset=\"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2019-09-19-at-10.22.35.png?w=773&amp;ssl=1 773w, https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2019-09-19-at-10.22.35.png?resize=300%2C160&amp;ssl=1 300w, https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2019-09-19-at-10.22.35.png?resize=768%2C408&amp;ssl=1 768w, https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2019-09-19-at-10.22.35.png?resize=380%2C202&amp;ssl=1 380w\" sizes=\"(max-width: 640px) 100vw, 640px\" data-recalc-dims=\"1\" \/><\/figure>\n\n\n\n<p>As you can see, currently the build will abort at the first failure with any given Delphi version; subsequent build steps are not performed, unless they have a <code>condition<\/code> applied to force them.<\/p>\n\n\n\n<p>I started looking at how to add such a condition and things quickly become  quite messy.  In particular, Delphi builds should only be forced if any current failure was a previously failed <em>Delphi build<\/em>.  If there was some other, earlier failure in the build pipeline then I would not wish to force in that case.<\/p>\n\n\n\n<p>A tricky problem and one I may return to at some point in the future.  But not today.<\/p>\n","protected":false},"excerpt":{"rendered":"<p><span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">[Estimated Reading Time: <\/span> <span class=\"rt-time\">4<\/span> <span class=\"rt-label rt-postfix\">minutes]<\/span><\/span> I figured out the iterative insertion problem and my build pipeline is now TIGHT!  Fixing it was super-easy in fact, barely an inconvenience.<\/p>\n","protected":false},"author":2,"featured_media":2862,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[324,322,323,4,321,1],"tags":[326,327,292,329],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/pipelines-hero-code-1024x256.jpg?fit=1024%2C256&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-Lm","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2931,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2931\/","url_meta":{"origin":2936,"position":0},"title":"&#8216;Sorry, this script is too long&#8230;&#8217;","date":"18 Sep 2019","format":false,"excerpt":"An object lesson on the importance of defensive programming and providing helpful error messages to your users.","rel":"","context":"In &quot;Azure DevOps&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Mark_Twain_life_1900s.jpg?fit=883%2C331&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2861,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2861\/","url_meta":{"origin":2936,"position":1},"title":"Azure DevOps &#8211; Building Some Code","date":"09 Sep 2019","format":false,"excerpt":"In this post we create a (very!) simple project, build it using Delphi (7) and run it. All with Azure DevOps.","rel":"","context":"In &quot;automation&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/pipelines-hero-code-1024x256.jpg?fit=1024%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2919,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2919\/","url_meta":{"origin":2936,"position":2},"title":"Azure DevOps &#8211; Now You Too Can Use My Template(s)","date":"14 Sep 2019","format":false,"excerpt":"Learn how you too can use my Delphi build template in your own Azure DevOps pipelines, and a sneak preview of something special coming soon...","rel":"","context":"In &quot;automation&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/github-512.png?fit=512%2C512&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2659,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2659\/","url_meta":{"origin":2936,"position":3},"title":"Azure DevOps and Delphi &#8211; Build Agents","date":"06 Sep 2019","format":false,"excerpt":"The first in a series of posts exploring build and test automation for Delphi projects using Azure DevOps.","rel":"","context":"In &quot;automation&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/pipelines-hero-1-1024x256.jpg?fit=1024%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2878,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2878\/","url_meta":{"origin":2936,"position":4},"title":"Azure DevOps &#8211; Template for Builds + Running Tests and Capturing Results","date":"12 Sep 2019","format":false,"excerpt":"A more complete build script, re-usable in the form of a template, that caters for different Delphi versions, combined with a demonstration of running unit tests and capturing results for reporting and analysis in Azure DevOps Pipelines.","rel":"","context":"In &quot;automation&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2019-09-12-at-14.25.20.jpg?fit=386%2C386&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2968,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2968\/","url_meta":{"origin":2936,"position":5},"title":"Azure DevOps + GitHub = GitHub++","date":"23 Sep 2019","format":false,"excerpt":"A look at some of the integrations that \"just work\" when you combine Azure DevOps and GitHub","rel":"","context":"In &quot;automation&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/azure-devopsgithub.png?fit=1024%2C341&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2936"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=2936"}],"version-history":[{"count":3,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2936\/revisions"}],"predecessor-version":[{"id":2940,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2936\/revisions\/2940"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media\/2862"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}