When I build my target, in the information tab I can see the scheme building and the target building. At the end of the process it runs 2 custom shell scripts.
I can't find where the target or project is running these 2 custom shell scrips. I've looked at target > build phases and it's not being set to run there. I also looked at project > build settings but I can't locate it there.
I don't want to run these scripts but I don' know how to remove them! Any help would be great! Thanks
yup but I know the pods project or targets are not set to run scripts. I've inherited this project on our jenkins it runs 2 scripts at the end of the build. I've removed it from jenkins but not sure how to remove it from the project.
Pods run scripts. Here's the two scripts being run:
If you don't want to use pods anymore, use this pods-deintegrate plugin to remove all traces of pods.
Related
Hit build and nothing gets printed in build log. What gives?
Xcode Version 8.2.1 (8C1002)
Pre-action takes place before the build, so output doesn't go to the build log, it goes to stdErr. You can copy the output to a file:
exec > ${PROJECT_DIR}/prebuild.log 2>&1
echo "hello world"
To get the environment variables to work, you also need to set "Provide build settings from" to the appropriate target.
That should write hello world to a file named "prebuild.log" in your project folder.
for XCode versions < 13.2
If you want these activities to end up in the build log, consider adding a run script to your target's build phase instead.
for XCode versions >= 13.2
The XCode build log now includes a Run pre-actions section. If you don't redirect to a file, those messages will end up as the last item in a 'Run custom shell script' in this section - access via the XCode Report Navigator.
To add to the answer, https://stackoverflow.com/a/42497746/1058199, it's important to not clutter up the project.pbxproj (where build scripts go) or your scheme file (where these scripts go) as much as possible.
With this in mind, I create a Build-Scripts folder in the project root where I put the app build scripts and pre-action scripts. This folder is dragged into the root of the project as a folder so that any script I add to it is automatically added to project.
Assuming that your pre-action script is called That_pre-action_script.sh, this is what I put in Pre-actions script based on the approved answer.
say "Pre build scripts running."
exec > "${PROJECT_DIR}/prebuild.log" 2>&1
echo "Starting build scheme Pre-actions"
"${PROJECT_DIR}/Build-Phases/That_pre-action_script.sh"
As a test, make sure to echo some message from your script so you can see it in the prebuild.log file.
Hope this helps.
And don't forget to chmod u+x your script in the terminal so that it will run.
The important part is if you can't make sure if your build script is running or not. This is where the say command us useful so that you know it's actually being issued before a build.
It's a good idea to put quotes around the path to the script in case there are any space characters (or otherwise) in the path to your project.
I'm looking into TeamCity and Jenkins, for a CI server.
My goal is this: every time someone commits a change to our repo, the CI server builds all targets in the project as .ipa's - ready for downloading/installing on a device.
I got Teamcity and Jenkins up and running, using a Mac mini as a build slave. That part of it is working fine.
Using Jenkins XCode plugin, I succeeded in building all targets as .ipa's.
I havent had such luck with Teamcity. The XCode plugin doesnt allow building all targets. Rather, you have to specify which targets you want to build, in each build configuration.
I approached the makers of Teamcity, and they gave me some convoluted method involving meta runners and a lot of duplication, in order to accomplish my goal.
Instead of relying on plugins, I'd rather build the .ipa's using shell scripting. However, as I'm not a script ninja, I can't figure out how to go about this.
I can figure out how to build one target via scripting, but it illudes me how make it build them all. Everytime I create a new target in the project, I don't want to have to add it at the CI server. The server should be able to automatically build all targets in the project.
...Maybe someone has a better solution? Any help is much appreciated.
What you should do (codes are bash script snippets, ready to run on OS X, you don't need to install anything except Xcode's CLI/Command Line Tools):
if you want to do this for every Xcode project file you have in your repository you should first search for these (if you have a specific Xcode project you can skip this)
for path in $(find . -type d -name '*.xcodeproj' -or -name '*.xcworkspace')
do
after this you can query all the shared (!) schemes through Xcode's command line tool
if [[ "$project" == *".xcodeproj" ]]; then
xcodebuild_output=($(xcodebuild -list -project "$project"))
else
xcodebuild_output=($(xcodebuild -list -workspace "$project"))
fi
now you have all the schemes so you can simply xcodebuild them one-by-one
Here's a bash script we developed to search for every Xcode project and every scheme configuration in a repository: https://github.com/concretebuilder/steps-cocapods-and-repository-validator/blob/master/find_schemes.sh
Note: you need to mark you schemes as shared to get xcodebuild (the command line interface of Xcode) list them.
How can I make Jenkins do the following?
Checkout trunk/ from SVN, then build configurations Debug and Release using CMake, without having duplicate jobs for the configurations.
Took me a while to figure this out. Here's how I managed to do it.
Create a free-style job "Checkout". This job is going to do all the stuff that doesn't depend on the configuration type (Debug/Release).
Under "Source Code Management" select Subversion
Fill in the Repository URL. Probably a good idea to make it point to /trunk.
Set Local module dir to "." (no quotes)
As Check-out Strategy "Emulate clean" is nice
Build trigger Poll SCM, set Schedule to "5 * * * *" to check every 5 minutes.
Now under Advanced Project Options check 'Use custom workspace' and set the dir to e.g. "c:/src". We don't want Jenkins to use its internal workspace, because we want other jobs to be able to access the source.
Under Build add the following Windows batch command, which is used to clean the build dir. For some reason, CMake doesn't provide a way to do this.
cd c:\
rmdir /S /Q build
mkdir build
cd build
cmake --version
rem optionally: svn info c:\src
cmake -G "Visual Studio 10" c:\src
Create another job "Build", this time make it a "multi-configuration" job. This job is going to run for each configuration (Debug/Release).
First, set the Build Triggers to build after job "Checkout"
Now under Configuration Matrix add an axis "configuration" with values "Debug Release" (whitespace = separator). Unfortunately, the CMake builder plugin for Jenkins doesn't work with multi-configuration jobs. We can't even use cmake --build, because it always builds the Debug configuration. To build, we have to use another batch script:
cd c:\build
call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
msbuild ALL_BUILD.vcxproj /verbosity:minimal /maxcpucount:1 /property:Configuration=%configuration%
If you want to build the entire solution, specify the .sln file instead of ALL_BUILD.vcxproj. If you only want to build a specific project, use
msbuild <solution>.sln /target:<project>
Use Jenkins Matrix job. Define one of the axes as build_mode with values Debug and Release. You then run CMake that will create both configurations for the compilation tool you'll be using (XCode, gcc, VisualStudio, etc.). You can then use build_mode as if it were an environment variable and pass it to build steps that do actual compilation.
When using the Visual Studio generator you can pass the configuration to build to the cmake --build-command:
cmake --build . --config Release
cmake --build . --config Debug
See also the CMake docs.
After using Jenkins for a while now, I found that you should use as few jobs as possible if you want to reuse the source directory.
The default setup in Jenkins is that each build uses a different directory as its workspace. Which implies that you do a complete SVN checkout every build. Which takes forever.
If you want to use the same source directory for every build, you have to worry about synchronization: Only one build at a time. As far as I know, Jenkins has no built-in means of synchronization. The only way is to only use one executor. Even then you can't control the way the executor chooses its next job.
Let's say job "SVN update" triggers job "Build". Someone starts "SVN update #33", which is supposed to trigger "Build #33". If, however, Jenkins' "Poll SCM" feature schedules "SVN update" #34 in the meantime, I haven't found a way to tell it that "Build #33" must run before "SVN update #34". So you might end up with "SVN update #34" running before "Build #33", and everything fails. Unless you manually disable the polling job. And remind yourself to re-enable it afterwards, of course.
Anyways. After using Jenkins for two years, I change my answer to: Never use multiple jobs that share resources (like the source dir), and bake all the logic into shell scripts (for loop over configurations).
I have a shell script that runs lcov (test coverage) on an iOS project that I have Hudson. Hudson's copy of this project is derived from a Git repository. The way that I have set up now is that whenever the repo is updated or if someone manually builds the project in Hudson, Hudson would automatically run the app, and then run my shell script after the build is done. lcov can only be run after the app is not only built, but automatically run with some functional test tools. So, I cannot run the shell script as part of the build process, through XCode. It must be run after the app finishes building and running.
However, I would like to use this project in multiple Hudson jobs. Unfortunately, in each Hudson job, the iOS project is named differently. I would like to refer to the build path with some sort of environmental variable, but I don't know how to. Does anyone have any tips as to how to find that?
If I understand you correctly this is really a Hudson question. You can set "global variables" in your Hudson config and then invoke shell scripts, batch files, ant builds etc. You can also set them dynamically on each invocation of your Hudson job. Not sure exactly how to help you in your specific environment without more info.
i'm new to world of continuous integration and software developement.
I wanted to try hudson so i installed it on my ubuntu machine and created a new job. i pointed it to an open source project's svn (keepassx) just to try.
Hudson downloaded everything from the repository and marked blue for successful build.
aren't i suppose to be able to execute the software now somehow ? i thought once it is built i can run it, but i can't find any executable in the project's home page under hudson user home dir.
thanks.
A Hudson/Jenkins build breaks down into three steps:
update source code in workspace
run build
publish build artifacts
It sounds like you've got step 1 covered.
If the project you linked to has instructions for building (ant, maven, etc.), you can enter these as build steps into the "Build" section of the project configuration.
You can then take the resulting files ("artifacts"--jar, exe, so, bin, whatever) and publish these using the "Post-build Actions", or if necessary you can grab them directly from the workspace filesystem.
Assuming the build artifact was an executable, you could then run it after downloading it from Hudson, or make a build step or post-build action which moved it into the appropriate location and ran it.
It helps to run the build locally before trying to get Hudson to handle it--then you know what the build steps are, and what the final build artifacts are.
How would jenkins/hudson know how to 'execute' some arbitrary package that you told it to download and build? It's up to you to write a program or script to run what you want to run, and then make a downstream job (for example) to do so.