Azure-pipelines-tasks: I want to know the status of another task in my own task

[GersonDias]

Hey, team

There are some way to know the status of another task? For example, I want to develop a script to do something when VSBuild task ran successfully and another when the same task fails... Is that possible?

Cheers,

[pascalberger]

If you're looking for conditional tasks, this was already asked in #795 and #629 and Microsoft has it in its backlog.

A workaround might be if you call the build in a custom script which sets a variable based on the build status using Logging Commands and in a later script decide further action based on the value of this variable.

[bryanmacfarlane]

If you can supply a more concrete example, I might be able to give some better guidance.

But in the abstract - If you want to do work that is that coupled to the work VSBuild (actually msbuild under the covers) is doing then just build it into that work. msbuild is a build DSL and you could weave that work into the msbuild.

That has a couple major benefits. The build the dev does on his desktop matches what is done on the CI server. You also have the full power of a build DSL/language.

If we add constructs like conditionals, then another language construct will be asked for, until ... we are another build DSL on top of the build DSL (msbuild, gulp, maven, gradle etc...) that developers use. We get back into the problem we got into with windows workflow - some logic in build DSL, some in the CI DSL, and developers asking how can they reproduce what the CI will do.

The exception to this is work specific to a CI build and not what devs do - publishing a build, creating a workitem if the build fails (actually an option now), publishing the test results. Hence my question about what specifically you are trying to do.

Back on my soap box ... :)

So, let's look at how this repro we're commenting in is built, tested and what the CI does.

We build with gulp - a build dsl we chose (orthogonal to this discussion). Devs do

gulp (build)
gulp test
gulp package

Those can be done independently and sequentially from a cmd prompt. There's conditionals in the package step to decide whether to publish to a nuget server. But it's all wrapped up in the build dsl logic. The same thing the dev runs.

What does the CI definition look like?
gulp
gulp test
gulp package

What does the release definition look like (triggers on release branches)?
gulp
gulp test
gulp package (but sets server variable)

What if publishing to nuget has issues? The dev sets the server variable and the same conditionals are taken on his box to test out what's going on. Rest assured, it's the same thing that will happen on the CI server.

Also note that what a dev does via the command line is sequential. The command line is sequential. The CI steps are sequential. But we realized that sometimes a dev conditionalizes what his next cmd he will run is :)

So, one downside to all this build DSL stuff - it pushes you down into a coding and scripting build DSL. We realize that and we will offer some conditionals perhaps for CI specific work but we also take the position that once you're off the beaten path and want to do more sophisticated conditionals and flows, that's a script or a build DSL

Hope that makes sense.

[GersonDias]

Bryan,

thanks for your explanation. My customer have a huge amount of customizations in TFS. Basically we implemented a Release Management Workflow inside WorkItems. So, using TFS Handlers, I can capture the build end event, check if its ok and change the status of an specific WorkItem. I want to do the same thing in vNext, so, I need to know if compilation step are ok (and, in that case, can be ANT or Maven build) and then update some WorkItems... Maybe I need to develop a Web Hook to perform this actions.

[ericsciple]

Within the build task the agent.jobstatus env var carries the current status for the job. If the definition has mulitpliers (parallel jobs) then the value could be misleading.

[bryanmacfarlane]

@ericsciple answered

[littleninja]

I'd like to suggest reopening this ticket. The answer from @ericsciple solves for job status, but we have a need for _task_ status.

An example:

• Build
• Test 1
• Publish Test 1 artifacts
• Test 2
• Publish Test 2 artifacts

If either the build fails or the Test 1 task fails, one or more publish tasks will fail. The setting "Run task: even if a previous task has failed, unless the build was cancelled" gets us close but not quite. What I'm hoping to achieve is a condition which can check if another task completed:

• Build
• Test 1
• Publish Test 1 artifacts: only if Test 1 completed (even if failed)
• Test 2
• Publish Test 2 artifacts: only if Test 2 completed (even if failed)

[GersonDias]

Maybe you can archive that with OutputVariables? I mean, create a build variable, assign that in OutputVariable task's field and then use a Control Option -> Custom Condition checking that variable.

[littleninja]

@GersonDias very possible. We haven't yet worked with output variables or custom conditions, so I'm trying to figure out how to wire this up. I'm not finding much documentation on either topic.

Could you point me at an example of how to declare an output variable and how to reference one within a custom condition?

[plang85]

@littleninja try this

      - task: CmdLine@2
        displayName: set variable
        inputs:
          script: |
            mkdir _failing_results
            if exist _failing_results (
                echo found artifacts
                echo ##vso[task.setvariable variable=faileddiff]yes
              ) else (
                echo no artifacts
                echo ##vso[task.setvariable variable=faileddiff]no
              )

      - task: CmdLine@2
        condition: eq(variables['faileddiff'], 'yes')
        displayName: conditional
        inputs:
          script: |
            echo check

[tharris29]

This works in the Build Pipeline but not in the release.

I have a scenario with

Test
Manual intervention - Only if task fail
Task - if the manual intervention request to continue

Any ideas?