I have a jenkins job using xcode to build my ipa file. That is all working great. Right now I just have the Marketing version set to ${BUILD_ID} and the technical version set to ${BUILD_NUMBER}. I also have Release configuration specified and my job is set to archive the ipa files as a post build action. I believe those combination of settings causes my resulting IPA file to be the following:
Target-Configuration-BUILD_NUMBER.ipa
So if my target was named BillyBob and this was the 23rd successful build, my resulting .ipa file is:BillyBob-Release-23.ipa
I want to setup a job or post-build action to upload my file to testflight on a successful build.
I can not figure out what to set the file parameter of the testflight API to so that it will always find the latest build file, I don't think there is a wildcard available or if there is I don't know how to set it.
Originally, when I wasn't setting the technical version as part of the build I had it just pointed to the -1.0.ipa version of the file it was creating and that would get uploaded fine.
I've tried using both the testflight plugin for jenkins and just a curl shell script command.
I will also point out that I'm not an iOS developer, I've just been trying to help the project by setting up the automated build, so my guess as to how that file is getting generated could be way off.
***UPDATE
So it looks like this current open issue is kind of what I am looking for
jenkins issue section
For now, I just had my job specify an output path that is the workspace of my upload to testflight job.
It looks like in the Testflight app, if you don't specify anything for the IPA file, it looks for one in the workspace directory of that job. So I could probably also put in a request to the testflight plugin to allow you to specify a path in the IPA setting and have it find the .ipa file in that path, that currently does not work.
If I was better at scripting I could probably also handle it in a shell command using the curl command to upload to testflight.
Leaving those fields empty in Jenkins fixed it for me.
If you do not specify the ipa/dsym file(s) they are searched for
automatically in the workspace.
As you can see from:
https://wiki.jenkins-ci.org/display/JENKINS/Testflight+Plugin
Version 1.3.1 (Jan 12 2012)
* Default IPA upload
Related
I need one help,
I am Executing a script of robot framework using Jenkins, as per the flow the script should download one XLS and validate the data using Pandas.
When I am executing the script using Jenkins and searching the downloaded file in a hardcoded path i.e. "C:\Users\Administrator\Downloads" the file is not found.
but when executing it manually the file downloaded on the same path
Can anyone please help me by telling me where do Jenkins stores all the downloaded files?
PS : I am using Google Chrome as web browser
For each job Jenkins runs, it creates a workspace directory, usually at:
$JENKINS_HOME/workspace/(Name of the Job)
The scripts (and robotframework's in this case) are run there, as the root directory. Most probably the downloaded file will be in a path from there (or an error should have occurred because the Jenkins user does not have access to the C:\Users... path).
There is a step in the Jenkins job, which is to archive (download) files from workspace, to Jenkins database, to be shown as "artifacts". Even the screenshots images or videos recording, must be registered in that step, so they can be viewed on the Report and Log in Jenkins (Robot Framework Plugin).
I've been trying to follow the
Setting Up Stackdriver Debugger for Java applications on Google Compute Engine, but am running into issues with Stackdriver Debug.
I'm building my .war file from a separate build server, then deploying it to my GCE server. I added the agent to the start command via /etc/defaults, and my app appears in the https://console.cloud.google.com/debug control panel. The version I set in the run command matches the revision that shows up in the source-context(s).json files.
However when I click open the app, I see the message that
No source version information was provided by the deployed application
I connected the app's git repo as a mirrored cloud repository, and can browse the source files in the sidebar of the Stackdriver Debug page. But, If I browse to a file and add a breakpoint I get an error that the error "File was not found in the executable."
I have ran the gcloud preview app gen-repo-info-file command, which created two basic json files storing my git repo and revision. Is it supposed to do anything else?
I have tried running jetty using both normal and extracted modes. If I have jetty first extract the war file, I can see the source-context.json filesin the WEB-INF/classes directory.
What am I missing?
https://github.com/GoogleCloudPlatform/cloud-debug-java#extra-classpath mentions
you can update the agentPath showing your WEB-INF/class directory.
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes
For multiple class paths:
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes:/another/path/with/classes
There are a couple of things going on here.
First, it sounds like you are doing the correct thing with gen-repo-info-file. The debugger agent should pick up the json files from the WEB-INF/classes directory.
The debugger uses fuzzy matching to find source files, so as long as the name of the .java file matches a file in your executable, you should not get that error.
The most likely scenario given the information in your question is that you are attaching the debugger to a launcher process, rather than your actual application. Without further details, I can't absolutely confirm that, though.
If you send us more details at cdbg-feedback#google.com, we can look more closely at your case to see if we can understand exactly what's happening, and potentially improve our documentation, since it sounds like you followed the docs pretty closely.
I am running Jenkins on a script, that generates a junit.xml report file and other files. However, all those files are zipped by the script, hence Jenkins cannot find it.
Is there a way to make Jenkins unzip the .zip file , find my particular junit file and generate the run results ?
All this is in Linux.
Thanks
Jenkins has the ability to execute arbitrary shell commands as a build step, just add the 'Execute Shell' step to your build and put in the commands you want (presumably 'unzip' would be among them).
Once you've extracted the xml, provided your internal tool generates it using this schema the JUnit plugin just needs the path you extracted to and it will show the results on the build page.
If you have the option, I would really suggest executing your tests via gradle or maven, as outputs from those tasks will produce a report that Jenkins (and other tools) can already read, and can streamline the job setup process for your users. But, if you can't get away with that, the above should work for you.
I ran into a problem creating a new project in Cocos2d-x 3.1.1 (or 3.0 - it happens at both versions).
When I'm running the build script in console (Windows 8 - console with admin privileges) an WindowsError pops up (check the image below).
http://i.imgur.com/Ixg4jEE.png
I can set up the COCOS_CONSOLE_ROOT manually, but it does not help with the Error 5.
I tried setting the 777 priviligies an all cocos2d-x folder and subfolders, but it does not help.
Anybody had the same problem? Any solutions out there?
On Windows you should not put manually installed programs and tools under C:\Program... (english: C:\Program Files) because that's a folder where only apps with a proper installer should go. Otherwise you will keep having permission issues. Apps are not allowed to write to that folder or any of its subfolders.
Since cocos2d-x isn't an app, it can't redirect its output to the proper AppplicationData folder as is mandated by the operating system. Not being able to write or modify the program folder's contents (except during installation) is a security feature in Windows that you can't (or shouldn't) bypass.
To fix this simply extract cocos2d-x in a folder that both you and apps have full read/write permission. Normally this would be in your Documents folder, but Desktop would also work and probably just any folder on a drive that you created, for instance C:\cocos2d-x.
Due to this line:
_winreg.SetValueEx() ...
the actual problem looks like to be with registry access, rather than with file permissions.
Make sure you actually running console as an admin, by:
searching cmd in Windows search, or just creating a shortcut to it to desktop
right clicking to cmd.exe and choosing "Run as administrator"
Make sure you don't have registry access block in any way: like blocking in group policies, some "security optimization" software and viruses and antiviruses.
Make sure your python version is 2.x. Python 3.x is not supported.
Anyway, this 'setup.py' step is optional for using cocos2d-x and you can live without running it at all.
I currently have Jenkins set up with a number of jobs, but it's proving difficult to back up because the artifacts are stored within the job directory. I'd like to back up the job configurations and artifacts separately. I'm sure I remember reading somewhere that Jenkins now has an option to store them outside the job, but I can't find this.
Is there any configuration option that does this while still making the artifacts visible from within the job on the Jenkins interface? (ie rather than merely an add-in that copies the artifacts elsewhere)
Go to your jenkins configuration page, e.g.
http://mybuildserver.acme.com/configure
At the top of the configuration page there is a "home directory" setting. Click the "advanced..." button below it.
Now set the "Workspace Root Directory" to e:\jenkins-workspaces\${ITEM_FULL_NAME}, and "Build Record Root Directory" to e:\jenkins-builds\${ITEM_FULL_NAME} or something similar.
Warning: I run Jenkins 2.7.2 and noticed that certain features don't work properly after configuring Jenkins like that. I saw problems with folders and problems with the multi-branch project plugin. Check the status of those issues if your rely on these features.
As you can see here, there are many plugins to deploy artifacts anywhere you want/need, on FTP, CIFS, Confluence, Artifactory.... especially the ArtifactsDeployer that will allow you to make a copy of the artifacts in the Jenkins Home.
Thank you Sam, for your post, which directed me into the right direction to solve my problem.
Have been searching for a way on how can I make a symlink to the Job-Archive of a build for multibranch projects. Up to now, we used to manually search for the correct folder basename in the filesystem and added that one to the Jenkinsfile.
Now, I can simply use
jobOutputFolder = currentBuild.rawBuild.artifactsDir.path
and use that in my script.
If security is a concern, I could implement that as a shared library additionally.
Try the Use Custom Workspace build option. From the Jenkins popup help:
For each job on Jenkins, Jenkins allocates a unique "workspace
directory." This is the directory where the code is checked out and
builds happen. Normally you should let Jenkins allocate and clean up
workspace directories, but in several situations this is problematic,
and in such case, this option lets you specify the workspace location
manually.
This option is also available under advanced project properties of multi-configuration project builds.
A groovy script under "Prepare an environment for the run" will always run on the master, and this groovy script can create a symlink to where you really want artifacts archiving to archive_to which SHOULD include the job name and build number:
if (! Files.createSymbolicLink(Paths.get(currentBuild.artifactsDir.path),
Paths.get(archive_to.getCanonicalPath()))) {
throw new RuntimeException("Can't create symlink to archive dir")
}
Of course (sadly) when old builds are purged by Jenkins the old artifacts are left because jenkins will not follow a symlink when purging, even if jenkins owns the symlink and the target (shame).
I workaround for that may be to point a symlink back from the new archive dir, then, when jenkins purges it's archive dir, the new symlink will dangle and a cron job can then later delete the new job archive dir
Copy Artifact Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin) adds a build step for retrieving files from another project's workspace to current and work from there.