Are there instructions for using the xcode plugin from a jenkins pipeline?
I'm moving some freestyle projects to pipeline and have realised I've left a step out: Import developer profile. I'd like to know how to do that from a jenkins pipeline. I assume this should involve the xcode plugin, but it does not come up in the snippet editor and I see no documentation.
I got a steer to this on the Jenkins site.
IF on the snippet generator, you look under steps, there is something that generates xcode-related fragments. Don't know why this does not come out under xcode, like other plugins, but I guess that is a different matter.
I have not yet worked out how to do my original scenario but I guess I need to sit down some time and give it a good try. In the meantime, I'm using secret text for the password I need.
Related
I am currently making a jenkins project on an EC2 instance using ubuntu and have learned about jenkinsfiles. My already made pipeline to automatically detect changes to a github repo is the one I want to make run the jenkinsfile which as of now has only echo commands. Is this possible? I cannot seem to find much at all about this.
I have tried looking it up on youtube and google to no avail. Youtube videos show people creating new pipelines but I am wondering if its at all possible to do it on an already made freestyle project.
I don't think you can do that. When you create a new job you have to chose if it's a pipeline or not. There may be some workaround to run a jenkinsfile from some magic shell script, but that's already sounds making more problems than how many it solves.
I tried continuous integration tools Travis CI, CircleCI and codeship, but found none of them provide support document for phabricator. Does anyone have ideas about how to do continuous integration (CI) with Phabricator?
I have done an integration with Travis-CI by adding post diff and land hooks to Phabricator to push diffs as branches to GitHub where Travis looks for branch updates. As far as I know, Travis-CI integrates only with GitHub, so if your main repo is there and Phabricator is pointing to it, it can be done.
If you want to take this approach, the place to start is with creating your own ArcanistConfiguration and overriding didRunWorkflow. See also how to create a new library. The API documentation is pretty good, but I had to go through some trial and error to get what I wanted. The Phabricator people are probably happy to answer questions.
You can also look into the Phabricator conduit differential.createcomment to script messages to diffs like so:
arc call-conduit --conduit="https://my.phabricator.com/" --arcrc-file="robot.arcrc" \
differential.createcomment <<EOF
{"revision_id":"1234","message":"Yer build done failed"}
EOF
Where robot.arcrc is an arcrc file with the credentials to push messages, and 1234 is the revision number. You would have to use the conduit API to get the revision number.
So, I think the answer is you may have to build your own custom solution depending on which CI integration for the CI tool you want to integrate with. And here's a discussion of Travis support for Phabricator.
Edit: Here's traphic, an example of extending arcanist to push diffs to branches on GitHub on arc diff and remove them on arc land. As Travis-CI looks for update from GitHub, it will build your diffs.
Side note: This is mostly a brain dump. I know good answers have more code examples and links are frowned on, but the question was pretty open ended and was looking for pointers, so I'm trying to be helpful.
If you are using Jenkins, the nice guys at Uber created a Jenkins Phabricator Differential plugin that makes it possible to really clean up your job configs (if you've already set them up using the links from zerodiff's post).
Might be worth noting that Phabricator's tool to do continuous integration (i.e. Harbormaster) is currently under development.
You can find this in a table in their comparison page. See http://phabricator.org/comparison/
I am trying to create 1 package with multiple build configurations. The first will checkout the code, build it (Solution File configuration), and run nunit tests. If that succeeds, another will then build in release mode. If that succeeds, a final script witll package up the output, and mark it as an artifact.
The problem I'm having is that I don't know how to tell TeamCity not to create new directories for each step, and as a result, the steps are failing. Is there a setting for this? It seems like the dependencies tab would be an appropriate place to look, but I don't seem to understand the instructions, and my tinkering so far has been fruitless.
I basically skipped most of the TeamCity workflow, and instead used a scripting language to handle all of this. (I used Rake and Albacore, which I highly recommend for .net projects)
I'd caution you not to use powershell w/ TeamCity. You have to wrap everything in .bat file, which is fairly excruciating.
So the result, is that I have 1 checkout, and everything builds from this point. It's drastically cut down the amount of time required for the builds, though perhaps that wouldn't be the case if I had a lot of agents available.
We have a large collection of nAnt scripts that build our various products. They almost all have the following structure:
Erase old working copy.
Check out complete fresh copy from version control.
Increment build number in appropriate file (custom nAnt task).
Run static analysis (StyleCop, Perl scripts)
Build solution using Visual Studio - ends up with MSI output.
Run unit tests (nUnit, JSUnit)
Run static analysis (FxCop)
Zip up deliverables (MSI, readme, etc) into well-named package.
Put this zip package onto a server share.
Email results to team.
From our research, it seems that CruiseControl(.net?)/Hudson/BuildBot would only add the trigger that causes the build, which at the moment is double-clicking the nAnt script over Remote Desktop and a status dashboard.
Are we missing anything else significant?
The question is subjective, and thus so is my answer.
In the projects I've automated before, CruiseControl was used essentially for that one purpose: so we didn't have to remote into the build machine and trigger builds. The CI part is that CruiseControl will monitor the repository for you, triggering builds at the intervals you define.
It also gave us the dashboard from which could trigger releases, or go back to examine logs and artefacts from past builds.
For us that was enough benefit to implement CruiseControl. Perhaps it doesn't "seem" like much until you've finished it and a month later realized you haven't had to touch your build system because it's off silently and thanklessly doing its thing for you.
A Continuous Integration server such as Hudson would do 1, 2, 3, 9 and 10 for you so that you don't have to implement them yourself. If you've already got it working that's maybe not a huge improvement for your current project but it makes things simpler for subsequent projects. It would also, as you mention, take care of when to trigger the build.
Hudson will also chart various trends over time, such as test coverage, build time, static analysis results. You can also have more sophisticated notifications than just e-mail if you choose.
The most important thing it gives you is visual feedback (the bigger the screen is better). When you have one machine, dedicated to displaying buildresults, visible to all team members, it works like a catalyst to people see that something is wrong and fixes it.
If you have something like that standing in a place where your boss can see it and ask you "Hey Wilkinson, why is this screen red?" will you fix your build faster?
Thay all look the same, you can pick whatever you think fits your needs, just have one setup and running.
These questions are for TeamCity users only
1) Is it possible to configure TeamCity to extract build artifact information based on your own your regular expressions? This is exactly what Pulse does here
2) Does TeamCity integrate with any task/bug tracking tool? like JIRA?
3) This question is for people who run static code analyzer only. A tool like PC-Lint/Visual Lint can generate XML reports. Can TeamCity be configured to parse these artifacts and generate a build failure?
4) I'm currently evaluating TeamCity right now...there community forum doesnt seem to be very active. For those who pay for support, how is Jetbrains support? Is it good? Atlassian seems to be much better.
TeamCity allows to get build artifacts with a Ant-based pattern. You can specify multiple patterns and set target directory for each pattern. Read more at http://www.jetbrains.net/confluence/display/TCD4/Build+Artifact
There is an integration which allows to link RF-3432 to the Jira issue. More advanced integration may appear in the next release of TC. Read more at http://www.jetbrains.net/confluence/display/TCD4/Mapping+External+Links+in+Comments
Only with custom plugin. Or your build process can send a specific "echo" message which will change build status and description.
OK, I'm JetBrainer. May be we don't response immediately, but we strive to answer forum questions ASAP. Paid customers also have e-mail support.
Hope this helps,
KIR
Disclaimer: I don't work for JetBrains! But I've worked with Pulse and TeamCity in my current job.
Build Artifacts: Yes, TeamCity will export artifacts that remain after a build. You can add define ant-style wildcard patterns to match files (the default pattern matches any files left in the root build directory). These files can be seen from the project view against each individual build.
You can use special service commands in a build script to immediately export artifacts along the way too, I do this for a code complexity tool that generates xml files, for which I've also defined a custom graph.
Bug Tracking: I don't have experience with this, but KIR pointed out some alternatives.
XML Parsing: You can control this with ant. I included a third-party tool called andariel in my build that can run XPaths across xml documents, then used service messages to export the result (in this case a count of methods exceeding a complexity limit) to be displayed in a custom graph.
I believe you could also publish the artifacts, provide TeamCity with an XSL to render the XML, and create an additional tab in your build results to display it (however I have not done this)
Tech Support: I've found the community forums to be pretty good, most questions I've had answered within a day or two by both civilians and Jetbrains employees, and I was using the free 'Professional' version.
I can only imagine that email support will be just as good if not better!
I am a little confused about this question because my use of TeamCity, TC (and I guess the design principles of TC) is to allow the build script (and not TC) to remain the correspondent of build imperatives.
In other words, if you need TeamCity to do something cool, just add that cool stuff in your build script either using an existing task in your build system or write one yourself.
TeamCity supports NAnt, MSBuild, Ant and am sure, any other build platform you can install on on the buildagents.
The only integration I will want TC or any other CI platform to have is source control integration with my choice of SC. The rest of the integration should be controlled by my build script. That way, I only configure my TC once at the beginning of project for each project and then, don't touch it ever again. In contrast, the build can change per version.
So, the indirect answer to your question is Yes, theoretically, through the build script.
Hope this helps.