Skip to main content

Azure Automation: Use a nested ARM template as an user defined function to bypass the start time issue of schedules

Lately I am busy with Azure Automation. In terms of ARM templates I run into a number of issues with this product. See also my previous blog postings about this. This time too I had to look for another workaround. In this case it concerns the start time of a schedule. This must be at least 5 minutes in the future for the product group each time you do an ARM deployment for the schedule object. This resource is also not complying to the idempotency rules of ARM template.

My workaround is to mark the date part of the startTime (for daily, weekly, montly recurring schedules) in my parameter file with 'GEN-DATE' placeholder and my ARM template will generate each time the correct date if I do the deploy. To replace the placeholder with the correct value I first thought to use an user defined function for this purpose. After reading the documentation, I could conclude that this functionality did not match what I needed. An user defined function consist of input parameters and output parameters but lacks the usage of variables. Because I have to calculate a few things to determine the correct date I need the usage of variables.

My solution is based on the usage of a nested ARM template which acts as an user defined function. The template calculates the correct start time in the variable section of the ARM template and will return the result in the outputs section. The next step in my ARM pipeline will reference that value and use it as the start time of the schedule.

The ARM template I created needs the start time as a parameter with the GEN-DATE placeholder in it. In the variable section I calculate if we can use the date of today or we need to start the schedule tommorow. Based on the current time this decession will be made. The current time will be corrected to reflect the UTC offset of the start time and we will give the script the minimal amount of 5 minutes in the future. To be save I decided to use a start time of minimal 7 minutes in the future because the deployment proces also needs some time to do the deployment. That value is configured via the default value of the addTimeForDeployment parameter.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "startTime": {
            "type": "string",
            "metadata": {
                "description": "The start time of the Automation schedule.",
                "remarks": "Add 'GEN-DATE' at the place of the date part of the schedule. For example: 'GEN-DATET16:00:00+01:00'."
            }
        },
        "addTimeForDeployment": {
            "type": "string",
            "defaultValue": "PT7M",
            "metadata": {
                "description": "The number of minutes to add to the compare time to determine if we use the date of today or tommorow.",
                "remarks": "Azure Automation requires that the schedule time is minimal 5 minutes in the future but you wil also need some additional time for the actual deployment."
            }
        },
        "currentTime": {
            "type": "string",
            "defaultValue": "[utcNow('u')]"
        }
    },
    "variables": {
        "today": "[substring(parameters('currentTime'), 0, 10)]",
        "tomorrow": "[substring(dateTimeAdd(parameters('currentTime'), 'P1D'), 0, 10)]",
        "scheduleTime": "[if(contains(parameters('startTime'), 'GEN-DATE'), skip(parameters('startTime'), length('GEN-DATE')), skip(parameters('startTime'), 10))]",
        "scheduleHour": "[substring(variables('scheduleTime'), 1, 2)]",
        "scheduleMinutes": "[substring(variables('scheduleTime'), 4, 2)]",
        "scheduleOffsetSymbol": "[substring(variables('scheduleTime'), 9, 1)]",
        "scheduleOffsetHour": "[substring(variables('scheduleTime'), 10, 2)]",
        "scheduleOffsetMinutes": "[substring(variables('scheduleTime'), 13, 2)]",
        "hourCorrection": "[concat(if(equals(variables('scheduleOffsetSymbol'), '-'), '-', ''), 'PT', variables('scheduleOffsetHour'), 'H')]",
        "minutesCorrection": "[concat(if(equals(variables('scheduleOffsetSymbol'), '-'), '-', ''), 'PT', variables('scheduleOffsetMinutes'), 'M')]",
        "currentTimeByOffsetHour": "[dateTimeAdd(parameters('currentTime'), variables('hourCorrection'))]",
        "currentTimeByOffset": "[dateTimeAdd(variables('currentTimeByOffsetHour'), variables('minutesCorrection'))]",
        "compareTime": "[dateTimeAdd(variables('currentTimeByOffset'), parameters('addTimeForDeployment'))]",
        "compareHour": "[substring(variables('compareTime'), 11, 2)]",
        "compareMinutes": "[substring(variables('compareTime'), 14, 2)]",
        "isCurrentHour": "[equals(variables('scheduleHour'), variables('compareHour'))]",
        "isHourInFuture": "[greater(variables('scheduleHour'), variables('compareHour'))]",
        "isMinutesInFuture": "[greaterOrEquals(variables('scheduleMinutes'), variables('compareMinutes'))]",
        "date": "[if(variables('isHourInFuture'), variables('today'), if(and(variables('isCurrentHour'), variables('isMinutesInFuture')), variables('today'), variables('tomorrow')))]",
        "newStartTime": "[concat(variables('date'), variables('scheduleTime'))]"
    },
    "resources": [],
    "outputs": {
        "startTime": {
            "value": "[if(contains(parameters('startTime'), 'GEN-DATE'), variables('newStartTime'), parameters('startTime'))]",
            "type": "string"
        }
    }
}

In the ARM pipeline you can reference the output value via a reference like this: reference(<deploymentName>.outputs.startTime.value

Comments

Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message: Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers. // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.

Make steps conditional in multi-stage YAML pipelines

To make the switch from the graphical release pipelines in Azure DevOps I am missing two features. The first one is to be able to defer a deploy and the second one is to exclude certain deployment steps without the need for editing the YAML file.  The defer option is something Microsoft has to solve in their Azure DevOps proposition. It's a feature which you have in the graphical release pipeline but what they have not implemented yet in their YAML pipeline replacement. Approvals and certain gate conditions are implemented on the environment but the defer option is still missing .  Pipeline The conditional deployment option can be implemented with the help of runtime parameters and expressions . In the parameter section you define boolean parameters which will control the deploy behavior. With the expressions you can control which stage/job/task should be executed when the pipeline runs. In the below YAML sample I experimented with conditions in the azure-pipelines.yml  file

Azure DevOps YAML based CD pipeline with multiple artifacts

In my post called " Switch from Azure DevOps release pipeline to YAML based CI/CD pipeline " I explained how to implement a combined CI/CD pipeline based on YAML templates. Because most of the deployments in my daily work are consuming multiple artifacts I had to do some additional R&D to find a solution for those releases in Azure DevOps. Base structure In the first post about the transition to YAML CI/CD pipelines I introduced the base structure. The templates I want to reuse are added to the yaml-template folders in the root of my GIT repo. For the CD pipelines which lack a CI phase I introduce a new folder called yaml-releases which will contain the YAML files for releases which are based on multiple artifacts. The folder structure within my GIT repo is thus: yaml-releases releaseArea myMultipleArtifactsRelease azure-pipelines.yml cd-job.yml yaml-templates jobs ... templates ...