After some research, we understood that each controller in our UITabBarController is a UINavigationController. As result, rounded corners disappear after pushing any next controller.
The third try: We applied it for all main views. We created an extension of UIView and used it where it is required.
Setting up Continuous Delivery may be challenging. However, it is definitely worth the time and resource investment,
if you want to release often, maintain a high quality of released products and have full control over the complete process.
GoCD is built on a pipelines concept described in Continuous Delivery book.
Docker greatly fits into the concept, because it solves the problem of packaging applications with all required dependencies and configurations into a standardized container unit.
A common build pipeline will use a Dockerfile as an input, create an image and publish it to a Docker registry.
A common deploy pipeline will use a Docker registry image as an input and deploy it to a proper environment when it is updated.
GoCD in its basic setup is distributed and has a Server and one or more Agents, which are running actual Jobs and Tasks.
The Server can be customized by adding new plugins, or by setting up a backed-up pipeline configuration.
The Agents may have different resources to run different types of jobs, i.e. separate Agents to build java and node.js projects.
Same as for any other software deliverable, packaging GoCD Server and Agents into Docker containers simplifies their deployment and maintainability.
One of the challenges in this setup is running your existing Docker pipelines in an Agent, which is running in a Docker container.
So, in brief, you may find this article interesting, if you:
use GoCD to build Docker images;
run GoCD agents in a Docker.
The most important part of this setup is a Docker-in-Docker, which we use as a base image:
To run a GoCD agent in a Docker, we need to run several processes in one container. For this let’s use supervisor:
RUN apt-get -y install supervisor
ADD supervisord.conf /etc/supervisor/conf.d/supervisord.conf
The configuration file for the supervisor will contain a section per each process, including the supervisor itself:
Some additional tweaks may be required to run your GoCD agent properly. One of them is setting GO_SERVER in your agent configuration. Let’s assume that it is available as an environment variable with the same name:
How often do you face the situation where your colleagues, QA, business or marketing report issues in test builds, but they forget to mention a build number or application version? And when they ask you about it, you spend a lot of time explaining the build number and application version, and where it can be found? When you have one to two builds per month the issue is not very big, but when you have a lot of different builds per week, it becomes cumbersome.
-For instance at tispr we build on each commit and every week for internal testing, and weekly demo’s for business & marketing departments.
Let’s solve this issue, by creating a build number and app version with maximum visibility for users!
Our solution: On the application icon.
You must be thinking: A new icon for each new build?! Our answer is yes, why not.
Let’s look at the how:
Develop - it is type/name of build (if you have a different type of builds, for instance: Develop build, Business build, etc);
1.0.1 - application version;
1023 - build number
Add new “Run Script” in Xcode in “Build Phase”
Get build number and application version from info plist in script
where iPhonefirstname.lastname@example.org, iPhoneemail@example.com - the names of the current application icons
While the application builds the Xcode, the icons with the names AppIcon60x60@2x.png, AppIcon60x60@3x.png will be generated, if you use Images.xcassets.
So, these names are used as second parameters in our calls.
Octopress is an intuitive and simple blogging platform. The official documentation includes numerous examples and tutorials: http://octopress.org/docs. The purpose of this article is to give a quick reference to commands which cover some basic workflows.
## Pushing generated _deploy website
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/tispr/tispr.github.io'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Deploy does not work.
This may be related to the fact that the root directory of the source code and _deploy directory for generated HTML have different git repository branches set to source and master respectively. Thanks to StackOverflow a workaround was found:
git pull origin master
However, if you know a cleaner way to resolve this issue, please share in the comments.