I'm Trying to setup a Release CD for D365 (or Power Platform) using the "Power Platform Deploy Package" task:
https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tool-tasks
I can see the build and release are flowing correct except for the very last part.
I can tell it works all the way to the "Download Artifact" part "
Download Artifact
Do I need anything else beside those 2?:
pipeline
I get this "Package File not specified or not found" error:
error
same error with several combinations of env variable paths. tried the exact path and still does not work
Am I forgetting anything?
path
The code is produced with the VS CRM Package and compiled just fine. I only updated the .net framework version to 4.7.2.
vs template
If you are using Hosted agent instead of Self-hosted agent, we need to specify the path using predefined variables $(Build.ArtifactStagingDirectory) instead of D:\a\r1\a, then it should be work.
Also we could add the task Copy files to filter the .dll file and copy them to another path, then specify the Package File path.
Note: I just share the yaml sample, you could enter the variable to class edit mode(UI)
- task: CopyFiles#2
displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)'
inputs:
Contents: |
$(Build.ArtifactStagingDirectory)/_Demo-CI/drop/bin/Debug/*.dll
TargetFolder: '$(Build.ArtifactStagingDirectory)'
Related
Artifacts is not uploaded after successful test pipeline. What's wrong with the code below?
Here's the result:
You are using a variable in your artefact name, which is currently not supported. As artifacts section is a separate post-script behaviour, your Test step is perfectly green.
To solve the issue, use a constant name for your artefact. Alternatively, you can combine the packaging and deployment steps into a single one:
script:
- echo "Packaging and deploying to test environment"
- zip -r example-$BITBUCKET_BUILD_NUMBER.zip .
- pipe: ...
This advice works https://stackoverflow.com/a/72570848/14740671 but I need to separate the deployment. I also tried uploading the file using this code:
- pipe: atlassian/bitbucket-upload-file:0.3.2
variables:
BITBUCKET_USERNAME: $BITBUCKET_UPLOAD_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_UPLOAD_PWD
FILENAME: "example-1.zip"
It has no errors but file is still no seen in the Artifacts and azure deployments has "FileNotFoundError: [Errno 2] No such file or directory: '/opt/atlassian/pipelines/agent/build/example-1.zip'"
I'm doing a zip deploy of a .NET Framework web app to an Azure App Service via a GitHub workflow.
I have set WEBSITE_RUN_FROM_PACKAGE to 1 in the Azure console's Settings / Configuration / Application settings page. I've also tried setting WEBSITE_RUN_FROM_ZIP to 1 there just in case (although I think this is an obsolete flag).
The package is building correctly in GitHub and I can see it showing up in my Kudu debug console, under C:\home\site\wwwroot (as MyPackageName.zip) as well as in C:\home\data\SitePackages (as 20220512205318.zip, for example).
The deploy portion of my YAML is:
deploy:
runs-on: windows-latest
needs: build
environment:
name: 'Test'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
- name: Download artifact from build job
uses: actions/download-artifact#v2
with:
name: ASP-app
- name: Deploy to Azure Web App
id: deploy-to-webapp
uses: azure/webapps-deploy#v2
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_XYZsecret }}
package: .
And the .PublishSettings I've uploaded to GitHub looks like:
<publishData>
<!-- Which one of these 3 profiles is my YAML using? I don't actually know. -->
<publishProfile profileName="mywebappname-test - Web Deploy" publishMethod="MSDeploy" etc="foobar">
<databases/>
</publishProfile>
<publishProfile profileName="mywebappname-test - FTP" publishMethod="FTP" etc="foobar">
<databases/>
</publishProfile>
<publishProfile profileName="mywebappname-test - Zip Deploy" publishMethod="ZipDeploy" etc="foobar">
<databases/>
</publishProfile>
</publishData>
The zip package is not getting automatically unpacked. The MSFT support rep I talked to suggested that this was the problem, and indeed when I download the package to my machine and drop it into Kudu's Tools/Zip Push Deploy page, I see that the package is unpacked, and I can get the site to work by setting the appropriate Physical Path to match the '/' Virtual path. Specifically the Kudu Tools Zip Push causes my web.config and favicon.ico etc. files to show up in:
C:\home\site\wwwroot\Content\D_C\a\foo\bar\good\boy\obj\Test\Package\PackageTmp
and I can go to the Azure console for my app service, navigate to Settings / Configuration/ Path Mappings, Virtual applications and directories, and edit the existing entry to:
Virtual path: /
Physical Path: site\wwwroot\Content\D_C\a\foo\bar\good\boy\obj\Test\Package\PackageTmp
Type: Application
and then see my site come up in a browser.
However, when don't do anything to unpack the archive, and I leave the entry as:
Virtual path: /
Physical Path: site\wwwroot
Type: Application
I can't see my site in a browser and instead just see "You do not have permission to view this directory or page." When I then dig in to the logs in Kudo, I see 403.14 - Forbidden errors on my main site and a 404.0 - Not Found error on C:\home\site\wwwroot\favicon.ico. (Like the rest of my files, favicon.ico is still inside the zip archive at [...]\foo\bar\good\boy\obj\Test\Package\PackageTmp\favicon.ico.)
My questions are:
Should my web app be able to run at all with just my zip file sitting there as C:\home\site\wwwroot\MyPackageName.zip? Or does it really need to be unpacked as the MSFT rep indicated?
If it is supposed to run this way, any ideas on what am I missing? I assume it's something in my YAML (which of the 3 publishProfile settings is it actually choosing here?) or in Settings / Configuration/ Path Mappings or Application settings, but I have no idea what at this point and I'm running out of ideas.
Thanks, Eric
Should my web app be able to run at all with just my zip file sitting there as C:\home\site\wwwroot\MyPackageName.zip?
Pretty much, yes, just not in wwwroot. When WEBSITE_RUN_FROM_PACKAGE is enabled, the application is run from the archive directly as a read only directory mount. Nothing is copied to wwwwroot or anywhere else.
If it is supposed to run this way, any ideas on what am I missing?
My understanding is package deploy from GitHub is not supported or rather GitHub archives are incompatible with run from package on App Service.
dwellman's response was the correct answer to my original question, but I'll add some more detail here on how I used this information to get my deployment to work properly. I feel like the inability to read the zip archive's internal index XML file(s) to find the correct relative path is an Azure flaw, but until it's addressed, I hope others may find this useful.
My first step was to abandon the idea of deploying as a zip file. It's possible I could have still made this work by doing some post-processing to zip things up in a different format without the nested folders, but I decided in my case that the benefits of a single-file deployment weren't worth the cost. To stop deploying as a zip file, I manually edited the .pubxml file I was passing in as msbuild option /p:PublishProfile=AzureCI.pubxml. The changes I made were to change PackageAsSingleFile from true to false, and change DesktopBuildPackageLocation from a zip file path to a folder path.
This alone was enough to get my site to get deployed to Azure as individual files instead of a zip archive. The files were still buried in an ugly folder structure, but I could at least see them in Kudu and get the site to work by applying the same Settings / Configuration/ Path Mappings, Virtual applications and directories adjustment I describe in my original question.
I could have stopped there, but I wanted to be able to just use the default virtual path and not have my Azure configuration be so dependent on my upstream processes. In other words, I wanted to just have my web.config and favicon.ico etc land directly in C:\home\site\wwwroot instead of deep in the weeds of a subfolder structure. To make this work, I changed the package argument to webapps-deploy in my YAML from . to the appropriate path as follows:
- name: Deploy to Azure Web App
id: deploy-to-webapp
uses: azure/webapps-deploy#v2
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_XYZsecret }}
package: .\Archive\Content\D_C\a\foo\bar\good\boy\obj\Test\Package\PackageTmp
This caused the deployment process to pick off just the files I needed from the build and drop them into C:\home\site\wwwroot. I could then revert the path mapping kludge and be on my way.
We have an azure pipeline which produces a zip artifact in $(build.artifactstagingdirectory). Later we extract this and deploy to target folder. This works fine with websites. The msbuildargs looks like below :-
msbuildArgs : '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
We have a windows service which is not generating any zip artifact. After following article. I added /p:OutDir="$(build.stagingDirectory) in msbuildargs, Now I can see the files, but no zip file. Which we actually use.
msbuildArgs : '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)" /p:OutputPath="$(Build.ArtifactStagingDirectory)"'
is there any csproj settings for zip artifact? any specific setting for windows service ? Could not find more documents for PackageAsSingleFile.
is there any csproj settings for zip artifact? any specific setting for windows service ? Could not find more documents for PackageAsSingleFile.
Most of your MSBuild arguments are apply to ASP .NET projects and will do nothing for a windows service (Console App).
We just need to use /p:OutDir=$(Build.ArtifactStagingDirectory). That will tell MSBuild to put the build outputs in the artifact staging directory.
But this still will not generate zip package with the argument /p:OutDir=$(Build.ArtifactStagingDirectory). If you want to to generate zip, we could use the task Archive files.
Besides, we could change the /p:OutDir to other folder, so that we could use Archive files task to generate zip, like:
/p:OutDir=$(System.DefaultWorkingDirectory)/output
Then use the archive file task:
A little background...
I have a small dotnet core application that is hosted on Azure and is being built and deployed using Azure DevOps Pipelines. Before we started using the DevOps Pipelines the CI was hooked up directly to Azure which compiled fine but took an actual lifetime to deploy, hence the decision to move.
However, the build pipeline no longer compiles or outputs the sass/css folder
Everything else works okay - I check in, the Build pipeline picks up my commits and has the following steps:
Restore [.NET Core]
Build [.NET Core]
Publish [.NET Core]
Publish Build Artifact
Part of step 3 (Publish) uses a Gulp task:
gulp.task('prod', function (callback) {
runSequence('clean','set-prod',
['icon-sprite', 'logo-sprite', 'images', 'sass', 'modernizr', 'mainjs', 'adminjs'],
callback);
});
And locally (and previously) this generated five folders:
icons
img
js
logos
css (now mysteriously missing in action)
Variations I've tried
I've tried deleting my local css folder and running the CLI dotnet publish exactly the same way the Pipeline does and that appears to work fine locally.
I've also stripped the sass task way back in case that was causing an issue somewhere in the pipeline, so that now looks like this:
return gulp.src('src/sass/style.scss')
.pipe(sass({outputStyle: 'compressed'}))
.pipe(gulp.dest('wwwroot/dist/css));
I can see all of the output in the console logs on the Pipeline and it successfully executes the sass task:
2019-01-02T14:43:51.3558593Z [14:43:51] Starting 'sass'...
2019-01-02T14:43:51.9284145Z [14:43:51] Finished 'sass' after 524 ms
There are no other errors or warnings in the build script and everything completes and fires off the Release pipeline (which copies the artifact up to the Azure site).
Speculation
I would expect an error somewhere... but nothing - all of the green ticks are downright cheerful... so I'm a little stumped at what may or may not be happening! I can only think that there must be some dependency or something missing in the Pipeline environment? Orrrrr maybe I'm missing a Pipeline step?
Any help or nudges or ideas would be greatly appreciated! Thank you for sticking it out through my small essay and for any help you can provide :)
Something I've done in this situation before is changing the Publish Build Artifact task to upload everything in the build folder. My guess is that right now the 'Path to Publish' value in that task is set to $(build.artifactStagingDirectory). Change it to $(build.SourcesDirectory). After running the build again you'll see that the entire build directory has was uploaded. This includes your source code and any other folders like you have on your local environment. From there you can figure out if the CSS folder is actually missing, or if it ended up in some other folder location.
If the folder ends up in a weird location you can either add a file copy task to move the CSS folder to the proper folder in $(build.artifactStagingDirectory) or make a change to the Gulp task. Whatever is better for your scenario.
Once you find the location, you can fix the Publish Build Artifact task.
I was having the exact same issue. I was able to get everything working locally without issue. gulp would generate the css folder just fine. dotnet publish -c release would do the same. However, when ran through the pipeline, no css folder.
The thing that I find the most strange, is that there is a sibling folder (scripts) that is used in the same way the css gulp task is used, but that folder makes it just fine. Here's my css task:
gulp.task('min', function() {
return gulp.src('wwwroot/css/**/*.css')
.pipe(cssnano({zindex:false}))
.pipe(gulp.dest('wwwroot/dist/css/'));
});
but, this task does works both locally and in the pipeline:
gulp.task('build-js', function() {
return gulp.src('wwwroot/scripts/**/*.js')
.pipe(concat('site.bundle.js'))
.pipe(uglify())
.pipe(gulp.dest('wwwroot/dist/scripts/'));
});
I ended up just giving up since this is legacy code anyways and settled on a workaround:
Add the Copy Files task right after your gulp task with the below configuration:
Or, if you like YAML:
steps:
- task: CopyFiles#2
displayName: 'Copy Files to: wwwroot/dist/css'
inputs:
SourceFolder: wwwroot/css
Contents: '*.css'
TargetFolder: wwwroot/dist/css
I just upgrading my Azure service from free level to basic level to get more file storage space. But now accessing my first newly deployed Web app shows: "You do not have permission to view this directory or page." The deployment from Bitbucket worked. The kudu console shows everything loaded. I have 3 branches in my repo and three Azure apps defined, one for each. Two were deployed before upgrading and they are okay. The third was just deployed after the upgrade and has this problem. All three come from the same repo, and at this time all three branches are basically the same. All are the same basic ASP.NET Core 1.0 web app for each branch. I checked a lot of google pages, but none were helpful. Where do I go to fix this?
This just means that the website didn't load so the IIS server is falling back and trying to load one of the html files it has in the list for startup which you wouldn't have since it should be loading up your site code instead, the directory listing is the last thing it could show and will fail in this scenario. Pay special attention to any differences in the deployment methods or any changes made to the Startup.cs file.
Your application files may not have deployed correctly. The root / gave me:
You do not have permission to view this directory or page.
When I tried a static HTML file I got:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
(This should have been served by the .NET Core static middleware.)
I'd been playing with my Azure Pipelines YAML and it was pushing the wrong files up in the deploy to Azure Web App task step, thing.
My app is .NET Core 2.2 in "Run-from-Zip" mode, now called Run-from-Package.
A path error in my YAML meant the package contained another subfolder with the package inside it, instead of it all being in the root of the package, if that makes sense.
Maybe this fascinating story helps someone.
A frustrating experience making this work caused me to write this guide. What happens is your output may be missing some of the files needed, or be structured incorrectly, for IIS to launch your app. The issue can arise for different reasons.
Archive contains root directory.
When you create your zip file, make sure you are not archiving the root folder. What happens is your /home/site/wwwroot directory looks like:
/home/site/wwwroot
--RootFolder
--LaunchFile
When IIS is expecting
/home/site/wwwroot
--LaunchFile
This is easy to fix by adding includeRootFolder: false to the ArchiveFiles#2 task.
- task: ArchiveFiles#2
displayName: 'Archive files'
inputs:
includeRootFolder: false
Alternatively, if using the Web UI in the Root folder or file to archive section ensure that
Prepend root folder name to archive paths is not checked.
Build vs Publish
Using the .NET Core task to build the project or solution can result in output that will not work in the /home/site/wwwroot directory. The key here is to choose the publish option, not the build option. build was working for us and then did not for one of our projects. Changing to publish made it work again.
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'MyProj/MyProj.csproj'
arguments: '--output $(Build.BinariesDirectory)/WhereYouWantFilesForNextStep --configuration Release'
Instead, use the publish command.
steps:
- task: DotNetCoreCLI#2
inputs:
command: publish
arguments: '--configuration Release -o $(Build.BinariesDirectory)/WhereYouWantFilesForNextStep'
Zip File is not Mounted
Zip archives deployed to Azure are stored in
Directory of D:\home\data\SitePackages
11/03/2021 06:24 PM <DIR> .
11/03/2021 06:24 PM <DIR> ..
11/03/2021 04:24 PM 66,278,978 20211103162437.zip
11/03/2021 06:24 PM 73,799,022 20211103182443.zip
11/03/2021 06:24 PM 18 packagename.txt
And, if the following Application Setting is provided:
WEBSITE_RUN_FROM_PACKAGE = 1
Then IIS will mount the zip archive specified in packagename.txt to the D:\home\site\wwwroot.
D:\home\data\SitePackages>cat packagename.txt
20211103182443.zip
Note that 20211103182443.zip is the name of one of the .zip file listed in D:\home\data\SitePackages directory. Now if WEBSITE_RUN_FROM_PACKAGE is toggled the contents of D:\home\site\wwwroot will change.
Useful Resources
Additional reading is available at Microsoft Docs: Run your app in Azure App Service directly from a ZIP package.
If you want to examine the contents of the zip file directly, PowerShell will work in the console provided at App Service > Development Tools > Console and has access to the Unzip command.
D:\home\data\SitePackages>PowerShell Unzip -l 20211103162437.zip
Archive: 20211103162437.zip
Length Date Time Name
--------- ---------- ----- ----
25600 2013-07-17 23:18 AForge.Genetic.dll
...