Is it possible to run a npm build on umbraco cloud v.13.
We have a simple uSkinned umbraco solution, but want to expand with some scss in the near future.
Do we need our own build service to do this, or is it possible without?
1 Like
As far as I know, you’re going to have to look into their CICD Api
I’ve used it on a few projects - can be a bit tricky to setup, but once you are up and running, you can build your frontend in your own pipeline.
Umbraco Cloud does not let you run a npm build as part of their pipeline.
As well as Umbraco CI/CD Flow, I use an alternative CI/CDprocess that works well for me.
If you want to keep it super-simple, an option that can work well is to have a separate dedicated frontend build that just handles the frontend assets and deploys them to different hosting altogether on a subdomain e.g. assets.example.com
@JasonElkin I read your article which is both interesting and helpful - thanks. However, I don’t understand why it is still necessary to jump through hoops like that when it is very common in this day in age to have your projects build/compile both frontend and backend artifacts as part of the same process.
I had a separate step in my pipeline to do it then include it in the artefact we pass to the API in our CI/CD workflow but once Umbraco Cloud gets it, it still adds the files to the git repository which is what we are trying to avoid because when we merged changes back we end up with them in our repo and that is exactly what we were trying to avoid in the first place. If we use .gitignore to ignore the files then they don’t get deployed. It’s all a bit frustrating.
How do you prevent Cloud from checking in the frontend build output in the git repository?
CC @skttl
I have Umbraco cloud download the assets at build time i.e. after Cloud has checked out the code and before it deploys. So it doesn’t end up in the repo, same as any NuGet packages you might reference.
<Project Sdk="Microsoft.NET.Sdk.Web">
<!-- ... -->
<Target Name="PreBuild" BeforeTargets="PreBuildEvent" Condition="$(configuration) == 'Release'">
<Exec Command="powershell .\fetchAssets.ps1" />
</Target>
</Project>
Because Umbraco Cloud does its own build, but only of your .NET project. So you can’t run any other build steps i.e. npm etc.
That said, you can execute arbitrary code at build time - hence my PowerShell script. That could just as easilly be a .NET tool or some other executable you want to run as part of the build. Sadly there’s no version of node/NPM that works without a proper install (dart sass is just an executable though).
Because Umbraco Cloud does its own build, but only of your .NET project. So you can’t run any other build steps i.e. npm etc.
I understand the technical reason, I don’t think my point came across as intended. What I was trying to say was why have they not added support for this, it is a common requirement after all.
That said, you can execute arbitrary code at build time - hence my PowerShell script.
My current issue is that I don’t like the fact I have to include sensitive information in the script in order to retrieve the artefact from my pipeline, something you touched on in your post. My experience so far is that you can’t access environment secrets at deploy time - they are runtime only so that is not an option either.
Gotcha, and yes I agree it’s a pain. Though I can also understand the difficulty of Umbraco running its own fully fledged CI/CD solution.
Yeah, it’s not ideal, though any risk here can be mitigated somewhat:
-
The Personal Access Token can be really locked down, IIRC you only need to grant read-only access to workflows and artifacts, and that can be locked down to the specific repo that you are working with.
-
I’m only pulling in frontend assets - so things that will ultimately be publicly accessible on the website anyway.
If you want a zero-trust solution you can also have your FE build pipeline push/deploy your frontend assets somewhere else and pull it down from there.
Gotcha, and yes I agree it’s a pain. Though I can also understand the difficulty of Umbraco running its own fully fledged CI/CD solution.
Not sure they’d need to go to that extent. As long as node was available on the build server, it would allow those assets to be compiled as part of the build process.
Sure, having node available isn’t difficult, but then what version of node?
Supporting pipelines for FE builds gets real complex real quick. I’ve looked after build servers for organisations using a single standard tech-stack and that was non-trivial, running one that’s suitable for all of Umbraco Cloud’s disparate customers is a whole other ball game.
Sure, having node available isn’t difficult, but then what version of node?
I guess you could argue the same about dotnetwhich I believe is handled by the global.json file.
Supporting pipelines for FE builds gets real complex real quick. I’ve looked after build servers for organisations using a single standard tech-stack and that was non-trivial, running one that’s suitable for all of Umbraco Cloud’s disparate customers is a whole other ball game.
I get that and I don’t doubt it, but it doesn’t get away from the fact that those artefacts need to be included and most people don’t want them in the repository.
Currently, we have a cloud.zipignore file - this is of no use in achieving our goal as we want the frontend artefacts included since we can’t build them on Umbraco Cloud. We can’t include them and then ignore them using .gitignore because then they don’t get deployed at all. Perhaps another file that tells Umbraco, we need this deployed, but don’t commit it - this would actually be a very simple solution to what is now an unnecessarily complex issue.
1 Like
I’ve not used CI/CD Flow, are you saying that the FE files that get included in the zip still end up in the repo?
If so, that’s wild.
Forgive my misunderstanding.. But what is the issue with a generated asset being in the cloud repo (other than yes it shouldn’t really be)? If every deploy it’s always rebuilt and ends up with the correct generation in the cloud repo?
Is it simply developing locally you don’t also have the same at build time generate the asset? (so it becomes stale on its merge from the cloud repo)
msbuildtarget to the rescue? or if VS use task runner (npm task runner extension maybe, native gulp is that still used) and bind the front end asset build command to the build action?
Or maybe as you say a convoluted front end build prohibits that?
Would setting automatic upgrades off.. stop the requirement to back merge from the cloud repo?
I’ve not used CI/CD Flow, are you saying that the FE files that get included in the zip still end up in the repo?
Yes, exactly that. It merges the zip provided via the API. I must admit I assumed (now it seems, incorrectly) that your post was in relation to the CI/CD workflow.
1 Like
Forgive my misunderstanding.. But what is the issue with a generated asset being in the cloud repo (other than yes it shouldn’t really be)? If every deploy it’s always rebuilt and ends up with the correct generation in the cloud repo?
It’s for the same reason you wouldn’t ordinarily commit your projects dll’s in a .NET project. They change every time you build, even if it is just a very minor change… they will change, and you end up bloating your commits/repository unnecessarily. They are build artefacts and should be generated by the build process (in my opinion) at build time.
1 Like
Sorry, I know it’s not ideal but easy enough to workaround without any other real impact than a bit of bloating? They are being built in your repo and just unfortunately have to be included in the cloud repo as a static asset (rather than generated there too)
If you really don’t want the repo polluted with generated assets, could you nuget package your frontend assets as part of the Umbraco CI/CD Flow (a simple staticwebassets approach), and stamp the new version in the cloud.csproj again in the CI/CD flow (if github action sed probably the easiest).. That way your cloud repo stays clean and unbloated (nuget assets fetched at build time in the cloud build process)?
If it’s public nuget then no secrets to expose either, though if private just an access token to access the package?
2 Likes
Yes, NuGet is a solid approach too. I found the DX a little more frustrating than the alternative(s), but not by much TBF - also with version ranges you can avoid having to hardcode versions.
1 Like
There are various workarounds, I understand that and have tried numerous ways. My point isn’t that the deployment can’t be achieved as I have a working pipeline it’s just not the one we ideally would like.
Perhaps raise a discussion to see if any traction to get things changed to how you would like it? 
I’d also like to see being able to set the assembly version to the github run number too…
I think I found a way for me that works…
I have a step for building frontend files, in between syncing files from Cloud, and preparing and uploading the zip artifact.
My frontend build step does the following:
- Builds the frontend using npm, the output ends up in wwwroot/build
- wwwroot/build is ignored in .gitignore - but not cloud.gitignore
- Adds the build output to a zip-file in devops/temp/frontend.zip
- devops/temp is also ignored
- I had ChatGPT help me write some code, that finds all changed files after the npm build, to include in the zip file.
- the file is posted as an artifact (I use BitBucket, where you have to do this, in order to persist it for future steps)
- In the “Prepare and upload” step, I check if there is a
devops/temp/frontend.zipfile, and extract it if found. The files from the zip file, then ends up in mysources.zip, which gets sent to CI/CD
And voila, the build output is included in the deployment. Subsequent pipelineruns, doesn’t sync the files back to my own repository, so it works just like I want, having build output be a cloud repository thing only.
It’s probably worth mentioning that the whole zip circus, is just to simplify the artifact that I have to send to the next step. It might be easier in GitHub og Azure DevOps.