I have recently updated from install4j6 -> install4j9, which I use within in my build server in bamboo. Bamboo has no issues code signing the files but the notarization process in never ran. I have no issues doing this manually on my Mac, but within bamboo it never runs. I've seen some posts about xcode plugins for bamboo, but I am not sure whether I need to implement script tasks to perform the notarization manually, or if install4j9 supports this. Any help/resources would be appreciated.
Here are the logs I am seeing from bamboo on my end:
[INFO] Important: macOS media sets have to be notarized before distribution.
[INFO] More information in the code signing help.
install4j can only perform notarization if the build runs on macOS. Notarization involves calling command line utilities on macOS that perform operations that my not be reverse engineered on other platforms.
If notarization might be executed at MacOS only then you can start Remote agent at your Mac env and configure Bamboo Server to send this job to that agent. Then it doesn't matter what OS Bamboo Server is running.
Related
I have ported my project build from buildbot to teamcity and it now fails on a command line step where I call a shell script that:
1) launches the macdeployqt qt utility to codesign the built app and then
2) tries to notarize the app.
I always get a sigsegv during the launch of macdeployqt
Obviously launching the script manually on the same machine and folder works as expected.
The problem was on my side, a JetBrains support staff stated that command-line runner is just calling the script as it is and not modifying any environment. It turned out that the script was failing because there was a double / in a path.
So my problem is that on pure swift project (almost :-) ) with test written also in Swift I got this every build. Build is started via Fastlane 1.63. :
▸ DTServiceHub: Instruments wants permission to analyze other processes. Please enter an administrator username and password to allow this.
▸ Username (jenkins): Password:
▸ Failed to authorize rights (0x1) with status: -60007.
Problem occurs when new command-line-tools and Xcode 7.3 was installed on MacPro with OSX Server. Objective-C project works every time. I've done what was suggested in those threads, didn't work:
Remove the authorization prompt from command line instruments (Under mavericks)
Is there a way to remove the authorization prompt from command-line instances of Instruments (XCode)? and in all other places that I could find. I have no idea how to fix it.
I just experienced a similar problem, triggered by Fastlane scan command to execute tests.
Following the discussion on this issue and this Apple Support discussion I managed to solve it by enabling "Developer Mode" on my CI machine.
$ DevToolsSecurity -status
Developer mode is currently disabled.
$ DevToolsSecurity -enable
Developer mode is now enabled.
I've got the same problem with Xcode 7.3. I wasn't admin on my Mac (I work on a company network) so the network manager gave me the admin rights and it works... I don't know why :)
I'm setting up a build on Teamcity that will build a XCode project, then create a release in Octopus and using Powershell copy the files into a server. However, I'm having an issue, while both steps (Teamcity and Octopus) work independently, currently Teamcity is telling me that my build agent does not complies with the requirement 'OctopusDeploy: Release'.
I've downloaded the plugin that is here, and have managed to put the zip file on the runner directory, and while Octopus restarted and seems to have installed it, it still doesn't show as one of the available Build runners.
Apparently you can't do this, or that's what it seems like. Installing the plugin on a fresh install of Teamcity ignored the Mac build agent, which means it's not compatible.
This makes sense because Octopus uses an exe wrapper so this could be the reason. If anybody finds something else, feel free to contribute.
I'm seeing a bizarre code-signing / file-transfer issue and haven't found any clue as to the cause, wonder if anyone else has an idea.
I have a Mac OS X build server running jenkins which builds and signs mac components and apps just fine. These include apps that are Final Cut Pro X plugins.
When I download a zip file produced by the build system through the browser (from the Jenkins build page) with these FCPX apps, after unzipping the app won't launch - it says it's from an unknown developer, as if it isn't code signed.
And yet if I get that same build output zip another way - downloading via sftp or by afp-mounting the build machine filesystem - it works just fine.
It is definitely code-signed on the build system originally, because the installer (which is built downstream on the build system) deploys the app fully code-signed.
Why would downloading a zip through a browser from jenkins destroy an app's code signature? I've tried it from a few browsers (Chrome, Firefox, Safari) and it's always the same. I'd suspect it's an issue with app bundle bits or sim. except that the download is wrapped up in a zip archive so that shouldn't matter. It's created with the OS-native /usr/bin/zip command (not an ant or python or other possibly non-bundle-savvy version).
So it turns out that it is OS X gatekeeper's fault - it doesn't appear to have anything to do with jenkins. The OS adds a quarantine attribute to the zip which tags along with the app bundle when unzipped, and this seems to cause it to treat the app as unsigned, even though it is signed.
This seems like a bug in OS X. Since the app is signed and the gatekeeper settings are to allow signed apps, it should not be screwing up the app with this quarantine attribute. The app works fine and is treated as signed if it is deployed by any means other than browser download.
There are a few workarounds, some of which a coworker discovered.
One is to download the app by some method other than a browser - I used sftp, afp mounting of the build system volume, and an http request from a python script, and all of those worked.
Another is to strip off the quarantine setting after download:
xattr -dr com.apple.quarantine my_file.zip
Yet another is to use 7z instead of native unzip / Archive Manager to unzip the archive.
I am running TeamCity 7.1.3 (yeah, I know it's an oldie). I have a Mac OS X Yosemite build agent.
I started the agent in the recommended way, sh bin/agent.sh start.
My build configuration contains one command line build step, but it can't run, because I get the following message on my agent:
Incompatible runner: Command line
I think it is a permission issue, because if I start the agent with sudo sh bin/agent.sh start it works. I don't want to run it with sudo though. Is there a permission I can give my agent account to make this work?
Update: it seems "chmod 777" on the buildAgent folder solved the problem. Of course, it is not the most secure idea. Would be happy to know the lowest permissions I need to apply.
When you installed the agent, did you use the Mac setup script in the agent's bin directory? I believe it's called mac.launchd.sh. You can't run it via remote terminal or Apple's Remote Desktop or you'll have issues. From the machine (or via VNC) login as the user you want to run TeamCity and run that script from Terminal. Then the agent will start on user login, and will properly upgrade itself when you finally get to upgrading to the latest TeamCity.
My experience with Mac OS X TeamCity agents improved greatly when I stopped trying to run it in the background as a 'daemon' (launchd's term for a boot service) similar to Linux, and instead ran it as an 'agent' (on login service). Typically on a Mac OS build agent you'll want auto login enabled for bits of Xcode to work correctly. Then you just lock it with a screen saver.