I have a Jenkins job set up that builds my iOS Xcode project and archives the resulting IPA file. In addition, I have also installed the Testflight plugin to upload the IPA file as a post-build action. That's all working fine, and my question is this...is there a way to only trigger that post-build action based on the result of a boolean build parameter. There are certain cases where I need to be able to build an IPA and I don't want it to be uploaded to Testflight. If I could just add a checkbox at the start of the build that determines whether or not to upload to Testflight that would be ideal.
Thanks.
Flexible Publish plugin supports Run Conditions. Never tried it myself, but heard good things about it from others.
If you don't mind setting up a separate Jenkins job to do the IPA file upload, you could use the Parameterized Trigger plugin.
Related
I have a job to maven build our project, we now have one job per release version. As the number of releases grows, there are too many jobs and very hard to find the one we need.
I wonder if there is a way to launch the same job with different parameters? The problem is one job only has one workspace, so I'm not sure if it's possible?
Thanks.
Use This build is Parameterized option to build the jobs. Using this you can build the same job for different parameters. You will be asked to enter the parameter before building or you can also give a default parameter and you can have multiple parameters.
It is good the archive the artifacts which you need later.
You can also have the option keep build forever, this will keep the builds permanently Ir-respective of the number of builds to keep.
To use above option you should enable Discard old build option.
You can also link your repository directly to Jenkins which will trigger the job whenever a new commit is made to master or a new tag is created.
I have a strange use case here I know, but basically I have a CI / CD solution that starts be a developer creating a zip file of a set of resources. This zip is then sucked in to SVN via the tools internal programs.
Currently the solution works, using the FSTRigger to poll for an updated zip. When it see it, then the process kicks off and we're happy.
going forward I'd like the builds to be triggered by a Jira job reaching a certain status and have been looking at the Jira trigger plugin. It looks like it will help satisfy me with regards the triggering of the build and passing data from Jira to Jenkins to use for delivery notes etc. However it would still depend on the zip file being in a certain location to be picked up.
I'm wondering if it's possible to attach the zip to the Jira task and then as part of the task status hitting 'build' kick off the Jenkins job and copy the zip so it can be picked up by by the Jenkins build task.
for reasons to complex to mention, checking the zip into svn first won't really work.
When your Jenkins build is triggered via jira-trigger-plugin, you would be able to access JIRA_ISSUE_KEY environment variable that contains the JIRA issue which status has changed.
With the JIRA issue key, you can hit Get Issue JIRA REST API to retrieve the issue details. The issue details would contain the attachment information, which would then be able to be used for downloading the zip in Jenkins.
We are now experimenting with multi-branch Pipeline builds. The main advantage of the feature is that it allows us to automatically create new Jenkins jobs whenever a new branch is created.
However, it also is a bit more difficult to implement than the old way of selecting how to do the build using the UI. Plus, certain features seem to be missing.
For example, in Jenkins Freestyle jobs, we are able to use the Jenkins UI to browse through the workspace, download individual files, and even wipe out the workspace. We found this helpful when builds went awry or if the developer needed a particular built asset that wasn't archived.
I've noticed in the Jenkins Pipeline jobs the UI no longer offers access to the workspace. I know I can archive the workspace, but I really don't want to save it -- especially for each and every build. I simply want to be able to browse the workspace or clean it out if something is causing problems with the build process.
Is there a way to get back this feature via the pipeline? I don't want to archive the workspace for each build (space issues), but I do want to be able to see what the workspace looks like if there are problems.
Freestyle Job with Workspace UI
Pipeline Job. No ability to browse Workspace
You can see your work space in three simple steps:
First, go to the build run you are interested in and click “pipeline steps”.
Then click “allocate node: start”. If you have multiple nodes, you’ll need to do this more than once.
Then you click the workspace link. (it appears on the left pane).
You can also click on Build Artifacts on build page:
I have a plugin in Jenkins for Checkmarx which scans the source code for static code analysis. Is there to make that plugin be compulsory for every job in jenkins?
For that matter any plugin.
The answer, that you probably don't want to hear, is: No.
The only way you can enforce something to happen at all times, is by writing your own plugin for your own "Project type" (instead of Maven or Free-style), and then enforce that everyone uses your project type.
Found a implicit way to do it.
Using jenkins rest api(batch,python,ruby) - run through all job
config.xml.
Download the jobConfig.xml
Update the xml with the plugin(checkmarx in this case) config
Upload(POST) it back to jenkins server.
Run this on a schedule and it shall force everyone to use it.
As I said its an implicit way of doing it.
Checkmarx plugin provides a build step, so it will run every time the job runs. No need to force, if I understand the question correctly. Just make sure the "Skip scan if triggered by SCM Changes" flag is unchecked, which is the default. See more info about the plugin here: https://checkmarx.atlassian.net/wiki/display/KC/Configuring+a+Scan+Action
Downloading the config.xml for the job and posting it back is a bad idea for several reasons. First checkmarx does not require the code to be compiled so you are wasting precious cycles on a build slave. Second Jenkins jobs can do more than compile and they could deploy to production accidentally. Just don't do it. The best way to do what you want to do is to download the config.xml file and then extract the repository url. You can use the Checkmarx rest api to perform a scan. You can probably name the program in checkmarx in some way to relate it back to the jenkins job.
At the moment we have our Jenkins Jobs configured so the Test Results get written to a specific file and then published. The problem with this is the next time the build runs it replaces the previous test results. This means the link the the email notification points to the same test results file and we are not able to debug why the tests failed.
Is there a way to create test results with a unique name like a time stamp and publish these?
You can use the archive function of Jenkins. Add the post build action "Archive artifacts" to your job and give the filename pattern of your test file. Now the file is archived for every job. The link in the mail notification may still point to the newest file, but you can download the archived files in the web interface of Jenkins (if you go to a specific build, you see all archived artifacts of that build).