Azure Powershell - load variables from another script file - azure

In Azure DevOps, I have an Azure Powershell task to create some resources using ps1 script in repo. This script working fine.
Now I need to split the script and variables into different files.
I created files SB-Config.ps1 for variables and ServiceBus.ps1 with main script. Moved all vars into SB-Config.ps1 .
Both files are in the same folder and in ServiceBus.ps1 I added:
. .\SB-Config.ps1
But Azure Devops fails with error:
What I'm doing wrong and how to get variables from SB-Config.ps1 script, when running ServiceBus.ps1 file?

I am able to reproduce your situation on my side.
Same issue as yours.
You can run this command to output the location of current work space:
Get-Location
I notice the powershell script file on your side is in the sub folder of Default working directory.
So do you set the work space in the powershell script file you are running first?
Set-Location $env:System_DefaultWorkingDirectory\subfolders
In your situation, I think the issue comes from the current work space is System_DefaultWorkingDirectory , the error output means the script can't get the file you want. This issue only occurs when you select 'file path' to run.

Related

Issue with release pipeline: Powershell script is not running in the working directory specified

In my release pipeline, I have specified the working directory for the powershell under the advanced options as $(System.DefaultWorkingDirectory)/_{project name}
However, when the powershell script ran, the working directory of the script is C:\Windows\System32\WindowsPowerShell\v1.0
Any attempt to change the working directory in the powershell script resulted in an error
"Cannot find path 'D:\a\r1\a_{project name}' because it does not
exist".
Note: My artifact was downloaded from this path so it should exist.
Does anyone know what is wrong?
The path "C:\Windows\System32\WindowsPowerShell\v1.0" is the installation directory of 'powershell.exe' on the agent machine. It should not be the default working directory of the PowerShell task.
On the Microsoft-hosted Windows agents, normally '$(System.DefaultWorkingDirectory)' should be "D:\a\r1\a", and "$(System.DefaultWorkingDirectory)/_{project name}" should be "D:\a\r1\a\_{project name}" not "D:\a\r1\a_{project name}".
It seemed did not correctly combine the path string for the specified working directory. A slash (\) was missed that caused the system can't find the path.
You can try to change "$(System.DefaultWorkingDirectory)/_{project name}" to "$(System.DefaultWorkingDirectory)\_{project name}" to see if it can work. Or try other agents.
However, I tested on my side and everything is working fine. The specified working directory can be correctly recognized.
PowerShell Tasks
Results:

AWS Elastic beanstalk - My deployed app can't seem to write pdf's into this directory i've set up in my project folder

I am currently using nodejs that is deployed in ebs on aws. I have a function that will write a pdf and then email it off but it says the file path can't be found. I've verified the project file seems to be /var/app/current/, but changing the reference of the file path doesn't seem to remove the error. Any idea how to go about fixing this?
The /var/app/current/ does not exist initially. Its only created at the very last stage of your deployment.
The deployment happens in /var/app/staging/ folder, and at the very last, once everything finishes, /var/app/staging/ is moved into /var/app/current/.
Thus, I would not recommend using absolute paths in your project or config files. Its better to use relative path or container_commands for config scripts:
The specified commands run as the root user, and are processed in alphabetical order by name. Container commands are run from the staging directory, where your source code is extracted prior to being deployed to the application server.

Deploy Nodejs apllication on azure linux vm using azure release pipeline

