I am new to TeamCity but have set up version 8.0.5. I am running it on a Windows 2008 R2 server and TeamCity is running as a service. I have configured the authentication to connect to the domain (which all works correctly)
I have created a project which connects to TFS to get the source code and compile it when the source code has changed.
The builds all work fine however, every time the build completes my windows account gets locked out (even if I did not trigger the build). This becomes increasingly annoying as other people are working on this project.
The TeamCity service does not use my account (it uses a service account) and the service account is used to get the code from TFS. When I view the project configurations, my account is not shown anywhere.
I have checked all of the configuration files and non of them are using my account credentials.
I have looked at the log files and I can't see anything there to indicate that my account is locked. However the TeamCity server is the server that is locking my account and it is happening when a build is completed.
As I'm still fairly new to TFS please can someone help me to establish why TeamCity could be locking out my account?
Thanks.
I resolved this by doing two things:
1) The TFS login account was previously using my login credentials, I removed these (to force it to use the service account).
This didn't actually resolve the issue.
2) Rebooting the TeamCity server seemed to resolve the problem (with the step above).
Related
I have this situation.
I have an already published react native app (both ios and android) (1.0.1).
So far, all the changes needed were made using OTA, so I had a jenkins pipeline which was trigger each time I was pushing anything to production branch. One of the main steps here is expo publish —release-channel prod-1, so I’m having the release channel called prod-1 here.
Now, I had to add some dependencies, therefore I am not allowed to use the OTA for these ones.
Here comes the questions:
What happens if I accidentally publish the current changes (which includes not accepted OTA changes) to the release channel prod-1?
Should I create a new release channel for these new changes called prod-2, then create the build for it, then submit it to stores for approval, then once approved released it in production?
If so, what will happen with the initial release called prod-1, in case I will need to do any changes on that one, should I simply publish again to prod-1 and an OTA will be performed for all the users using the old all version?
I was thinking about this flow, please confirm me if this is right or if you have any other ideas:
Create a new branch called production-v1 where I will merge what I have now on production, with a pipeline for automatically publishing the changes to prod-1 (OTA - if needed for the users using the old app).
Change the production pipeline so instead of using the release channel prod-1, it will use prod-2
Merge the main into production so it will trigger a new publish to prod-2 channel
Submit the build to the stores and once approved, I should be able to release the new version for the users using the old app.
Please let me know if I’m missing anything here, or if my approach is wrong. Thank you so much!
In Xcode 10.1 I have noticed when I restart my MacBook, every time I go back toward on my Xcode projects, I have to re-enter my GitHub credentials to use source control. I have the RSA saved to my keychain to enable automatic source control via SSH. But after updating to Xcode 10 or 10.1 (I'm not sure which) everytime I try to push to my remote repos, Xcode pops up asking for my credentials.
They seem to have tinkered with the usage of SSH in the github transactions.
Now XCode requires you to register your github user name and password under the "Accounts" preference pane. Once you have entered it and authenticated with github, XCode produces a dialog allowing you to decide how you wish to clone (ssh or or https) and in the case of ssh, which key you'd like to use.
Once that has been done, it appears to work as before. I guess the new method is "better" for people starting fresh, but breaks backward compatibility for those of us that have had it working well for a long time.
As we all know, backward compatibility is not high on the list at Apple.
Submitting a freshly build built with App Center used to work perfectly for us. But this week, it's not working at all. Every time we try to deploy,
through build > distribute > store, we have the same message appearing in the bottom :
Oh no! Build XX failed to distribute. Error: Release notes string or mandatory update boolean were successfully updated, but failed to distribute to some or all the destinations.
And we're stuck with that, we can still deploy the build, by downloading it, an doing it manually, but still, we kind of lost the need to use Appcenter.ms
If you are using AppCenter to automatic sign your builds, you might have lost your connection to the apple.developer portal.Go to settings and reestablish your connection. Maybe you also needs to agree to new terms with Apple on the apple.developer site.
Is there a way to activate pre-release builds (activating them for beta testing) without having to go to iTunes Connect's dashboard and manually activating them?
Every time I have a new build I have to go there, click on the app, click on pre-release and click the toggle. Being able to do it via terminal would fix my problem.
The old testflight didn't had this, i.e. builds were available right after you uploaded them.
Edit: I was expecting a solution that wouldn't require third party tools. However it seems like using fastlane is indeed the best solution. I may mark that answer correct, but I need to try that out first.
You can use the fantastic deliver tool. It supports both uploading a new build and activating it for pre-release testing (aka Apple TestFlight beta testing).
My company was using the old Testflight service for adhoc/beta builds running on a Jenkins server. When it finally stopped working, I looked into using the new Testflight service and was pretty bummed to see that (at least at the time) there was no way to set up automation with it, so we stopped using it. We have now switched over to using Crashlytics Beta which accomplishes pretty much 100% what the old Testflight did with full commandline (and hence automation) support. It also comes with some other nice features.
I am going to develop an iOS application for a customer of mine and I would like to make him constantly up-to-date during the development phase. In order to do so, I am looking for a tool which should allow me to share the current status of the application with my customer. The goal is to allow my customer to personally run the latest prototype of the application on a kind of simulator/emulator or on his own device (either iPhone or iPad).
Is that possible? Is there a tool (or a set of tools) which I can use to do so?
In case it is not possible, as far as I know the only alternative is to take screenshots or record videos, right? Just let me know if I am mistaken.
Thanks a lot!
The best way, I know of, is TestFlight.
This allows you to upload an AdHoc build of your app to there server and allow you customer to download it.
They even supply an SDK which can alert the user that a new version of the app is available also you add some debug functionality to the build (reading crash reports).
If you want to do, one elegant solution would be to use a continuous integration server to pull the code from your repository, make an adhoc build and place it somewhere publicly accessible.
The whole solution can take some time to set up and depends quite a lot on how is your development environment. In my company we are actually doing it with Jenkins and some shell scripting. If you Google a little bit about continuous integration of iOS projects with Jenkins you'll find some information.
Might not be the best way to do it, but I can't trust online repositories like TestFlight.
Not the easiest but rather secure workaround for this;
Get your customers device into your developer account
Create your new development provisioning profiles (consisting that device)
Distribute your application via Archive, and save it
Send your IPA to your customer