[Jenkins] build for google map android Key

因為key store 綁電腦

所以developer 傳到git後，由jenkins下載，build 過後並無法顯示地圖，因為keystone不同

因此.... 要在jenkins  用ant 建立前

先換置掉  key store

script :

#!/bin/sh

# 步驟 (1/3)
DEVELOP_ANDROID_GOOGLE_API_KEY=XXXXXXXXX

# 步驟 (2/3)
# 處理google map android api key 的問題
# 先用 google帳號 到google console申請 api key
# builder的 default.keystore的
# sha1 = XXXXXXXXX

# 步驟 (3/3)
# 將申請到的 key 複製到下面的變數中
ANDROID_GOOGLE_API_KEY=XXXXXXXXX

# 換置動作
sed "s/$DEVELOP_ANDROID_GOOGLE_API_KEY/$ANDROID_GOOGLE_API_KEY/g" AndroidManifest.xml > AndroidManifest.xml.tmbuilderkey

mv AndroidManifest.xml AndroidManifest.xml.tmp
mv AndroidManifest.xml.tmbuilderkey AndroidManifest.xml

 

 

以上應該就能暫時解決問題

(不過同時多個開發者應該還是會  …orz)

[Jenkins] MacOS + Jenkins 系統更新

記錄一下 這次更新的流程

1.  app store 升級 MacOS
2.  app store 升級 Xcode
(此時重開 後的  Jenkins 會是由  主要帳號開啟  )
3. 在主要帳號的  command line 下  執行 launchctl unload  xxxxxxxxxx
4. 切換到 Jenkins 的帳號下
5. 在  command line 下  執行 launchctl load  xxxxxxxxxx  （不可以加入 sudo）
6. 開啟Jenkins網頁
7. 進入系統頁面下載新版本
8. 換置 .jar  (注意 own & grp)
9. 在  command line 下  執行 launchctl unload  xxxxxxxxxx
10. 在  command line 下  執行 launchctl load  xxxxxxxxxx

11. 記得要加入 ssh-add 相關的 id
12. 記得把jenkins 下的 cashlytics 打開

打完收工.....

Jenkins git change log for 中文

我的英文不好，

而且團隊合作上，需要在寄送版本的時候，通知PM or Tester 修改的相關內容

如果用   

${CHANGES_SINCE_LAST_SUCCESS, reverse=false, format="<li>Changes for Build #%n %c </li> ", showPaths=true, changesFormat="<li>[%a]<font color=#ff0099> %m </font></li>", pathFormat="<br>%p<br>"}

 

就可以很輕鬆的達到，在email 中通知變更內容，不過.....

他顯示中文是亂碼 orz

如果用ssh 到後台去看，可以發現如果使用  cat change.xml

依然可以看到正確的中文字，那麼問題應該就出現在讀取這個檔案轉到email上面的問題

• 產生自己的git change log， 印到email上送出

  我希望產生的log與 ${CHANGES_SINCE_LAST_SUCCESS…} 一樣
  是包含到上次成功build的間所以的log
   所以我需要知道上次成功建立的時間
   
  export LAST_SUCCESS_BUILD_TS=$(stat -f "%m" ../../jobs/${JOB_NAME}/lastSuccessful)
   
  知道時間之後，就要利用git log印出所以的commit message
   
  git log --pretty=format:'<li>%h was %an, %ar, message: <font color=#ff0099>%B</font></li>' --since="$LAST_SUCCESS_BUILD_TS" > GIT-Log-Report.txt
   
  最後會產生我想要的 GIT-Log-Report.txt   
   
  但是！
   
  這個是一個UTF8 的檔案
   
  如果直接用 Jenkins 的網頁觀看 也會看到亂碼，因為他的網頁是用UTF-16讀取的
  
   
  而Email 呢？ 我這裡是希望mail 送出Html的格式出來，而他是用 Big5 讀取的
   
  所以在使用  ${FILE, path="…..txt"}  之前
   
  要先用
   
  iconv -f UTF-8 -t BIG5 GIT-Log-Report.txt > GIT-Log-Report.BIG5.txt
   
  產生big5 的檔案，
   
  最後產生的script :
  
   
   
  然後再使用   ${FILE, path="GIT-Log-Report.BIG5.txt"}  
   
  將資料印到 Email 上 :
  
   
   

Jenkins + KIF

經過 前一篇的 Jenkins + Unit Test by iOS-sim

這個也算順利的在Jenkins上面跑起來的

先照著  KIF Readme 產生基本的建構環境

 接著做了一些修改

