I have been trying to build an ios app for quite some time now. I did all the certificate provisioning etc. The problem is that whenever I send the build from netbeans to CN1 build-server it tells me that "you might have ran out of builds"... Mind you, I have only done less than 10 and only 3 of them are iphone (which failed). I know there is also a subscription to this, but I am also aware that there is a free subscription which allows a couple of builds. Is there a way I can fix this build problem. (see the output below)
Sending build request to the server, notice that the build might take a while to complete!
C:\TrueMobile\BeCorrect_\build.xml:82: Failed to upload to server. Its possible you ran out of builds. Please check http://www.codenameone.com/build-server.html
BUILD FAILED (total time: 2 seconds)
iOS builds take up more build credits than other platforms since they take up considerably more server resources. Hosting on a Mac is required (which is REALLY expensive) and the build itself is quite long which delays concurrent builds.
You get unlimited builds for 9USD per month or you can wait for next month and you will get 100 build credits again (iOS takes up 20 the other platforms take up 1).
Alternatively you can get unlimited builds for free by following the instructions here.
Related
I have a VSO release management definition in which I'm deploying a cloud service and then running some tests. The deployment executes without issues, but then the tests don't run, I recieve the following message in the logs:
Warning: No test is available in My DLL Path. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.
Now, the strange thing is that this release is triggered by a build, which runs exactly the same set of tests and they all run happily.
I've included a runsettings file specifying the framework version (based on some SO posts I found from a year ago with a similar issue) but its made no difference. Been messing with this for nearly 2 days now with no progress. Any suggestions happily accepted!
Arrrrgh! So it turns out, if I deleted the whole project, created it again and added my tests again, it just works. Gremlins apparently!
Admins, if this needs to be deleted, go ahead
I've been trying to include Fastlane in a CI environment where the following should happen:
any commit to the master branch should trigger a test run and then a build into Testflight.
any commit to the development branch should trigger a test run and then a build into Fabric Beta.
any other commit or pull request should trigger a test run.
The lanes are working with all the code signing through match.
In order to avoid building twice I'm building through Gym and then Scan with skip_build: true and clean: false, as mentioned in #3353.
Although this does seem to help with the build time, due to the amount of cocoapods dependencies, it goes over the 50 minute limit in travis-ci.org. (Feel free to check the build logs)
How can this be improved in terms of running time? (Aside from fixing the slow compiling Swift functions mentioned in #3)
For reference, here's my Fastfile.
One way you can speed up your build phase is using prebuilt frameworks. It's like importing AVFoundation or any other Apple toolkit on your project.
Try to identify which dependency is slowing the running time down and move it to a prebuilt framework.
Carthage is a nice tool that allows you to use prebuilt frameworks and manage dependencies as well. You can cache Carthage builds on your CI. Check out this great blog post on how you can achieve caching.
I don't know of a way to re-use pre-built derived data for scan, gym and snapshot. Main reason for that is that those are builds for different architectures, with potentially different xcconfigs.
Basically, I would like details of all of the builds where:
it is the latest build
is has failed
I'm using TC 8.1, and looking at the API, you'd think that it would be as simple as:
guestAuth/app/rest/builds?locator=status:failure
but this seems to give you a list of any build that has ever failed. So if you have a configuration that failed 10 times last year, but hasn't failed since, you'll get the details of all 10 build instances that failed.
Even if I could just get the details of the latest build for each configuration, that would be a great start!
OK, so a possibly experimental, undocumented, but functional (at least for now) example:
app/rest/buildTypes?locator=paused:false&fields=buildType(id,name,projectId,builds($locator(status:failure,running:false,canceled:false,count:1),build(id,number,status,statusText)))
Is there a known solution for splitting build process cross the network machines?
Use case:
We are an average software development company. We own around 50 development workstations (Quad Core 2.66Ghz, 4 GB ram, 200 GB raid). No need to tell that at any single moment not every machine is loaded to the max.
There are 5 to 15 projects running simultaneously at any single moment. Obviously all of them are continuously build on server, than deployed to proper environment. Single project build is taking from 3 to 15 minutes.
The problem: Whenever we build 5 projects in a row the last project is going to be ready after around 25 - 50 minutes. Building in parallel does not solve the problem (build is only a part of the game, than you need to deploy, run tests etc.)
YES the correct solution is to add another build server, but "That involves buying new Expensive hardware, and we already spent a lot!". Yea, right(damn them)!
Anyway. What about splitting build among developers workstation? Lets say whenever we need to build project "A" we check 5 workstations and start build on all that are not overloaded. The build can be canceled by a developer if he really needs all the power of his machine as long as there is at least 1 machine that is still building. After build is finished deployment can be performed to a proper environment (hosted on some server, not on workstation :) ). The bigger the company the more this makes sense to me.
Anyone tried something like this? Are there any good practices? Any helpful software?
(90% of the projects are .net C#, platform - Windows)
You can also check our Parabuild at http://www.viewtier.com - it allows to designate a set of machines as a build farm. Works practically on any platform. It looks like that's what you are looking for.
We will be embarking on an Application developement project (.NET 3.5) for a large organization. As we started thinking about the upgrades we would be giving across the machines, we are looking at options like ClickOnce.
What we need is a push model, as long as the client machine is connected to the network, the server can send updates. I believe ClickOnce is a pull model(although by specifying minimum version we can kind of push). Also ClickOnce downloads complete files only, it cannot download the change (byte difference) among the files.
Can anyone point me to a better tool that can be used here. Also better strategies, if any, are welcome, we are in a very early stage of the project.
I don't have a definitive answer on better options, but I've used ClickOnce and can offer some advice.
There are several update options with ClickOnce (before starting, after starting, check every time, check every X Hours/Days/Weeks, etc). You can also throw those out and write code to check for updates. It's not a "push" from the server, but your client could poll for updates which would be the next best thing. Just remember, the application is going to have to restart after the update to see changes.
ClickOnce only downloads changed files. However, the progress dialog always shows the entire size of the application even if it's only downloading a single file. Everyone worries about that, but it's just a bug with the progress dialog.
Finally, I'm a big fan of keeping it simple. It's really easy to over-think these things and create a monstrosity that was never needed. We went through something similar at my company. We were so worried about users downloading unnecessary bytes, we broke our apps up into more, smaller assemblies. It turned into a nightmare; apps were harder to maintain and performed worse on the client. We finally undid it all and wasted weeks just to end up where we started.
I'm not saying you don't need the features you're asking for, I don't know your scenario. Just educate yourself first and know what you're getting yourself into.
We use clickonce at my company (about few hundred users for the app geographically dispersed). By specifying the minimum version we can make sure that every app installation gets updated after deployment automatically. You are right that clickonce downloads full files only but only files that have changed since previous version. If that is still a concern you can break your application into more smaller assemblies. I think you can also use netmodules but then Visual Studio has not built in support for that.
In general clickonce has worked good for us.
I am just in the process of implementing such a service on top of my distributed application platform. In essence I have developed a "push" model for corporates that follows these basic principles:
Software upgrades are "managed" from the server, NOT from the client, which is in line with the deployment of corporate software as opposed to user software (this is a very important point)
Software upgrades can be customised per client application on the server, i.e. the server can deploy unique configurations to every client if required
Software upgrades can be deployed to clients at different times, or all at the same time, or any combination of the two
The software upgrade version can be specified per client, i.e. different versions can be deployed to different clients as required
All software upgrades for all clients can be "managed" from a single server, i.e. the software upgrading "service" is consistent across any application, and all applications can utilise the software upgrading "service"
Clients can implement a software upgrade policy of automatic (application restarts as soon as the upgrade has been downloaded and available at the client), manual (application needs to be "sent" a custom "force upgrade"
message"), or on restart (application upgrades on shutdown if an upgrade has been downloaded and is available)
All auto-upgrading functionality is transparent to any running applications as this is all performed in autonomous background threads and all inter-process communication and file transfer is handled by my framework
In essence this now allows me (or will allow me when I have tidied a few things up and thoroughly tested the implementation) to manage the version of any application developed by me from a central server after it has been initially installed, without any client intervention.