{"id":67096,"date":"2023-06-11T23:53:10","date_gmt":"2023-06-12T07:53:10","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/devops\/?p=67096"},"modified":"2024-01-19T07:48:02","modified_gmt":"2024-01-19T15:48:02","slug":"updates-to-approvals-and-checks","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/updates-to-approvals-and-checks\/","title":{"rendered":"Updates to Approvals and Checks"},"content":{"rendered":"<p><a href=\"https:\/\/learn.microsoft.com\/azure\/devops\/pipelines\/process\/approvals\">Approvals and Checks<\/a> provide increased security to your YAML pipelines. They allow you to control if a pipeline run is allowed to access a resource.<\/p>\n<p>Let&#8217;s look at an example. Say you develop the <em>FabrikamFiber<\/em> web app. To deploy a new version of your app, you use a YAML pipeline that uses an <em>Azure Resource Manager<\/em> (ARM) service connection. Your deployment to production policy requires the app meet some performance criteria. You implemented the policy using an <a href=\"https:\/\/learn.microsoft.com\/azure\/devops\/pipelines\/process\/approvals?#invoke-azure-function\">Invoke Azure Function<\/a> check on the ARM service connection. Your Azure Function can check the performance of the to-be-deployed version of the system against a test environment and decide accordingly.<\/p>\n<p>We are making changes to improve the scalability of Invoke Azure Function &amp; REST API checks and customer experience.<\/p>\n<h2>Scalability improvements<\/h2>\n<p>We noticed that when an organization makes extensive use of the Invoke Azure Function &amp; REST API checks, they do not scale. That is, a modest increase in the number of running checks leads to abnormally large delays in checks execution time, negatively impacting deployment experience.<\/p>\n<p>Our solution to scale Invoke Azure Function and REST API checks is to enforce their configuration to match <a href=\"https:\/\/learn.microsoft.com\/azure\/devops\/pipelines\/process\/invoke-checks\">recommended usage<\/a>. If you followed our guidelines, your checks are compliant and need no further changes.<\/p>\n<p>Invoke Azure Function &amp; REST API Checks can run in two modes:<\/p>\n<ul>\n<li><em>ApiResponse mode (or Synchronous mode)<\/em>: In this mode, Azure DevOps makes a REST HTTP call to your check and actively waits for an answer.<\/li>\n<li><em>Callback mode (or Asynchronous mode)<\/em>: In this mode, Azure DevOps still makes a REST HTTP call to your check, but does not wait for an answer. Once your check reaches a decision, it fires a callback to communicate it. Azure DevOps resumes your pipeline&#8217;s execution.<\/li>\n<\/ul>\n<p>Two settings relevant for checks&#8217; scalability are <em>Time between evaluations<\/em> and <em>Timeout<\/em>, both under <em>Control options<\/em>. Time between evaluations defines how long a check&#8217;s decision is valid. A value of 0 means the decision is final. A non-zero value means the system retries the check after the configured interval, when its decision is negative or there are other approvals and checks. Timeout defines how long Azure DevOps waits for a positive decision. Together, time between evaluations and timeout define how many times the system can try a check.<\/p>\n<p>Your checks are considered compliant when they follow these rules depending on the mode you use and the number of retries:<\/p>\n<ul>\n<li><em>ApiResponse mode (or Synchronous mode)<\/em>: You limit the number of retries for your check to 10. You can do this in a number of ways. For example, you can configure timeout to 20 and time interval between evaluations to 2. Or, you can configure timeout to 100 and time interval between evaluations to 10. But, if you configure timeout to 100 and set the time interval between evaluations to 2, you are essentially asking Azure Pipelines to retry your check for a maximum of 50 times, and it is therefore not compliant. To summarize, the ratio of timeout to time interval between evaluations should be less than or equal to 10.<\/li>\n<li><em>Callback mode (or Asynchronous mode)<\/em>: In this case, Azure Pipelines does not retry your checks, and you are expected to provide a result asynchronously whenever you consider the result of your evaluation to be final. For this to be considered compliant, you must configure time interval between evaluations to 0.<\/li>\n<\/ul>\n<p>There is no need to retry a <em>Callback<\/em> check. You fully control your check&#8217;s logic, so you know best if and when a pipeline run has met the criteria to proceed with its execution. There is no need for Azure DevOps to probe your Azure Function check every 15 minutes. All Azure DevOps needs is a decision within the configured <em>Timeout<\/em>. The decision must be final, be it fail or pass.<\/p>\n<p>If your checks follow our <a href=\"https:\/\/learn.microsoft.com\/azure\/devops\/pipelines\/process\/invoke-checks\">recommended usage<\/a>, they are compliant.<\/p>\n<p>When Azure DevOps evaluates an Invoke Azure Function or REST API check, it makes an HTTP call. The check fails if the call does not complete in 3 seconds.<\/p>\n<h3>Rollout<\/h3>\n<p>Our goal is that by the end of the year, all your Invoke Azure Function &amp; REST API check are compliant. You may need to take action to ensure this.<\/p>\n<p>We realize this change is disruptive, so we have a three-phase rollout plan:<\/p>\n<h4>Phase 1<\/h4>\n<p>Starting June:<\/p>\n<ul>\n<li>When you create a check, its settings are compliant, but you can still edit them to make them non-compliant<\/li>\n<li>Azure DevOps shows warnings for non-compliant checks encouraging you to update their settings<\/li>\n<\/ul>\n<p>We show warnings at resource level, for example, this is how it looks like for the <em>FabrikamFiber Feed WUS1<\/em> environment, which has non-compliant checks configured. <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warnings_resources.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warnings_resources.png\" alt=\"Warnings on resources with non-compliant checks\" width=\"1200\" height=\"300\" class=\"alignnone size-full wp-image-67104\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warnings_resources.png 1200w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warnings_resources-300x75.png 300w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warnings_resources-1024x256.png 1024w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warnings_resources-768x192.png 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><\/a><\/p>\n<p>When you open a resource&#8217;s details page, we show warnings on the <em>Approvals and checks<\/em> tab for non-compliant checks. <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_env.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_env.png\" alt=\"checks phase 2 environment warnings\" width=\"1934\" height=\"790\" class=\"alignnone size-full wp-image-68302\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_env.png 1934w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_env-300x123.png 300w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_env-1024x418.png 1024w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_env-768x314.png 768w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_env-1536x627.png 1536w\" sizes=\"(max-width: 1934px) 100vw, 1934px\" \/><\/a><\/p>\n<p>Finally, when you click on a check, we focus the input on the setting you need to update. <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warning_invoke.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warning_invoke.png\" alt=\"Screenshot showing warnings in the configuration side panel for an Invoke Azure Function\" width=\"600\" height=\"378\" class=\"alignnone size-full wp-image-67103\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warning_invoke.png 600w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/warning_invoke-300x189.png 300w\" sizes=\"(max-width: 600px) 100vw, 600px\" \/><\/a><\/p>\n<h4>Phase 2<\/h4>\n<p>Starting July 24<sup>th<\/sup>:<\/p>\n<ul>\n<li>You can only create compliant checks<\/li>\n<li>When you edit a check, you can save changes only if its settings are compliant<\/li>\n<li>Azure DevOps shows more prominent warnings for non-compliant checks encouraging you to update their settings<\/li>\n<\/ul>\n<p>In addition to the warnings in Phase 1, we show warnings in a pipeline run&#8217;s detail page.<\/p>\n<p>We show warnings in the <em>Stages<\/em> card. For example, this is how it looks for a stage named <em>Deployment FabrikamFiber Feed WUS1<\/em> that accessed resources protected by non-compliant checks. <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/errors_build.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/errors_build.png\" alt=\"Screenshot showing warnings in a pipeline run&#039;s details page.\" width=\"600\" height=\"307\" class=\"alignnone size-full wp-image-67100\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/errors_build.png 600w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/errors_build-300x154.png 300w\" sizes=\"(max-width: 600px) 100vw, 600px\" \/><\/a><\/p>\n<p>If you open the <em>Approvals and checks<\/em> side panel, we show warnings next to the non-compliant check. <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_panel.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_panel.png\" alt=\"Warnings phase 2 checks panel\" width=\"806\" height=\"352\" class=\"alignnone size-full wp-image-68303\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_panel.png 806w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_panel-300x131.png 300w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/checks_phase2_panel-768x335.png 768w\" sizes=\"(max-width: 806px) 100vw, 806px\" \/><\/a><\/p>\n<h4>Phase 3<\/h4>\n<p>Starting Autumn:<\/p>\n<ul>\n<li>Weekly, one-day long brownouts, where all pipeline runs that use non-compliant checks fail<\/li>\n<li>Starting Winter, all pipeline runs that evaluate non-compliant checks fail<\/li>\n<\/ul>\n<p>A pipeline run that failed due to non-compliant checks shows an error in the <em>Errors<\/em> card guiding you to this blogpost. <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/build_failed.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/build_failed.png\" alt=\"Screenshot of a failed pipeline run due to non-compliant checks\" width=\"1200\" height=\"618\" class=\"alignnone size-full wp-image-67098\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/build_failed.png 1200w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/build_failed-300x155.png 300w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/build_failed-1024x527.png 1024w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/build_failed-768x396.png 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><\/a><\/p>\n<h2>Experience improvements<\/h2>\n<p>We are making reading check logs easier. Checks are critical sources of information for your deployment&#8217;s success. They can tell you if you forgot to close a work item ticket, for example. Alas, knowing that a check provided such critical information is hard today. The pipeline run details page shows the latest check log <em>only<\/em> for checks that follow our <a href=\"https:\/\/learn.microsoft.com\/azure\/devops\/pipelines\/process\/invoke-checks\">recommended usage<\/a>.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/check_logs.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/check_logs.png\" alt=\"The pipeline run details page showing check logs for compliant checks\" width=\"1200\" height=\"470\" class=\"alignnone size-full wp-image-67099\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/check_logs.png 1200w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/check_logs-300x118.png 300w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/check_logs-1024x401.png 1024w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/check_logs-768x301.png 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><\/a><\/p>\n<p>To prevent mistakenly approved <em>Approvals<\/em>, Azure DevOps shows the <em>Instructions to approvers<\/em> in the <em>Approvals and checks<\/em> side panel in a pipeline run&#8217;s detail page.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/approval_instructions.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/approval_instructions.png\" alt=\"approval instructions in checks panel\" width=\"964\" height=\"358\" class=\"alignnone size-full wp-image-68305\" srcset=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/approval_instructions.png 964w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/approval_instructions-300x111.png 300w, https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2023\/06\/approval_instructions-768x285.png 768w\" sizes=\"(max-width: 964px) 100vw, 964px\" \/><\/a><\/p>\n<h2>FAQ<\/h2>\n<h3>How do I make sure my checks continue to work?<\/h3>\n<p>If you followed <a href=\"https:\/\/learn.microsoft.com\/azure\/devops\/pipelines\/process\/invoke-checks\">our guideline on recommended usage<\/a>, your checks need no further changes.<\/p>\n<h3>Can I still use synchronous Invoke Azure Function or REST API checks?<\/h3>\n<p>Yes, but there is a 10-try limit.<\/p>\n<h3>My Azure Function takes more than 3 seconds to start up and process the request. What can I do?<\/h3>\n<p>If the HTTP call Azure DevOps makes to your check returns an HTTP status code outside of the 2xx and 3xx range, it retries for a maximum of 10 times. Then, the check fails. This is a built-in retry by the system that you do not have to configure anywhere.<\/p>\n<h3>I don&#8217;t see the check logs in my pipeline run details page. Why?<\/h3>\n<p>The pipeline run details page shows the latest check log <em>only<\/em> for checks that follow our <a href=\"https:\/\/learn.microsoft.com\/azure\/devops\/pipelines\/process\/invoke-checks\">recommended usage<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Approvals and Checks provide increased security to your YAML pipelines. They allow you to control if a pipeline run is allowed to access a resource. Let&#8217;s look at an example. Say you develop the FabrikamFiber web app. To deploy a new version of your app, you use a YAML pipeline that uses an Azure Resource [&hellip;]<\/p>\n","protected":false},"author":76405,"featured_media":60180,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[224,1],"tags":[],"class_list":["post-67096","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-devops"],"acf":[],"blog_post_summary":"<p>Approvals and Checks provide increased security to your YAML pipelines. They allow you to control if a pipeline run is allowed to access a resource. Let&#8217;s look at an example. Say you develop the FabrikamFiber web app. To deploy a new version of your app, you use a YAML pipeline that uses an Azure Resource [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/67096","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/76405"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=67096"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/67096\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/60180"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=67096"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=67096"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=67096"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}