As announced in a blog post, we've shut down Sider Review service. If you have any inquiries, send an e-mail to support@sider.review Note: we'll close the e-mail address after February 10, 2023.
開発の規模が大きくなると、CI/CDに時間がかかるようになります。特にクラウド環境を用いた開発で、インフラ構成までコードで管理している場合、差分の確認やインフラサービスの更新で処理の待ち時間が発生します。 各機能やサービスに依存関係がないのであれば、処理を並列に実行することで、デプロイ等にかかる時間を短縮することが出来ます。デプロイ以外にもビルドやテストで時間がかかっているのであれば、機能単位などに分割して並列に実行させるのも良いと思います。 本記事ではAWS環境へのデプロイをGitHub Actionsで並列に実行させてみます。 ワークフローを実装 AWS環境にデプロイするワークフローを実装します。.github/workflowsにYAMLファイルを作成すると、プッシュ時にGitHub Actionsがワークフローを実行します。 以下のワークフローでは、指定したブランチにプッシュされた
普段使うサービスで、会社用のアカウントとプライベートのアカウントを分けると便利でセキュアですよね?うっかり間違って仕事のデータを大公開してしまうリスクも小さくなります ただ、日本国内では、アカウント分離はNGで、個人ごとに1つのアカウントに集約しないと規約違反であるという言説が広まっているようです。 認識共有用に頑張って書いた図。指摘歓迎ですそこでGitHub Supportに事実を確認したところ(英語)、規約違反ということはないという話でした。会社側で有償のオーガニゼーションを契約し、仕事用アカウントを所属させていれば、各自のプライベートアカウントは無料でOKです。 ロジックとしては、オーガニゼーションに所属させているアカウントは有償コーポレートアカウント(名称仮)なので、個人アカウントに対する無料アカウントの複数所持禁止条項は無関係となります。 該当条項 One person or l
tl;dr 失敗したステップの次に #スニペット を貼って workflow 発火します。おわり! 導入 みなさん、GitHub Actions 使っていますか。他 CI サービスと比べていくつか機能が間に合ってなくて移行できない、みたいな人たちも結構いるんじゃないかと思います。今回は Circle CI などではできていた SSH デバッグができるよさそうな Actions をみつけたので、その方法を紹介しようと思います。(技術的には昔からできたが、その決定的な方法がなかった。) 今回紹介する Actions は debugging-with-tmate です。以下ではそのおすすめの使い方を紹介します。 SSH デバッグのおすすめ手順 あるブランチでの、ある workflow のある step が失敗した そのブランチからデバッグ用のブランチを切る その step の次に debuggi
If you are developing Android apps, chances are you have confronted any sort of CI at some point in your career. If you thought Android fragmentation was a thing, the wide availability of CI systems will be familiar to you. GitHub Actions was released around November 2019, and since then it has proved itself to be reliable for a production environment (one of our requirements before committing to
Prologue GitHub アクションをちょっとずつ試しています。今回は GitHub Script をご紹介します。 GitHub Actions で標準で用意されている Functions は最低限過ぎてできることが少ないので、ちょっとした文字列の加工なんかは JavaScript が使えると便利です。 そこで利用できるのが GitHub Script です。 GitHub Script GitHub Script は、スクリプト処理として JavasScript を利用できます。 スクリプトの中では、下記が利用できます。 github インスタンス: 認証済みの octokit/core.js クライアントで、REST API のエンドポイントの利用と、pagination プラグインを利用できる contextオブジェクト: github.event などを含むコンテキスト c
この記事の内容を一言で commitのメッセージやPull Requestの内容がひと目で内容がわかるように、メッセージ冒頭に(GitHubが用意した)慣例的なキーワードをつけてください。 はじめに Githubをより便利に使えるツールを調べていたら、semantic-pull-requestsという機能を見つけた。 見てみるとなかなか便利だったため、どのようなものかを解説。 semantic-pull-requestって何? まず、これがどういう機能かについて。 簡単に言えば、commitのメッセージとPull Requestにおけるタイトルのつけ方をチェックしてくれるもの。 semantic-pull-requestsのページのスクリーンショットを使いながら、具体的にどんな感じか解説。 semantic-pull-requestの機能 付け直したほうが良いメッセージ、タイトル ▶ 黄色
今更ですが, ここ最近ちまちまとGitHub Actionsをしています. github.co.jp 個人的にはこういうのイジるの大好きなので, 新しいおもちゃをもらった子供のようにはしゃいでいます. 今回は, その中で知った知見などを雑多にご紹介します. Pull Requestでコケた時にRe-run jobsするとactions/cacheアクションが正常に動作しない GitHub Actionsには, 依存ファイル(例えばPerlならlocalとか, Node.jsならnode_modulesとか...)をキャッシュする, actions/cacheアクションが公式から提供されています. github.com このアクションを使っていて, かつon: pull_request のようにしてPull Requestをフックとしてワークフローを実行するとき, Re-run jobs(再
This action makes it easy to quickly write a script in your workflow that uses the GitHub API and the workflow run context. To use this action, provide an input named script that contains the body of an asynchronous function call. The following arguments will be provided: github A pre-authenticated octokit/rest.js client with pagination plugins context An object containing the context of the workf
GitHubで複数アカウントを作ってもいいのかを調べたところ、利用規約にこんな一文を見つけました。 One person or legal entity may not maintain more than one free account, and one machine user account that is used exclusively for performing automated tasks. (引用元:GitHub Terms of Service - User Documentation) 以下、拙訳。 いち個人や法人は1つより多くの無料アカウントを維持することはできません。また、自動化タスクの実行のみに使えるマシンユーザーアカウントも1つより多く持つことはできません。 ちょっと意外な気もしますが、個人がGitHubに無料アカウントを2アカウント以上作成すると厳密には
追記(2019/04/11): sonots氏がGitHubの方と相談しつつ設計した運用方法が公開されました。 全社的に会社用GitHubアカウントを廃止した件 - ZOZO Technologies TECH BLOG このガイドラインは今後のデファクトスタンダードになると思うのでtl;drを引用します。 個人で会社用と私用の2つの無料GitHubアカウントを持つことはGitHubの規約「非」準拠だった 会社用GitHubアカウントを廃止し私用GitHubアカウントを利用する規定に変更した セキュリティを担保するためGitHubのSSO機能を利用した GitHubの規約的には、おそらく「会社として会社用アカウントを pro版にする」「個人が身バレを防ぐために個人アカウントをpro版にして会社用アカウントを別途作る」などの運用も可能だとは思います。しかし、GitHubというサービス自体マル
ヒント: 個人用と業務用のリポジトリの両方を 1 つの個人アカウントのみで管理することをお勧めします。 警告: 組織とリポジトリのアクセス許可はアカウント間で移動できません。 削除するアカウントにアクセス許可が与えられている場合、組織の所有者またはリポジトリ管理者は、保持するアカウントを招待する必要があります。 GitHub 提供の noreply メール アドレスで作成されたコミットは、アカウント間で転送できません。 削除するアカウントで [Keep my email address private] オプションが使用された場合、削除するアカウントで作成されたコミットを、保持するアカウントに転送することはできません。 issue、pull request、ディスカッションは、新しいアカウントのものにはなりません。 Achievement をアカウント間で移動することはできません。 削除す
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました TweetDeckは開発者でもよく使っているTwitterクライアントになっています。多くの検索条件でツイートを閲覧したり、メンションやDM、タイムラインなどを切り替えることなく閲覧できる一覧性が便利です。 そんなTweetDeck風のUIをGitHubで実現してくれるのがDevHubです。 DevHubの使い方 メイン画面です。通知やアクティビティが閲覧できます。UIはまさにTweetDeck風です。 ユーザを指定してカラムに追加しました。 カラムのフィルタリング条件も指定できます。 ダークモードにも対応しています。 DevHubはGitHubをよく使っている人ほど便利でしょう。組織やリポジトリも指定できるので、仕事とプライベート両方で便利に使えるはずです。コメントにいち早く反応
GitHubでのリリース 前回、GitHubのRelease機能ついて書きましたが、これはリリースする側の自動化等についてでした。 git tagとGitHub ReleasesとCHANGELOG.mdの自動化について | Web Scratch 今度は、いわゆるライブラリユーザーだったりソフトウェアの利用者側から、 GitHubでリリースされるものをどう追っていくかについて書いていきたいと思います。 自分は、JSer.infoというJavaScriptの情報を見ていくサイトをやっているので、 JavaScriptのライブラリ等のリリース情報をどう追っていくかが中心になりますが、基本的にGitHubでリリースされてるならやり方は大きな違いはありません。 基本的には以下に色々書いていた内容のGitHubに関してをまとめた感じの記事となっています。 最近のJavaScript情報の探し方 ·
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く