I’m trying to perform some some steps within my fastlane from an AppleScript. I’ve not been able to find any documentation about this.
I know you can run shell scripts from the fastlane but I’m not sure whether you can run AppleScripts
One way to achieve this would be to create a shell script that executes the AppleScript:
<root>/test.sh:
#!/bin/bash
osascript <<EOD
tell application "Google Chrome"
activate
end tell
EOD
<root>/fastlane/Fastfile:
platform :ios do
lane :test do
sh('../test.sh')
end
end
and run it using bundle exec fastlane test
Related
I am able to configure Fastlane locally and working well with terminal, but when I am trying to run it with Jenkins(I have configured Jenkins locally on my macbook) it is failing every-time(i have installed ruby 2.5.0 again).
Any help on the same would be highly appreciated.
I am attaching SS for your reference.
Jenkins run its build scripts using specified user 'jenkins'. You might want to check if 'jenkins' user had installed requires dependencies to run fastlane, for e.g ruby ...
Have you set up your PATH in Jenkins? In the configuration of your node, in the environment variables section, you'll want to include /usr/local/bin/ with Jenkins's PATH by entering /usr/local/bin/:$PATH.
I have a linqpad script which we need to run as part of our release, from VSTS. Best way I can think of is to run this as a Powershell script. There seem to be 2 options to be able to do this
Linqpad's native lprun.exe
Linqpadless lpless.exe
The problem with these however is that I will have to install these on the Build/Release VMs for each environment, which is what I'm trying to avoid at the moment.
Linqpadless does distribute a nuget package but I don't know how to run that from powershell/release pipeline.
Has anyone done something similar. What's the best way to achieve this?
You can add three tasks in your build definition to do this:
Nuget Task to install linqpadless package:
Command Line task to run lpless.exe:
Command Line task to run the script generated by lpless.exe in last step:
If you want to use Powershell script, you just need to call these command in the script one by one.
I installed VSTS build agent on mac to build xamarin iOS project. Builds worked fine until I added powershell build step.
Even though I installed powershell for mac (https://github.com/PowerShell/PowerShell) and re-installed the agent, VSTS complains it does not have agent that is capable to run the build.
No agent could be found with the following capabilities:
DotNetFramework, Xamarin.iOS, npm
When I disable the build step, builds work just fine.
Is it possible to run powershell build step on Mac?
As MrHinsh clarified, the PowerShell task cannot be used on Mac.
As a workaround I used ShellScript task:
With the following bash script:
#!/bin/bash
powershell ./SetAppVersion.ps1
Also, the powershell installer did not seem to add powershell to my PATH so I had to add it:
$ export PATH=$PATH:/usr/local/microsoft/powershell/6.0.0-alpha.16
If you're sure that DotNetFramework is installed then you can go to the Agent Queues settings and add a custom Capability to it called exactly that.
That should allow it to run but it might fail after that if the agent can't actually find them, but it might also succeed so it's probably worth a try.
No, you can't use a PowerShell task on a Mac, only node tasks are supported.
PowerShell tasks as currently written in PowerShell3 which is not supported on Mac. You can request that the team implement this on http://visualstudio.uservoice.com
In TFS build go to Agents Queues=>Capablilities=>Add variable named as DotNetFramework and give value for mac agent's dotnet framework path.
It's fix for the issue "No agent could be found with the following capabilities:DotNetFramework"
This is a follow-up to the accepted answer to address a question in a comment which I also had.
Thanks to spatialguy for posting and finding a simple solution to this problem. I had the same problem as KeithA45:
QUESTION: What if you wanted to do the same, but also pass arguments to the Bash script which passes them to the Powershell script?
I found a solution to this, first off, I modified the shell script task to include the Visual Studio Team Services (VSTS) environmental variables that I wanted to pass to the powershell script.
Next, I pass the arguments through to the called powershell script by slightly modifying the shell script mentioned by the accepted answer.
#!/bin/bash
powershell ./Version.ps1 $1 $2
Finally, in the powershell script, I catch the arguments that have been passed through using using param like this:
param([string]$version, [string]$path)
Wherein I can now use the variables $version and $path which contain the original arguments entered in VSTS to the needs of my powershell script.
Things seem to have moved forward because I ran successfully today a PowerShell#2 task on a Mac Self-Hosted Agent from an Azure DevOps build pipeline.
By checking "Enable system diagnostics" when queuing the build, the log shows me that the task found itself the path to the PowerShell Core (pwsh) that I installed on my Mac with the help of Homebrew (brew cask install powershell - see https://learn.microsoft.com/fr-fr/powershell/scripting/install/installing-powershell-core-on-macos).
I have a gradle build, which runs a few tests on our application. Currently the tests that store assets in mongoDB fail if the developer forgets to run mongod first. So I want any build that uses mongoDB to fail with a message the user that clearly tells him to start mongoDB. Ideally, later we would start mongoDB from gradle.
I already found this nice article about how to see if mongoDB is running under Linux, which is quite simple. I am sure something similar can be done under Windows using tasklist /FI "IMAGENAME eq mongod", etc. But I need to know how to use this correctly in gradle.
Is there a cross platform way to check if a service or normal process is running in gradle?
The suggestion provided by Orid to use the Gradle Mongo Plugin should work if you set the necessary Gradle tasks to be dependent on a startManagedMongoDb task.
While that may seem to be the easiest way, it may be breaking with how MongoDb will be used in non-development environments or on a continuous integration build-server, where the MongoDb service will already be running.
A very simple solution would be to add the MongoDb checking functionality to the top of a customized gradlew.bat (and the gradlew bash script if it will be run on a *nix operating system).
Another simple solution that wouldn’t require changing the gradlew.bat script would be to create your own MongoDb checking script that then called gradlew.bat, passing on command line arguments. I’m not sure if there is an equivalent to the bash $# for all positional arguments in windows, but looping through the arguments with SHIFT %1 can be used to generate the gradlew.bat command line.
As I understand, all that Capistrano does is ssh into the server and execute the commands we want it to (mostly).
I've used rvm in some past couple of projects, and had to install the rvm-capistrano gem. Otherwise, it failed to find the executables (or so I recall), even though we had a proper .rvmrc file (with the correct ruby and the correct gemset) in the repository.
Similarly, today I was setting up deployment for a project for which I'm using pythonbrew, and a simple "cd #{deploy_to}/current && pythonbrew venv use myenv && gunicorn_django -c gunicorn.py" gave me an error message saying "cannot find the executable gunicorn_django". This, I suppose is because the virtualenv was not activated correctly. But didn't we activate the environment when we did "pythonbrew venv use myenv"? The complete command works fine if I ssh into the server and execute it on the shell, but it doesn't when I do it via Capistrano.
My question is - why does Capistrano need modifications to play along with programs like rvm and pythonbrew, even though all it's doing is executing a couple of commands over ssh?
Thats because their ssh'ing in doesn't activate your shell's environment. So it's not picking up the source statements that enable the magic. Just do an rvm use ... before running commands instead of assuming the cd will pick that up automatically. Should be fine then. If you had been using fabric there is the env() context manager that you could use to be sure thats run before each command.