Design and Strategy: How to Deal with People Who Don’t "Get" Design
カスタム GitHub Actions 超入門
Design and Strategy: How to Deal with People Who Don’t "Get" Design
GitHub Actionsをローカルで実行する(nektos/act) - くらげになりたい。
GitHub Actionsを試すときに、いちいちコミットしないといけないのがめんどくさいので、 ローカルで確認できればな〜と思い、色々調べたときの備忘録。 Dockerを立ち上げてローカルで実行できるのがあった...(*´ω｀*) ・nektos/act: Run your GitHub Actions locally 🚀 使ったサンプルはこれ(*´ω｀*) # ./github/workflows/build.yml # ./github/workflows/test.yml name: Act Sample on: release: types: [created] jobs: build: runs-on: ubuntu-latest steps: - run: | echo "MY_ENV_VAR = ${{ env.MY_ENV_VAR }}" echo "MY_2ND_EN
GitHub ActionsのSelf-hosted RunnerをM1 Macで構築して、iOSのCI/CDが快適になった話
こんにちは！テラーノベルでiOS/Android/Webとフロントエンド周りを担当している @kazutoyoです！ テラーノベルのCI/CDは、Bitriseを利用していました。（旧プランでTeamsプラン移行前のもの） BitriseはモバイルにフォーカスされたCI/CDサービスで、かんたんにモバイルでのCI/CDパイプラインを構築できる素晴らしいサービスです。 ただし、テラーノベルのアプリ開発において、以下のような問題点がありました。 テラーノベルでのBitriseを利用する問題点1: マシンタイプが現在では古い こちらは旧プランを利用していたためGen２マシンを利用できなかったからなのですが、当時のEliteプランでもMac mini 2018年モデルでした。 Model Identifier: Macmini6,2 machdep.cpu.brand: 0 machdep.cpu
Notion APIとGitHub Actionsで毎日ページを自動生成する
どうも。えーたんです。 先日、Chrome拡張機能Choomameを公開し、GitHub Actionsを使ったChrome拡張機能の開発の記事も書きました。 その過程でGitHub Actions面白いなぁと思ったので、今回はNotion APIと組み合わせてみました。 本記事では、「毎日午前0時過ぎにNotionのデータベースに自動でページを作成させる手順」を紹介します。 デイリーページのタイトルの入力の手間が省けて少し楽になりました。 ワークフローを見てみよう ざっくりとしたワークフローの流れは以下です。 ワークフローのトリガーを設定する ワークフローの実行環境を整える Notion APIを実行する 先に実際に使っているワークフローの定義を載せます。 name: Notion Daily Generator on: schedule: - cron: "8 15 * * *" #
GitHubでhttpsのパスワード認証が廃止された。Please use a personal access token instead. - Qiita
GitHubでhttpsのパスワード認証が廃止された。Please use a personal access token instead.GitGitHub $ git push origin branch名 remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. fatal: unable to access 'https://github.com/名前/リ
入門 GitHub Actions - メドピア開発者ブログ
CTO室SREの @sinsoku です。 社内のGitHub ActionsのYAMLが複雑になってきたので、私が参考にしてる情報や注意点、イディオムなどをまとめておきます。 頻繁に参照するページ 新しい機能の説明が日本語ページに反映されていないため、基本的に英語ページを読むことを推奨。 ワークフロー構文 YAMLの基本構文の確認 コンテキストおよび式の構文 github オブジェクトの情報、関数の確認 ワークフローをトリガーするイベント 各イベントの GITHUB_SHA と GITHUB_REF が記載されている About GitHub-hosted runners インストールされているSoftwareのバージョンなどが記載されている GitHub REST API APIを使うときに参照する よく使うaction actions/checkout イベントによってはデフォルトブ
GitHub Actions でキャッシュを使った高速化 - 生産性向上ブログ
GitHub Actions Advent Calendar 2019 の 15 日目の記事です。 この記事では、GitHub Actions のキャッシュ機能について解説します。 目次 CI/CD とキャッシュ 簡単な例 (npm) 実験用リポジトリ作成 キャッシュ actions/cache Inputs と Outputs キーのマッチング順序 ビルド失敗時 キャッシュクリア 複数 OS で matrix ビルドするときのキャッシュ 言語ごとの例 アーティファクトとキャッシュの違い 制限事項 注意事項 まとめ CI/CD とキャッシュ CI/CD のビルドでは、リポジトリが依存するパッケージのダウンロードが原因でビルド時間が長くなってしまうことがよくあります。近年の CI/CD ではビルドごとに完全にクリーンな実行環境が用意され、前回のビルドでダウンロードしたファイルが持ち越されない
CDKとGithub ActionsによるCI/CDパイプライン | DevelopersIO
その昔、初めてのサーバーレスアプリケーション開発というブログを書きました。 このシリーズを通して出来上がるものは、AWSのコードシリーズを用いてAWSリソースをデプロイするためのパイプラインです。 時は流れ、2020年。同じような仕組みを作るのであればCDKとGithub Actions使いたいという思いに駆られたので、こんな感じのパイプラインを作成してみました。 今回作成したコードは以下のリポジトリにあげています。 cdk-github-actions 目次 CDKとGithub Actions 今回構築するアプリケーションの全体構成はこちら。 CDKで「クライアントからリクエストを受けて文字列を返却する」簡単なアプリケーションを作成します。 AWSにデプロイされるまでの流れは以下のようになります。 ローカルでCDKを使ったアプリケーションを作成 featureブランチを作成しmaste
[iOS] GitHub Actionsでfastlaneのmatchを使わずにAdHoc書き出しをしてからFirebase App Distributionにアップロードする | DevelopersIO
ファイルをbase64化する キーチェーンからp12ファイル形式で書き出したAdHoc用証明書と、プロビジョニングファイルはbase64化します。 コマンド例 openssl base64 -in cert.p12 -out cert_base64.txt base64化すれば、バイナリファイルがテキストファイルに変換できるのでsecrets内に登録することができます。 それをワークフロー内でbase64デコードしてバイナリファイルに戻してあげて使用します。 FIREBASE_TOKEN firebase login:ci を実行すると、こんな感じになります。 Waiting for authentication... ✔ Success! Use this token to login on a CI server: ここにトークンが書いてあります 2020/05/05追記 たまにトーク
GitHubを使うなら最低限知っておきたい、プルリクエストの送り方とレビュー、マージの基本
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回の記事「これでもう怖くない、Git／GitHubにおけるリモートリポジトリの作成、確認、変更、更新時の基本5コマンド」では「リモートリポジトリ」に対する基本操作を解説しました。 連載第10回目の本稿では「プルリクエスト」の基本機能や手順について解説します。 本稿で解説する作業は、前回の記事で作成したリポジトリをベースに進めていきます。リポジトリを作成する作業をまだ行っていない場合は、前回の記事を読みながら準備を進めてみてください。 プルリクエスト
Worry-free deploying to GitHub Pages using Jekyll
Kickster provides a basic Jekyll project setup packed with web best practises and useful optimization tools increasing your overall project quality. Kickster ships with automated and worry-free deployment scripts for GitHub Pages. Easy installation Kickster is built for fast prototyping so without the hassle of setting up your project from scratch and with an easy deploy mechanism you can focus on
Pull RequestごとにデプロイされるHerokuのReview Appsを仕事で使ってみたら超絶便利だった - 月曜日までに考えておきます
業務でGitHubを使っていて、developブランチにマージされたらステージング環境として使っているAWS上のサーバにデプロイされるようにしています。この時点で割と便利なんですが、マージ前にデザインや挙動を確認したいというケースも多いのでこの部分何とかしたいなぁと思っていました。 Review Appsとは 最近、HerokuはGitHubとの連携を強化しています。以前だったら GitHubの特定のブランチにPushされたら、Herokuにデプロイする ということを実現しようとすると、CircleCIなどのCIツールを使ってやるのが一般的でした。 そこが最近変わりました。Heroku側からGitHubと直接連携して、「GitHubの変更を受けてHerokuにデプロイ」がHeroku側の画面でポチポチやるだけで簡単に実現できるようになっています。 この時点でかなり便利なのですが、さらに「P
オレ流 Pull Request 作業フロー - 詩と創作・思索のひろば
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
GitHub を用いた開発フロー テンプレート - ペパボテックブログ
Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scope
Droneのオープンソース版を試してみました。 - Yosssi's blog
Droneのオープンソース版が公開されたということで、早速こちらを試してみました。 GitHub: https://github.com/drone/drone デモビデオ: https://docs.google.com/file/d/0By8deR1ROz8memUxV0lTSGZPQUk GitHubのREADME.mdによると、Droneは現在以下のバージョンのUbuntuで動作検証が実施されているとのことでしたので、今回は前述のデモビデオでの手順通り、DigitalOceanでDocker 0.8 Ubuntu 13.04 x64のDropletを作成・起動し、その上でDroneをインストールすることにしました。 Ubuntu Precise 12.04 (LTS) (64-bit) Ubuntu Raring 13.04 (64 bit) インストール $ wget http:
Github Pages について整理しておきます | そんなこと覚えてない
Git の練習を兼ねて Github できることといえばひとつとして Github Pages があります。 ウェブサイトを Git で管理して、Github へ プッシュすれば公開できるというものです。 使い方などは 公式のヘルプに書かれていますが自分が Github Pages を使おうとした時に知りたかったことを整理しておきます。 細かいことについてはあまり書きません。 Github Pages の特徴 Github Pages の種類 ユーザぺージ または グループページ プロジェクトページ Github Pages の構築方法 Jekyll 静的ファイル 独自ドメインの利用 Github Pages の特徴 公開リポジトリで作れば無料。容量制限もないと言ってよいです。 CGI,PHPなどで動的ページは生成できません。 代わりに Jekyll というアプリケーションを使い gith
middleman で構築したサイトを GitHub Pages で公開するまでの流れをまとめてみた - C++でゲームプログラミング
@supermomonga さんに教えてもらいながら middleman で構築したサイトを GitHub Pages で公開する事ができたので、その手順をまとめておきます。 デプロイとかめんどくさいと思っていたんですが、実際やってみたらめちゃくちゃ簡単でした。 [必要なもの] git github のアカウント gem middleman [middleman の生成] まずはローカルに middleman のプロジェクトを作成します。 middleman は gem からインストールする事ができます。 $ gem install middleman $ middleman version Middleman 3.2.2 これで、middleman のコマンドを使用できるようになったので次のようにして middleman でプロジェクトを生成します。 $ middleman init t
Node.jsの開発を超速化するGitHub連携 三種の神器 - teppeis blog
Node.js Advent Calendar 2013 - Adventar 9日目です。 あまりネタを用意する時間がなかったので、GitHubにNode.jsのリポジトリを置いたりnpmにパッケージを公開したりしたときに便利な定番サービスを3つ紹介します。 Travis CI Coveralls David タイトルは釣りですが、特にTravisとCoverallsは一度体験すると離れられないぐらいほんとにlife changing。コードをpushしたらブランチのビルド結果をプルリクに表示してくれたり、カバレッジ結果をコメントで書き込んでくれるので、それを見ながらコーディングを進めていけます。これが無料なのは意味不明なぐらいの神です*1。 サンプルコードはこちらのプロジェクトで見てください。 Github: https://github.com/teppeis/fixclosure
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - GitbookIO/nuts: :chestnut: Releases/downloads server with auto-updater and GitHub as a backend