• 改用CocoaPod

  由於如果用 read me 所講的方式加入 KIF framework 的話

  會因為xcode workspace的設定檔案不會上傳到 git

  且 xcode workspace 會用 pod install 產生

  導致 Jenkins在build的時候 會找不到 libKIF.a  (-lKIF 會找不到)

   

  在 public的 pod search KIF 有一個非官方的來源

  但是因為他很機婆的把 下面這一行加進去了  orz

  s.xcconfig     = {  'GCC_PREPROCESSOR_DEFINITIONS' => '$(inherited) RUN_KIF_TESTS=1' }

  會導致 preprocessor defined 在 $(inherited)  就已經存在 RUN_KIF_TESTS=1

  這樣會發生什麼事情呢？  ==> 不論跑哪個 target都會讓他執行kif的劇本

  這不是我想要的呀 T_T

   

  所以呢.... 我就自己開了一個private 的 KIF spec  without  RUN_KIF_TESTS=1

  而另外如 readme中，手動的將 RUN_KIF_TESTS=1 加入 需要的target 中

   

• 借用跑Unit Test的經驗，在target後面加入script

  如果照readme中的script在 CI上跑，似乎會遇到權限的問題
   
  可能是因為產生的app的位置的關係吧？！
   
  後來我想，既然之前可以跑Unit Test，那就照同樣的處理方式吧！
   
   
  然後在 Jenkins 上 使用script
  
   
  並且在report Email 中加入
  
   
  最後會在Email中看到
  
   
  不過，現在即便是失敗了.... 信件還是Successful  XDDD
   

開始的設定還是有點麻煩

不過至少後期能自動化測試

 

接下來就是寫劇本了！

 

 

Jenkins setting

http://jdonee.iteye.com/blog/315440


雖然是舊？！  不過有些可能之後可以設定看看

 译自： http://www.javaworld.com/javaworld/jw-12-2008/jw-12-hudson-ci.html 

• Project name :我已经把这个项目命名为HeliosJMXTrunk ，但你也可以在这里修改它。
• Description : 这是一个自由项，主要用来说明你关于这次构建工作的描述。可不填。(帮助:这说明放在项目的首页，以便访问者可以知道这个工作的内容。您也可以在这里使用任何HTML标记。)
• Discard old builds : Hudson默认将保留过去的构建，除非你事先选中此框。(帮助:这里控制着您想要在Hudson所在的磁盘把构建记录存储的有效期(诸如控制台输出、编译构件等等)。Hudson为此提供了两个标准：1。时间驱动。在Hudson中您可以判断如果达到一定时限来删除一条记录(例如，七天前)。2。数量驱动。在Hudson中您可以确保它拥有N份构建。如果又有新的构建开始，最早的那份(记录)就将被删除。Hudson也可以让您建立的个别构建定义为'永远保持这个记录'，以便防止某些重要的构建被自动丢弃。)
• This build is parameterized : 如果选择此选项，Hudson将允许您提供一套任意的键值对参数，它们会被传递到构建过程里。配置的参数往往是构建运行环境中的一些环境变量。(帮助：当您使用了Hudson的各种自动化，有时要求在构建过程中提供一组用户的输入，使用“parameterize”就能够更方便构建。例如，您可能会设立一个按需测试，在那里用户可以提交一个二进制文件的压缩文件来进行测试。
  本节参数可以完全按照您构建的需要配置。参数是以名字区分的，所以您可以有多个参数，只要它们名称不同。
  关于此功能的更多资料请查看维基专题讨论 。)
• Enable project-based security : Hudson支持全面的安全方案，可以强制用户在通过身份验证后，再访问Hudson网页;它也可以通过控制用户的权限来管理用户的工作。在这个Hudson例子中我没有配置安全 [你可以参考我的另外两篇文章：Use Hudson之标准安全设置和使用matrix security对Hudson进行细粒度Job的安全控制，获取关于安全的详细配置]。
• Disable build : 如果这里被勾选，这项工作将不会执行构建，直到选项禁用为止。(帮助：有时候，你会想暂停某个构建中的项目。例如，也许您正准备一次大的迁移，而且你知道新版本会失败。或者您想每一个小时构建一次，但您却发现CVS服务器将在未来24小时内down机。当这个选项被设置后，关于这个项目就不会再有新的构建。这样一来，您就可以在不想改变外部依赖或者提交错误通知的情况下禁用构建过程。)
• Advanced options : 我没有使用这些选项，但是当此复选框被选中时，选项中就会暴露下面的接口：
  • Quiet period : 在这里您可以配置一个静态监控，当构建准备按某个计划运行时，实际上它就已经在开始执行了。
  • Use custom workspace : 默认情况下，Hudson将在${jboss-home}/.hudson/jobs/[项目名称](注:Linux环境 )下创建一个工作区 。此选项将允许您使用指定的地址替代(它)。
