Azure Devops (pipelines) for deploying multi apps (angular and nestjs) ?

[iangregsondev]

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed
• I'm reporting the issue to the correct repository (not related to Angular, AngularCLI or any dependency)

Expected Behavior

Hi, I am hoping that somebody is doing something similar and can share there azure-pipelines.yml file :-)

Trying to use azure pipelines to build the projects (there is 1 angular and 1 nestjs) and automatically release.

The thing where I am getting confused is, technically there are 2 apps, and each push to master causes a build, but I only want to build and release the artifact if its changed.

Anybody doing something with the azure pipelines ?

I presume that I need to use the affected scripts and build only if changed but then how for the release artifacts to support deploying 1 or more apps.

Look forward to any insight anyone has :-)

I am at a loss right now.

[elvirdolic]

We are doing this by adding tags to the build. Each affected app is added as tag. You can use azure devops rest api for that (poweshell or node.js there is a node client available). You need then for each app a release pipeline. For each release pipeline you can define artifact filters based on build tags.

[iangregsondev]

Thanks @elvirdolic , I am still learning azure :-) I presume then I need to write a small nodejs script to call the rest service. Would you have the link to the docs for that ?

The tag that is added, is a one off tag, i mean, right now the pipeline we detect a new PUSH on github and run the yaml file, so I presume that the filters need to be added on the yml level ? to check for the tag - and next push the tags are reset ?

[iangregsondev]

I think I have the concept more or less now :-) The tags are added to the buildId. And I am able to use the AZ command line tools to add the tags using a buildID.

I will attempt it after doing a little further investigation.

[wangzishi]

@iangregsondev I'm also trying to do this. This is how I build angular applications.

But with nestjs, I still need to find a way to build the docker image without copy all angular node_modules stuff into it.

[iangregsondev]

This has been really helpful

Thanks

[vsavkin]

@mbriggs is putting together an example. Matt, once you are done, can you link it here and closer the issue?

[NiklasPor]

We've also been searching for this and built it ourself. We use build tags and specify release triggers based on the build tag. To add the tags inside the build, we simply use this single line of bash:

node node_modules/@nrwl/cli/bin/nx.js affected:apps --base=HEAD~1  --head=HEAD | grep -E '( - )(\w|-|\d|_)+' | sed -E 's/ - /##vso[build.addbuildtag]/g'

It works for app names containing numbers, letters, - and _.
After that simply create different release pipelines for your different apps and use the build tag as a trigger :)

(We're echoing ##vso[build.addbuildtag] with the tags inside the pipeline. Docs for that can be found here.)

[FrozenPandaz]

Hi, sorry about this.

This was mislabeled as stale. We are testing ways to mark not reproducible issues as stale so that we can focus on actionable items but our initial experiment was too broad and unintentionally labeled this issue as stale.

[KevTale]

Hi,

I'm struggling alot with this.
I don't understand how to make it work.

I've created a release pipeline which is linked on my monorepo and I added a build tag which is the name of my application.

Is that correct?

Now I believe I should add a build tag for each artifact that is created while running the build pipeline. Am I understanding it correctly?

If yes, then I really don't understand how to do so.
If you could help me on this, it's driving me crazy.

When and how am I supposed to add those build tags?

Many thanks

[elvirdolic]

What we did is to read all folders from the dist dir which contains all builded apps then we use the azure devops rest api to add the build tags based on the folder names. This is done as last step of the build Pipeline

[NiklasPor]

@GreatHawkeye we're using the affected:apps command by nx to add these tags.

Simply have a look at the bash command I wrote in december. We're using it to tag the builds. You'll just have to include the execution of it in your build pipeline:

#1930 (comment)

[KevTale]

@NiklasPor Thank you for your answer.
Is the following correct? Because it looks like doing nothing on the pipeline logs.

  - job: Build
    steps:
      - task: NodeTool@0
        inputs:
          versionSpec: '12.x'
        displayName: 'Install Node.js'
      - task: Npm@1
        displayName: 'npm install'
      - pwsh: 'npm run nx affected -- --target=build --parallel --base=origin/master --prod'
        displayName: 'Running build'
      - pwsh: |
          npm run nx affected:apps -- --base=HEAD~1  --head=HEAD | grep -E '( - )(\w|-|\d|_)+' | sed -E 's/ - /##vso[build.addbuildtag]/g'
        displayName: 'Adding build tags'

[NiklasPor]

@GreatHawkeye looks pretty solid, except you'll need to change the base to match your other affected command. Instead of --base=HEAD~1 use your --base=origin/master.

[KevTale]

@NiklasPor , awesome, it worked!!
Thank you very much. It added two tags as my workspace contains 2 apps.

So if I understand it correctly, what just happened is that the entire build has now 2 tags linked to it.
Now, I've created two release pipelines which are linked to my monorepo, each has a build tag filter with the name of their associated app.

How does the build tag filter works? In my (poor) understanding, the generated build has both tags, how can my release pipelines filter the correct folder to deploy (which is dist/${app-name}) as the entire build has both tags?

[NiklasPor]

Yes, you'll now need different release pipelines for the different tagged builds. One pipeline for each application. (We also have the different stages of that release inside that pipeline).

Sadly you'll have to do the extracting yourself. E.g. copying the files from one app folder to wherever you wanna do release stuff with them.

You can extract the common tasks shared by all release pipelines into task groups, so that you'll only have to write that once.

[KevTale]

Okay so I believe I should zip each one of my app and publish the artifact in my artifact directory?

I found this snippet :

  - task: ArchiveFiles@2
        inputs:
          rootFolderOrFile: '$(Build.SourcesDirectory)/dist/apps/app-name'
          includeRootFolder: false
          archiveType: 'zip'
          archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildNumber).zip'

      - publish: '$(Build.ArtifactStagingDirectory)'
        artifact: app-name

I'm guessing I have to replace app-name by the correct folders.

Does that make sense if I store the result of your nx affected:apps [...] commands in an array in order to loop through it and executing the zip and publish tasks on each item of the array?

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[draylegend]

How can I share installed node modules from the install/setup command across other jobs?

[cwmrowe]

@NiklasPor (or anyone else) interested to know if you have made any changes to support YAML Pipeline now that Classic Release pipelines are deprecated in Azure. As far as I can tell, build tags are no longer helpful with these new pipelines so I am looking for an alternative.

[cwmrowe]

Ignore me, it looks like build tag triggers are still a thing for YAML Pipelines. Hopefully this will help others.
https://docs.microsoft.com/en-us/azure/devops/pipelines/process/resources?view=azure-devops&tabs=schema#evaluation-of-artifact-version

[NiklasPor]

Haha yes, it works the same with the yaml pipelines 🚀

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.