How is SQL Change Automation helping you? Share to win DevOps books.

nupkg removed by post-stage checkout (build, Azure DevOps)

Kris_LawtonKris_Lawton Posts: 3 New member
edited February 10, 2021 1:20PM in SQL Change Automation
We have two pipelines on Azure DevOps that perform similar operations for two different databases. They both run a "[email protected]" task followed by a "[email protected]" task. All of a sudden this morning, after months of working builds and releases, one of the pipeline's release task is errororing because it cannot find the nupkg generated by the build. On inspection, the build job generates a nupkg file in the agent-redgate/_work/<number>/s folder which I believe corresponds to the source control repo for the DB, then a "post-job checkout" is performed which cleans that folder, and since the nupkg is not in source control, it is deleted.

Confusingly, this deletion only happens for one of the two pipelines mentioned. They both perform a post-job checkout, but only one of them seems to pick up that the nupkg is there, and deletes it. Not sure why that is...

I should probably mention, these pipelines both run on self-hosted agents.

How can I solve this? I see three options, but I have cons for each.

1. Change the build task to a deployment, so that it doesn't perform a post-job checkout. Con: I'm not sure if this is advisable, since to me this is not a deployment, it is just a task.
2. Change where the nuget package gets generated. Con: I can't see an option for this within the SQL Change Automation module of Azure DevOps
3. Switch to using a NuGet feed. Con: I don't know much about this. My inkling is that we don't really need to since the build and release are done on the same agent.

Could someone provide some advice or solution?

EDIT: Accidentally submitted post before I had finished

Best Answer

  • Kendra_LittleKendra_Little Portland, OR, USAPosts: 126 Gold 2
    edited February 10, 2021 1:25PM Accepted Answer
    Hi @Kris_Lawton ,

    I am a little confused about what type of pipeline we are talking about. Is this a YAML pipeline? Or one of the classic pipeline types? 

    If it is a YAML pipeline, the build task publishes the build artifact to the pipeline, so you can always pull it down to the local agent with:

      displayName: Download build artifact
      inputs:
        buildType: 'current'
        artifactName: 'Database Build Artifact'
        targetPath: '$(System.DefaultWorkingDirectory)'

     I am not clear why this would have suddenly changed in your pipeline, though. 


    Edit: struggling with code formatting
    -------------------------------
    @Kendra_Little
    Product Manager at Redgate

Answers

  • Hello @Kendra_Little, thanks for your quick response!

    Yes it is a YAML rather than classic.

    Ahh so the "<pipeline>\s" is not the proper place for the nupkg – I see that now. I also found that all of the build nupkg files are in "<pipeline>\Database Build Artifact" anyway with their respective build names, so rather than adding a download task, I've just told it to get the current nupkg from that folder using the build number and it seems to have worked.

    And for safety's sake/to be thorough, I'd better sort the other pipelines lest they start having the same problem...

    Thanks for your help!

    Kris
  • First let me point out few things that may be helpful:
    • Unfortunately the only control over the .nupkg generated by the Build task is to whether you want to publish it or not.
      The package is always generated in current working directory (the "/_work/x/s/" directory you mentioned, available in $(System.DefaultWorkingDirectory) YAML property).
      If you choose to publish it, it's always published under "Database Build Artifact" name.
    • In Release task, you choose from which directory Build Artifact (.nupkg) will be grabbed, using the NuGetFile input parameter (set it to the directory where .nupkg is located).
    • I'm not aware of scenario, where either Build or Release task would delete the Build Artifact.
    • You can use the default [email protected] task, to copy the Build Artifact to any directory of your choosing, then specify that directory to the Release task, e.g.:
    - task: [email protected]
    # [...]
    
    # Copy Build Artifact to /_work/x/a/
    - task: [email protected]
    inputs:
    SourceFolder: '$(System.DefaultWorkingDirectory)'
    Contents: '$(PackageName)*.nupkg'
    TargetFolder: '$(Build.ArtifactStagingDirectory)\Database Build Artifact'
    OverWrite: true - task: [email protected] inputs: Operation: 'Create' NuGetFile: '$(Build.ArtifactStagingDirectory)\Database Build Artifact' # [...]
    • If you opt-in to publish the Build Artifact during the Build task, you can download the published artifact later on, using the [email protected] (example in Kendra's post above).

    Maybe just copying the .nupkg, right after the Build task, to $(Build.ArtifactStagingDirectory) or something else would help?
Sign In or Register to comment.