• Source code management : 在默认情况下是这三个选项：
  • Subversion
  • CVS
  • None
      这个None会误解我先前的主张 ：一个先决条件是要有一个源代码仓库。但我坚持认为，在大多数情况下，为Hudson选择某个仓库是绝对必要的。本文稍后，我将讨论如何安装Hudson插件。如果您安装了一个与SCM相关的插件，并重新启动Hudson，那么在这个清单上也将出现一些新的选择。本文，我使用 Subversion 。当您选择Subversion后，将展开一个配置表单。我会在下面的某一部分中单独描述这个配置(见“ Subversion的工作配置” ) 。
• Build after other projects are built : 此选项支持一条装配(流水作业)线——作业依赖: 一个作业依赖于另一个作业的输出的情况 —— 或者如以下情形：你只是想简单的把一些有关的工程构建编入一个组以便一起构建。当您一选择它，你将得到一个字段，输入其他工程的名字[多个项目名间用逗号分隔]后，这个构建应该就可以运行。
• Poll SCM : 这是CI 系统中常见的选项。当您选择此选项，您可以指定一个定时作业表达式来定义Hudson每隔多久检查一下您源代码仓库的变化。如果发现变化，就执行一次构建。例如，表达式中填写0,15,30,45 * * * *将使Hudson每隔15分钟就检查一次您源码仓库的变化。更多信息请查阅Quartz CronTrigger中关于这个定时作业语法的详细描述(新版Quartz支持从秒开始触发，所以请查阅下面的cron帮助，对此引起的误导表示歉意)。
• Build periodically : 此选项 (也是使用定时作业表达式)仅仅通知Hudson按指定的频率对项目进行构建，而不管SCM是否有变化。我这个作业就属于目标测试环境是按某种方式定期修订的而SCM却是静态的情况。如果您想在这个作业中运行一些测试用例的话，它可能就很有帮助。
• Add build step : 按一下这个按钮，添加了一项指令以执行构建脚本。您的指令可以是下列之一：
  • 执行 Shell
  • 执行 Windows 批处理
  • 使用Ant(这是我将要使用的选项，在下面我会做详细的说明)
  • 使用Maven
• Archive the artifacts : 当您选择此选项，就可以指定文件和目录的掩码(Ant风格的掩码，可以指定包含与排除)，当与掩码相匹配的构件在构建时将被添加到Hudson的构件仓库，它们会用作业（名）和构建序号来标识。所有以前构建过的构件可以选择性地丢弃，以节省您Hudson服务器上的磁盘空间。
• Record fingerprints of files to track usage : 当您选择此选项，它使用类似Ant方式的掩码，恁可以指示Hudson去生成构件的指纹码，确保您能够更容易地找到它们的位置，另外判断系统中的这些构件是否还在使用。
• Publish javadoc : 如果您的构建脚本能生成JavaDoc，此选项将指示Hudson发布这些内容，而且立即把它公布在当前工作的主页上。每一个成功构建的文档内容都可以保留，但在默认情况下只保留最新的。
• Publish JUnit test result report : 如果您的构建脚本执行了JUnit测试，此选项将指示Hudson处理XML测试文档并为每次连续构建产生一份可持续的报告，依据正在进行的测试汇总处理结果。其结果是当前工作主页的一份报告，作业中的单元测试会随着时间的推移按由老至新进行陈列。
• Aggregate downstream test results : 在某些情况下，作业中一组单元测试花费的时间大大长于实际构建它所花的时间。在这些情况下，你可以选择把构建和测试分为不同的作业，以便完成构建能相对迅速，一旦与这相关的一个或多个测试作业就执行完毕，构建也就成功完成了。 当您选择这个选项， Hudson就会把构建后作业的测试结果进行统计，并且能追溯到它们的明细。用以做为本次构建成功或失败的主要依据。
• Build other projects : 较之前面的选项，这个选项主要用来实现一个合乎逻辑的构建和测试过程，它会被分为两个或两个以上的物理工作，并且会按顺序执行。当此项被选择后，您将得到一个字段，可以在其中输入您想在当前作业中后执行的其它作业名[多项作业可用逗号分隔]。即使目前的作业得出结论说构建可能不稳定，您也可以选择这样做。(关于“作业的稳定性”请查阅“作业状态”章节以获取更多信息)
• E-mail notification : 当您选择此选项，您可以输入一个或多个电子邮件地址[多个可用空格分隔]，当Hudson完成了执行作业后，将会给它们发送通知。事件触发时将产生一份Email，包括构建失败、构建不稳定等。这儿有一个额外的选项，当由于用户的错误提交造成Hudson决定废弃此次构建，将会发送一份专门的邮件给这位SCM提交者，以便让他检查源代码。