We can see that in the Open Testing track, we have more then 1 builds under review. How is that possible. I have always seen that as soon as we uploaded a new build for review, earlier build under review will get super seeded.
Any idea?
-Ajay
Related
I'm in the following situation:
Both versions are in the "review and publish" state, definitely not out to the public yet
I want to release just one, the one that says 176(1.0.27)
How can I be sure that when i click review and publish only that one will be published, and the other one will be archived?
It seems that the 176(1.0.27) one is currently at 0%. You can increase staged rollout percentage to 25% or something. Once it has reached at 100% and wait a couple hours for it to take effect, I think the older version will be closed.
I am new to TeamCity. I am facing this issue. I have several tests running as part of a system test. Some of the tests after completing the run, shows result of an earlier day. Please see the image in the link below:
As you can see, it shows it was ran 3 days ago with a build number 164. But if I go to the log of that test, I can see the correct info
If I run the same test again, it shows the build is outdated
But even after completing this run, it shows the same result as in the first image.
Can someone please let me know what I have to do to fix this?
Maybe you are generating history builds, you can check this article in the official Team City documentation.
History builds
I have checked:
will open testing on Google Play overwrite the existing production app?
New Google play console - managed publishing for first app release
but they don't seem to answer my question.
I have enabled "Managed Publishing" and an existing Production release (build 6416) that's already reviewed by Google Play, and only needs to be published manually (because I had managed publishing turned on)
I created a Closed testing release (build 6425) and is currently undergoing review.
See screenshot.
Questions:
If I promote build 6425 from Closed testing track to Production track:
will it invalidate or remove build 6416 and reset back to the reviewing stage? And it means, I can no longer publish 6416 without waiting until 6425 is reviewed completely?
Or can I still publish build 6416 without waiting for 6425? And 6416 will only be replaced by 6425 after the review process of 6425 is finished?
I'm raising this because my team would like to have the option to release 6416 immediately without waiting for 6425 fixes ONLY if there's a need (and still within the deadline). But ideally, we'd like to release 6425 but we are hesitant because of the uncertainty of the review duration.
Thanks
UPDATE/SELF-ANSWER:
So in the end I tried this in a dummy app then in our final project, and was able to confirm that:
No, creating another release will not delete/invalidate an already reviewed-but-not-yet-published release.
Yes, after 6425 is reviewed, it will just override the not-yet-published 6416 release.
See screenshot of ongoing review and an already reviewed release but not yet published.
I'm somewhat new to maintaining separate production vs development builds of an app.
I want to have my current build deployed to heroku so i can easily get it in front of people for critique but I'd also like to run a local version as well so i can make changes and see them quickly on the fly.
With my app on heroku, everytime i make a change, I have to push to github then hit the deploy button. This takes a relatively long amount of time compared to just launching the app on localhost and just refreshing the browser page to see how the changes came out. This is fine if you have made a ton of changes and you know they all work as expected, but its horrible for trying incremental changes, as you can imagine.
I know this is sort of a newbie question, but how can I have the best of both worlds?
The only way to achieve something like this is with review apps.
Instead of doing a git push, you will need to enable GitHub Sync. You will be able to deploy either through the heroku dashboard, or automatically when a push is made to master.
Review apps will automatically create a test app and configure it, for each pull request.
Then, when you wish to do QA with other people, you just have to give them the address to that review app where the new code is deployed instead of the main one.
When creating an Xcode Bot in Xcode 6, it is linked to the current active branch in Xcode source control. There seems to be no supported way to change branches after creating the bot.
Xcode Service: Select Git Branch
I have set my bot to run "on commit". I find when I commit to that branch the bot immediately integrates the project. But when I commit to a different branch, the bot takes no action.
Ideally I would like a single Xcode Bot to look at all branches of the remote repository. When there is a new commit to any branch the bot and its tests should be run.
I do not want to create a new bot for each branch. Is there a solution?
Bug Report:
rdar://20154198
Developer Forum:
https://devforums.apple.com/thread/263490
There is also https://github.com/modcloth-labs/XBotBuilder developed by the same creators of the tool #jeremy-fox. It will create a bot per Pull Request, and re-run the bot for every addition in the PR.
It seems to be in early stages and without documentation but the code seems to be well organized so wouldn't be hard to get it to work or change it's behavior to do what you want.
For the moment we use a tool called Buildasaur (https://github.com/czechboy0/Buildasaur) to improve our CI-workflow. It's written in swift and helps to build/run/ delete bots automatically for one github repository, for example whenever a pullrequest was created or newer commits were pushed to the pullrequest. Actually it works fine on our Xcode Server 6.3. Unfortunately it works for just one repository at the same time. :-(
We also hope, that Apple will implement such features soon.
Apple response from the dev forum:
This isn't something Xcode Server supports. You might be able to craft a pre-integration trigger to switch branches in the working copy and invoke seperate xcodebuild invocations, but the results reported in the UI will only be for the Xcode Server builds (the build that XCS runs after your trigger executes).
https://devforums.apple.com/thread/263490
rdar://20154198
This is not currently possible with Xcode Bots (current versions are Xcode Server 4.0.3 & Xcode 6.2). A Bot will only track the specific branch form which it was created.
This was possible in the past on Xcode Server 3 and Xcode 5 using https://github.com/modcloth-labs/github-xcode-bot-builder but this project hasn't been updated to work with the latest version of Xcode Server and Xcode.
I'm also really hoping Apple introduces this feature soon, it would be great to be able to have a single bot monitoring a repo for new Pull Requests and when found run an integration against that PR. For now though, it's just not possible.
Update 3/19/2015:
As #Gus reports in another answer, there is a new Mac OS X based project that can help with ad hoc bot creation for feature branches/PR's called XBotBuilder - https://github.com/modcloth-labs/XBotBuilder. It should be worth noting that currently, this project only works with one github repo. So, if you have more than one repo you'd like to monitor for PR's, this is still not currently possible unless you have multiple machines each running a different instance of XBotBuilder and targeting a different repo.