この非常に小さなメモでは、Travis CIでアプリケーションを自動的に構築するプロセスの非常に小さな改善について説明します。 Androidアプリケーションを例として使用してこれを実行しましたが、もちろんこれは他の言語でも機能します。 タスクの設定は非常に簡単です-コミュニティメンバーは、GitHubのリポジトリにコミットするたびにアプリケーションに自動的に収集するように要求しました。 つまり、修正バージョンをアセンブルすることではなく、公式バージョンを待たずにすぐにインストールしてテストできる「毎日」のアセンブリについてです。 開発者としては、フィードバックの品質を大幅に向上させるため、このような関心のみを歓迎できます。 このプロセスの実装は非常に簡単で、GitHubとTravis CIの標準的な手段であり、魔法ではありません。 ですから、尊敬されているhabrozhitelをより深刻なトピックから書き、注意をそらす価値があるかどうかはまだ疑問です。 しかし、誰かが興味を持っている場合-私は猫をお願いします。
Android開発者として、GitHubのオープンソースプロジェクトを興味を持って監視し、成功を収めています。たとえば、 good-weather 、 AFWall + 、 Timber 、 Pedometer 、 AmazeFileManager 、 ConnectBot 、 K-9 Mailなどです。
これらすべてのリポジトリには共通する2つの点があります。各コミット後にTravis CIサーバーでアプリケーションを自動的にビルドするように構成され、この自動アセンブリの結果はTravis CIサーバーに残ります。つまり、収集されたビルドは単に削除されます。 はじめに述べたように、このコンパイルされたAPKファイルを利用してGitHubリポジトリに戻し、コミュニティメンバーがすぐにテストできるようにします。
Travis CIは、 コンパイルされたアプリケーションをGitHubにロードするための通常の方法を提供しますが、タグで動作するように設計されています。つまり、このアセンブリは、最初にGitHubリポジトリに新しいタグが作成されたときに開始され、次に、APKファイルのみをダウンロードできるようにしますGitHub Releasesセクション。ただし、リポジトリブランチは対象外です。 私の意見では、コミットごとにタグを作成することは常識に対する暴力であるため、この方法をタスクの精神と本質と矛盾するものとして拒否しました。
リポジトリのルートにあるTravis CIバッチファイル（.travis.yml）の構造は単純です：
language: android jdk: oraclejdk8 android: components: - platform-tools - tools - build-tools-25.0.2 - android-25 - extra-android-m2repository branches: only: - master install: - chmod +x ./gradlew script: ./gradlew clean assembleDebug notifications: email: on_success: change on_failure: always
このスクリプトは、gitリポジトリのルートにある仮想マシンで実行されます。これは、いわゆる 「デタッチされたHEAD」モード。つまり、リモート（つまり元の）GitHubリポジトリのmasterブランチに直接コミットすることはできません。
仮想ターゲットでこのスクリプトの実行ログを注意深く見ると、最初（この例では設定されていないスクリプトのgitセクション）で、Travisはこれを行います：
$ git clone --depth=50 --branch=master https://github.com/user/repo.git user/repo Cloning into 'user/repo'... $ cd user/repo $ git checkout -qf d7d29a59cef70bfce87dc4779e5cdc1e6356313a
ローカルブランチを「デタッチされたHEAD」モードにするのはgit checkout -qfです。
スクリプトセクションが機能し（私の例では./gradlew clean assembleDebug）、生成されたAPKファイルが./app/build/outputs/apkディレクトリに表示された後、after_successセクションが呼び出され、Gitを使用してこのファイルをコミットできます。 唯一の質問はどこですか？
いくつかのオプションがあります。
1）GitHub-Pagesを使用して、そこにAPKファイルを配置できます。つまり、gh-pagesブランチにコミットします。 このアプローチの主な欠点は、GitHub-Pagesが公式ストアからアプリケーションをダウンロードする必要があるエンドユーザー向けに設計されていることです。 コミュニティメンバーは、GitHub-Pagesではなく、リポジトリ自体を引き続き使用します。 したがって、このオプションは考慮しません。
2）GitHubリポジトリのmasterブランチ（たとえば、autobuildフォルダー）にコミットできます。 この場合、「detached HEAD」を非アクティブ化し、ファイルをコミットし、リモートリポジトリにログインしてプッシュする必要があります。
install: - git checkout master - chmod +x ./autobuild/push-apk.sh after_success: - ./autobuild/push-apk.sh
push-apk.shは次のようになります。
#!/bin/sh mv ./app/build/outputs/apk/snapshot.apk ./autobuild/ git config --global user.email "travis@travis-ci.org" git config --global user.name "Travis CI" git remote add origin-master https://${AUTOBUILD_TOKEN}@github.com/user/repo > /dev/null 2>&1 git add ./autobuild/snapshot.apk # We don't want to run a build for a this commit in order to avoid circular builds: # add [ci skip] to the git commit message git commit --message "Snapshot autobuild N.$TRAVIS_BUILD_NUMBER [ci skip]" git push origin-master
このオプションでは、GitHubリポジトリのmasterブランチでコミットするたびに、Travisは別のコミットを作成します。この場合、snapshot.apkファイルもmasterブランチに配置されます。 一方で、すべてが1か所にあると便利です。 一方、このファイルはローカルリポジトリで常に同期する必要もあり、開発者にとってはあまり便利ではありません。
3）すべての実験の投稿私は何よりも3番目のオプションが好きでした。 autobuildブランチはリポジトリに作成されますが、autobuildフォルダーを除くすべてのファイルとディレクトリはそこから削除されます。 このスタブは、マスターブランチと同期できないため、本格的なブランチではありません。 この場合、push-apk.shスクリプトは次のようになります。
#!/bin/sh # Checkout autobuild branch cd .. git clone https://github.com/user/repo.git --branch autobuild --single-branch repo_autobuild cd repo_autobuild # Copy newly created APK into the target directory mv ../repo/app/build/outputs/apk/snapshot.apk ./autobuild # Setup git for commit and push git config --global user.email "travis@travis-ci.org" git config --global user.name "Travis CI" git remote add origin-master https://${AUTOBUILD_TOKEN}@github.com/user/repo > /dev/null 2>&1 git add ./autobuild/snapshot.apk # We don't want to run a build for a this commit in order to avoid circular builds: # add [ci skip] to the git commit message git commit --message "Snapshot autobuild N.$TRAVIS_BUILD_NUMBER [ci skip]" git push origin-master
承認に関する最後の言葉。 環境変数AUTOBUILD_TOKENがそれを担当します。 この変数はセクションで設定されます
env: global: secure:
このセクションには、 個人アクセストークンページで生成する必要がある暗号化された秘密キーが含まれます。 次に、暗号化され、travisユーティリティを使用して.travis.ymlファイルに追加されます。
sudo gem install travis echo AUTOBUILD_TOKEN=<Personal access token> | travis encrypt --add -r user/repo
ここにそのような小さな改善があります。 興味がある場合は、 このリポジトリで作業バージョンを確認できます 。
継続的インテグレーションサーバーをウォームアップするすべての人に幸運を！