I am creating CI & CD pipeline for nodejs application using azure devops.
I deployed build code to azure linux vm using azure release pipeline, here I configured deployment group job.
In deployment groups I used extract files task to unzip the build files.
Unzip will works fine and my code also deployed in this path: $(System.DefaultWorkingDirectory)/LearnCab-Manage(V1.5)-CI (1)/coreservices/ *.zip
After that i would like to run the pm2 command using azure release pipeline, for this task i take bash in deployment group jobs and write the command
cd $(System.DefaultWorkingDirectory)/LearnCab-Manage(V1.5)-CI (1)/coreservices/*.zip
cd coreservices
pm2 start server.js
But bash not executed it will give exit code 2.
it will give exit code 2
This error caused by your argument are using parentheses ( in the command at your first line. As usual, the parentheses is used as group. This could not be compiled as a normal character in command line.
To solve it, you need transfer the parentheses as a normal character with \:
cd $(System.DefaultWorkingDirectory)/LearnCab-Manage\(V1.5\)-CI \(1\)/coreservices/*.zip
And now, \(V1.5\) and \(1\) could be translated into (V1.5) and (1) normally.
And also, you can use single or double quote to around the path:
cd "$(System.DefaultWorkingDirectory)/LearnCab-Manage(V1.5)-CI (1)/coreservices/*.zip"
Or
cd '$(System.DefaultWorkingDirectory)/LearnCab-Manage(V1.5)-CI (1)/coreservices/*.zip'

Azure webapp deployment fails after removing Composer SiteExtension

I had Composer Site extension installed till now on azure php webapp.
I need custom deployment that can run grunt tasks also. So I created the .deployment and deploy.sh files in project root. But that deploy.sh is not being picked up.
.deployment file contents:
[config]
command = bash deploy.sh
Looking at the deployment logs, I find this
2017-05-04T06:21:03.9301086Z,Updating submodules.,8bc3029f-d77b-4c1e-860f-a3d439d7a354,0
2017-05-04T06:21:03.9926050Z,Preparing deployment for commit id 'e2b45fb52b'.,61c286b1-5c00-4c11-ae14-54e0711d6857,0
2017-05-04T06:21:04.2632947Z,Running custom deployment command...,e71c397e-bc63-4357-abc4-acd49bc2041d,0
2017-05-04T06:21:04.3101663Z,Running deployment command...,24db1c4f-8a51-463b-8c4a-ee040bc5dfd8,0
2017-05-04T06:21:04.3101663Z,Command: D:\home\SiteExtensions\ComposerExtension\Hooks\deploy.cmd,,0
2017-05-04T06:21:04.4039215Z,The system cannot find the path specified.,,1
2017-05-04T06:21:04.4195462Z,The system cannot find the path specified.\r\nD:\Program Files (x86)\SiteExtensions\Kudu\62.60430.2807\bin\Scripts\starter.cmd D:\home\SiteExtensions\ComposerExtension\Hooks\deploy.cmd,,2
Seems like somewhere the trigger for Composer site extension still remains which is being invoked during deployment.
How can I completely remove Composer site extension and use my custom deployment script deploy.sh? Thanks in advance.
Found the problem. After uninstalling Composer SiteExtension, this environment variable is still present APPSETTING_COMMAND = D:\home\SiteExtensions\ComposerExtension\Hooks\deploy.cmd. Deleted the environment variable using kudu console and then deployment succeeded.
After removing the Composer Extension the APPSETTING_COMMAND remains as an environment variable.
Use the Kudu PowerShell command Remove-Item Env:\APPSETTING_COMMAND to remove the variable online.
Alternatively, restarting the App Service via the overview tab will refresh the environment variables, though this could be a little invasive.

Run executable from local storage using Azure Web Role

i'm trying to run a simple executable using an Azure Web Role.
The executable is stored in the Web Role's local storage.
The executable produces a log.txt file once it has been run.
This is the method I am using to run the executable:
public void RunExecutable(string path)
{
Process.Start(path);
}
Where path is localStorage.RootPath + "Application.exe"
The problem I am facing is that when I open the local storage folder the executable is there however there is no log.txt file.
I have tested the executable, it works if I manually run it, it produces the log.txt file.
Can anyone see the problem?
Try setting an explicit WorkingDirectory for the process... I wonder if log.txt is being created, just not where you expect. (Or perhaps the app is trying to create log.txt but failing because of the permissions on the directory it's trying to create it in.)
If you remote desktop into the instance, can't you find the file created at E:\approot\ folder ? As Steve said, using a WorkingDirectory for the process will fix the issue
You can use Environment.GetEnvironmentVariable("RoleRoot") to construct the URL to your application root

Resources