Azure static web apps(preview) currently only works with a github account, and as a company policy we have to use Azure for repos and everything else (pipelines, releases, etc..) We are going to use the static web app just for viewing a simple angular website however all the source code must remain in the azure devops repo.
Is is possible to create a private github account and upload to it only the compiled angular files to make use of the static web app? for example we already have a pipeline to compile and deploy the angular website to an Azure web app service, can this pipeline be modified to publish the same files to the github account? and if so how?
You can do it in Azure Devops. Try put this YML in Azure DevOps Pipeline
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
name: 'yourApplicationName'
steps:
- task: NodeTool#0
inputs:
versionSpec: '12.x'
displayName: 'Install Node.js'
- script: |
npm install -g #angular/cli
npm install
displayName: 'npm install'
workingDirectory: '$(Build.SourcesDirectory)/yourApplicationName'
- task: AzureStaticWebApp#0
inputs:
app_location: "/yourApplicationName"
api_location: "api"
app_build_command: $(build_command)
output_location: "dist/yourApplicationName"
env:
azure_static_web_apps_api_token: $(deployment_token)
You can put build_command and deployment_token in the variables
Azure SWA is only available for code in Github at the moment.
However, you can get something pretty close with Azure App Service. Microsoft even has a couple blog posts about how to configure Azure App Service, Azure Repos and Azure Pipelines together.
You can deploy a React Static Web Apps from Azure using Pipelines as follows:
name: Azure Static Web Apps CI/CD
#
# Trigger off of changes in master or another branch(s)
#
trigger:
branches:
include:
- TestBranch
jobs:
- job: build_and_deploy_job
displayName: Build and Deploy Test Web App
condition: or(eq(variables['Build.Reason'], 'Manual'),or(eq(variables['Build.Reason'],'PullRequest'),eq(variables['Build.Reason'], 'IndividualCI')))
pool:
vmImage: ubuntu-latest
variables:
- group: <Name of your Static Web App Resource Group>
steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp#0
inputs:
azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_TOKEN_#####)
# Details at https://aka.ms/swaworkflowconfig
app_location: "/" # App source code path
api_location: "" # Api source code path - optional
output_location: "build" # Built app content directory - optional
app_build_command: 'chmod 755 scripts/*.sh;./scripts/WebAppBuild.sh prod'
You will first need to set up a connection in Azure->Settings->Pipelines->Service Connections. Use the Pipeline wizard to set up all the initial YML.
The key for me was to run my own build in WebAppBuild.sh which basically runs "npm run build". My repo has a scripts folder. The job/task performed the rest of the install
Related
I have an azure devops package feed which was working fine for my purposes, until recently a hard drive failure disrupted operations. Suddenly I found myself unable to push any packages without running into a 401 response. I was able to get it to work eventually after modifying a nuget.config file as described in the answer to this question, but given that this entire process was fairly convoluted, it seems like there should be a much more straight-forward way to set this up when needed. So that in the case I ever need to do this again in the future, and so that I don't have to rely on getting lucky with stack overflow answers, what is the best, most straight-forward method for setting up publishing to azure devops package feeds?
nuget.config is the most commonly used authentication method for push packages to feed. There are two ways to push packages to feed, I think you may need another.
Pipeline push should be a easy way to achieve your requirement.
trigger:
- none
pool:
vmImage: 'windows-latest'
steps:
- checkout: self
persistCredentials: true #This step will do the auth.
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration Debug'
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
versioningScheme: 'byPrereleaseNumber'
majorVersion: '1'
minorVersion: '0'
patchVersion: '2'
- task: NuGetCommand#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'xxx/xxx'
You just need to 'click' the feed you want push to and then change the step of YAML like the above.
After that, give the permission to pipeline:
Finally, run the pipeline to push artifact to feed:
Each step of this method is very clearly and each time you want to push artifact, you just need to change several settings is ok(Version, Repo that the pipeline based on, artifact name). Create once, use for a long time.
Additional:
How to change the repo that the pipeline based on:
Repository Structure on my side:
Everything of push artifacts:
Publish Nuget packages(NuGet.exe)
Publish Nuget packages(dotnet)
Publish NuGet packages with Azure Pipelines (YAML/Classic)
The current setup is as below
Version Control - Git
Repos and Branch hosted on - Azure DevOps
Codebase - External server
The dev team clones Azure Repo into local git project and any staged changes are committed via Git and pushed to specific branch of Azure DevOps. In this setup we would want to upload the changes to external FTP servers and avoid manual upload. Currently trying to use Azure Devops FTP Upload Task (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/ftp-upload?view=azure-devops), however facing issues; yaml script as below
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
phpVersion: 7.4
webAppName: 'Test Project'
buildConfiguration: 'Release'
vmImageName: 'ubuntu-latest'
steps:
- publish: $(System.DefaultWorkingDirectory)/AzureRepoName
artifact: Test Project Deploy
- task: FtpUpload#2
displayName: 'FTP Upload'
inputs:
credentialsOption: inputs
serverUrl: 'ftps://00.00.00.00:22'
username: ftp-username
password: ftp-password
rootDirectory: '$(System.DefaultWorkingDirectory)/AzureRepoName'
remoteDirectory: '/home/public_html'
clean: false
cleanContents: false
preservePaths: true
trustSSL: true
PROBLEM
Following errors occur when I commit (for test purposes) something.
Starting: PublishPipelineArtifact
==============================================================================
Task : Publish Pipeline Artifacts
Description : Publish (upload) a file or directory as a named artifact for the current run
Version : 1.199.0
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/publish-pipeline-artifact
==============================================================================
Artifact name input: Test Project Deploy
##[error]Path does not exist: /home/vsts/work/1/s/AzureRepoName
Finishing: PublishPipelineArtifact
I want to upload any staged change that is committed to main branch on Azure Devops to be automatically deploy on the remote FTP server
Thanks
On checkout devops agent will create /home/vsts/work/1/s/AzureRepoName folder with your source but actually when the checkout happens the /home/vsts/work/1/s folder is the repository root i.e. there is no AzureRepoName folder in there. so what you need is to publish /home/vsts/work/1/s folder itself as the artifact. also your ftp upload task should use rootDirectory: '$(System.DefaultWorkingDirectory)/AzureRepoName'
We have two static apps, one for production and one for non production (test). They just show a site down page for when our main site on AEM is down (using traffic manager to switch).
The source is held in an Azure devops git repo.
This is how it is built in non prod:
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp#0
inputs:
app_location: '/'
api_location: ''
output_location: ''
azure_static_web_apps_api_token: $(deployment_token)
Now we want to make it build a prod version of the static web app, if we push to another branch (e.g. "prod"). Any idea how we might do this? Not sure how we would differentiate between the prod static web app deployment token and the non prod one either?
Please take a look on this example. Here you have three main steps:
in stage Build - a package is being prepared
in stage Dev - package is being deployed to Dev env
in stage Prod packages is being deployed to Prod env
It is implementation of approach build once deploy many, which is good because it means that on each env you use the same package, so you trully test the package which is going to be deployed to production.
In terms of token, you can put this is two seprate variables group. One name dev, and the other prod. Both should have the same variable deployment_token and then
- stage: Prod
dependsOn: Dev
variables:
- group: Prod
- stage: Dev
dependsOn: Build
variables:
- group: Dev
What I want to achieve:
I have a repository on Azure DevOps which hosts my web application. I wrote a test suite for UI Automation using Cypress. I created a separate repository for my test cases to check if they are working properly or not. I created a pipeline which has the following content:
trigger:
- manual-tests
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install
displayName: 'npm install'
- task: Npm#1
inputs:
command: 'custom'
customCommand: 'run test'
continueOnError: true
- task: PublishTestResults#2
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-output-*.xml'
testRunTitle: 'My Test Cases'
I have a trigger set to a branch of the repository in which my UI Automation code is stored. What I want is, to trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this? Can we store our test case files in the application repository and give the path of the test script?
It seems that the UI Automation Repo and Web Application Repo are two separate repos.
To trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this?
The function: "trigger a pipeline from a different repo" is not available now.
This feature is still under development. Multi-repository support for YAML pipelines will be available soon for azure devops service.
Please check the function:"Multi-repository support for YAML pipelines" in Azure DevOps Feature Timeline 2020 Q2. This feature will roll out to everyone by the end of July 2020.
Workaround：
You could try to use the Pipeline triggers.
Here are the steps:
Step1: Create a pipeline with web application repository, then you could set the trigger branch.
Step2: Add the Pipeline trigger in the Yaml file (UI Automation Repo).
For example:
resources:
pipelines:
- pipeline: Name
source: Pipeline name
trigger:
branches:
- releases/*
- master
When you make changes in web application repository, the pipeline with the web application will be triggered.
After running the pipeline , the pipeline with UI Automation repo will be triggered.
Can we store our test case files in the application repository and give the path of the test script?
Of cource. You can do it.
If you want to use the test file in the pipeline (UI Automation repo), you could add the repo resouces in the pipeline.
For example:
resources:
repositories:
- repository: MyAzureReposGitRepository
type: git
name: MyProject/WebapplicationRepo
...
steps:
- checkout: MyAzureReposGitRepository
Note: the repo will be check out to the Agent Source Folder.
Hope this helps.
In Azure DevOps we have created both build and release pipeline using classic way and now we are planning this to convert to yaml file.
But it seems in yaml method, the code can be put only on the root of the repo, where we want to keep the build yaml files in a separate repo, where the developers won't have access.
How can achieve this?
You can use templates, put in the main repo only the minimal yaml that refers to a template with all the steps, the template exits in another repo.
For example, your main repo yaml:
resources:
repositories:
- repository: templates
type: git
name: Contoso/BuildTemplates
jobs:
- template: common.yml#templates # Template reference
In in the repo: Contoso/BuildTemplates put the full yaml:
# Repo: Contoso/BuildTemplates
# File: common.yml
parameters:
vmImage: 'ubuntu 16.04'
jobs:
- job: Build
pool:
vmImage: ${{ parameters.vmImage }}
steps:
- script: npm install
- script: npm test
Restrict the access to the second repo (unless the agent pipeline user).
Read here more info about the resources.
I agree that one solution could be the one proposed by #Shayki Abramczyk
but to have standalone *.yml in dedicated repository you can use 'git clone' while using 'Git Credentials' to access the other repository that contains the files you want to build by the pipeline.
If your repository dedicated for *.yml is in the same Azure Devops project then you should not have any problem with the release definition.
Please see example *.yml that works for us as described:
pool:
vmImage: 'your-preferred-image'
variables:
solution: '$(Agent.BuildDirectory)/**/YourSolution.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Debug'
urlWithCreds: 'https://YourUser:YourPassword#dev.azure.com/YourOrganization/YourProject/
_git/YourOtherRepository'
steps:
- task: CmdLine#2
inputs:
script: |
git --version
git clone --quiet $(urlWithCreds)
git checkout master
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: 'your build args'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
You don't have to keep the YAML files in the root of the repository; ours are in a dedicated sub-folder:
That's crucial, because it means that we can add a PR policy which restricts who can approve changes to any of the pipeline YAML files.