CircleCI のパスフィルタリングと設定ファイル分割を組み合わせる実験

三話目の今日は、パスフィルタリングと組み合わせてみるぞー!

第一話:設定ファイル分割の紹介

bufferings.hatenablog.com

第二話:モノレポ用の実験

bufferings.hatenablog.com

前回の最後に

こんなことを言ったので、今日ぼけーっと考えてた

ブランチごとに合成方法を変えたりできるかなぁ?か、変更があったサービスのジョブだけ実行したりできないかなぁ?のどっちかを考えてみたいな。できるかどうか分かんないけど!

ブランチは別にいっか

でも、ブランチは別に考えなくていいなと思った。main だったらこの設定ファイルだけを合成に使う、feature ブランチだったらこの設定ファイル、みたいにブランチごとに合成する設定ファイルを変えるのは、あんまりユースケースが思いつかない

あるかもって思ったのは「ブランチごとの設定を別ファイルに分けてわかりやすく管理したい」かな。でも、それは特に難しいことを考えずに今の機能で足りそう。 main.yml とか feature.yml とかにそれぞれのブランチ用のワークフローを書いて、それをマージしてしまえば良さそうなので

変更があったサービスのジョブだけ実行

ということで、今日はこちらを実験してみようと思う

どういうものかというと、昨日試してみたモノレポ的なリポジトリで「変更が入ったサービスのビルドだけを実行したい!」っての

実は、これ自体は既に公式の Orb がある。path-filtering という Orb

この Orb もダイナミックコンフィグを使ってるから、組み合わせて動くかなぁ?ってのを試してみるだけになるかな

path-filtering Orb

まずは path-filtering Orb のことを簡単に紹介

僕が読んだ記事たち↓。どれも分かりやすいー!

仕組み

セットアップ用のジョブに、こんな風に書くと

version: 2.1

setup: true

orbs:
  path-filtering: circleci/path-filtering@0.1.3

workflows:
  setup-workflow:
    jobs:
      - path-filtering/filter:
          config-path: .circleci/continue-config.yml
          mapping: |
            src/.* build-code true
            doc/.* build-docs true
  1. mapping の定義に従って、正規表現に一致したファイルに変更が入った場合に、指定してあるパラメータに指定した値が設定される(正規表現 パラメータ名 パラメータ値 になってる)
  2. config-path に指定したファイルを設定ファイルとして、ダイナミックコンフィグの機能を使ってパイプラインが実行される。このときに(1)のパラメータが渡される

なので、上の例だと .circleci/continue-config.yml の中で build-codebuild-docs というパラメータが true かどうかをジョブの実行条件に加えることで「変更が入ったサービスのビルドだけを実行したい!」が実現できる

どこからの差分?

ところで「変更が入った」ってどこからの差分だろう?と思って Orb のコードを見てみたらデフォルトでは main からの差分だった。なるほど。・・・ん?

「え、じゃあ main 自体のビルドの場合はどうなるの?」って思うよね。で、見てみたら main の場合は一個前のコミットとの差分を見てた。へー

だから、気をつけておきたいのは、main でビルドに失敗して、もういっかい何か変更を加えてコミットしてプッシュしたときとかに、一個前のコミットとの差分を元に起動されて大丈夫かどうかってところかなぁ

そういうときのために、手動でトリガーできるパイプラインパラメーターを用意しておくか、まぁ、ジョブを走らせたいディレクトリのファイルをわざと触るかしたら良さそうかな

組み合わせる

で、本題の、設定ファイル分割と、この path-filtering を同時に動かせるかどうか、ってやつ

ここまでの情報をふまえると頭の中では、大丈夫そう。先に設定ファイル合成のジョブを走らせておいてから、そこで合成したファイル名を path-filtering/filter ジョブの config-path に指定してあげれば動くはず

ということで、本当に動くかどうかやってみよー!

実験

今日のコード:

github.com

こんな構成にしてみた

path-filtering は mapping にマッチしなかったケースを書いておいてあげないといけないので Tsuji さんの記事を参考に noop.yml を書いたのと

version: 2.1

jobs:
  noop:
    docker:
      - image: cimg/base:stable
    steps:
      - run:
          name: "No operation"
          command: echo "No operation"

workflows:
  noop:
    when:
      and:
        - not: << pipeline.parameters.build-service1 >>
        - not: << pipeline.parameters.build-service2 >>
    jobs:
      - noop

パラメータの定義が必要なのでそれを parameters.yml に書いておいた

version: 2.1

parameters:
  build-service1:
    type: boolean
    default: false
  build-service2:
    type: boolean
    default: false

別ファイルで既に書いてあるから、version: 2.1 はつけなくてもいいんだけど、なんとなく

それに合わせて、config.yml 以外の YAML ファイルも読み込めるように find の正規表現を昨日のやつから少し変えておいた

command: |
  find . -type f -regex '.*/\.circleci/.*\.yml' -not -regex '\./\.circleci/config\.yml' \
  | tee .circleci/config-list.txt

今日のは余裕やろー!

と思って

  • generate-config -> path-filtering/filter

なセットアップワークフローをこんな風に書いたら

workflows:
  setup-workflow:
    jobs:
      - generate-config
      - path-filtering/filter:
          config-path: .circleci/generated_config.yml
          mapping: |
            service1/.* build-service1 true
            service2/.* build-service2 true
          requires:
            - generate-config

怒られた!

jq: error: Could not open file .circleci/generated_config.yml: No such file or directory

・・・はっ!そうか。ジョブ間でファイルを渡してあげなきゃか

ワークスペースを使う

ジョブ間のファイルのやりとりにはワークスペースを使えばいいので

generate-config ジョブの最後にこうやって

      - persist_to_workspace:
          root: .
          paths:
            - .circleci/generated_config.yml

で、どうやって、このワークスペースpath-filtering/filter にアタッチしようかなぁって思って見てみたら

path-filtering/filterworkspace_path ってパラメータがあった。Orb のソースを見た感じ、これを使えばちょうどいい場所でアタッチしてくれそう

なので、こういう感じになった(workspace_path: . が足した部分)

workflows:
  setup-workflow:
    jobs:
      - generate-config
      - path-filtering/filter:
          workspace_path: .
          config-path: .circleci/generated_config.yml
          mapping: |
            service1/.* build-service1 true
            service2/.* build-service2 true
          requires:
            - generate-config

動作確認

じゃ、動作確認していこー!

service1 にも service2 にも変更が入らなかった場合 -> noop ワークフローが実行された

service1 にだけ変更が入った場合 -> service1 用のワークフローだけが実行された

service2 にだけ変更が入った場合 -> service2 用のワークフローだけが実行された

service1 にも service2 にも変更が入った場合 -> 両方のワークフローが実行された

やったー!

次は

アンカーの動作確認をしておきたい。これまで特に YAML の要素の順番を気にしてこなかったけど、YAML のアンカーって先に定義がでてきてないと怒られるんじゃないかなぁ?って思うのでその確認をしておきたい

で、それが終わったら、このファイル分割の機能を Orb 化しようかな

楽しい3連休だったー!

今日も今日とて宣伝

梅田まで来れる方はぜひお申し込みくださいませー!

bufferings.hatenablog.com

CircleCI の設定ファイル分割をモノレポ的な構成で実験

昨日(というか今朝)書いたやつの続きー!

bufferings.hatenablog.com

昨日の記事を書きながらこんなことを考えてたので、今日はモノレポっぽいものを思い浮かべながら試してみた↓

ダイナミックコンフィグの有効化

と、その前に、昨日書き忘れてたやつを最初に

CircleCI のダイナミックコンフィグはデフォルトでは無効になっているので、そのままだとこういうエラーになる

Use of setup workflows must be enabled in project settings (Project settings > Advanced -> Dynamic config using setup workflows)

なので、プロジェクトの設定から有効化してあげる必要がある。

Project Settings > Advanced の一番下にあるトグルをオンにする:

これでダイナミックコンフィグが使える

モノレポのサービスごとに設定ファイルを用意

コードはここ → GitHub - bufferings/circleci-config-separation2

昨日は .circleci/config の中に YAML ファイルを置いてそれを合成したけど

今日は、複数のサービスをひとつのリポジトリに入れて、それぞれのサービスがそれぞれの config.yml を持っていると想定して作ってみた:

せっかくだから、共通の定義を置くのも想定してみようと思って、common も作った

気をつけること

設定ファイルで、気をつけないといけないことがいっこある

最終的にはひとつの YAML ファイルにまとめてしまうので、各サービスのジョブやワークフローの名前がかぶらないようにしないといけないのだ

だから今回は「サービス名 + -」を各ジョブ名とワークフロー名のプレフィックスとしてつけておいた。例えば service1 の場合はこうしておいた:

version: 2.1

jobs:
  service1-say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: "Say hello"
          command: "echo Hello, World!1"

workflows:
  service1-say-hello-workflow:
    jobs:
      - common-say-hello
      - service1-say-hello

設定ファイルを生成

じゃ、あとは設定ファイルを生成すればいい

昨日はこうしてた↓。.circleci/configs の中の .yml を集めてきて CUE に渡して合成してる

- run:
    name: Generate config
    command: |
      cd .circleci/configs
      find . -type f -name "*.yml" | awk '{printf "\"%s\" ", $0}' \
      | xargs -0 -I {} sh -c 'cue export {} --out yaml' | tee ../generated_config.yml

今回はこれを2つのステップに分割してみた

- run:
    name: Generate config list
    command: |
      find . -type f -regex '.*/\.circleci/config\.yml' -not -regex '\./\.circleci/config\.yml' \
      | tee .circleci/config-list.txt
- run:
    name: Generate config
    command: |
      cat .circleci/config-list.txt \
      | awk '{printf "\"%s\" ", $0}' \
      | xargs -0 -I {} sh -c 'cue export {} --out yaml' \
      | tee .circleci/generated_config.yml

最初のステップで対象のファイルリストを生成してから、次のステップでそのリストのファイルを読み込んで合成するようにした

今回はファイルリストの生成部分が前回と異なるので、各サービスの config.yml を集めてくる(でも、メインの config.yml は含まない)ようにした

生成されるファイルをローカルで確認

こんな風にしたらローカルマシンで確認できる

❯ find . -type f -regex '.*/\.circleci/config\.yml' -not -regex '\./\.circleci/config\.yml' \
| awk '{printf "\"%s\" ", $0}' \
| xargs -0 -I {} sh -c 'cue export {} --out yaml'
version: 2.1
jobs:
  common-say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello
          command: echo Hello, World! common
  service3-say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello
          command: echo Hello, World!3
  service2-say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello
          command: echo Hello, World!2
  service1-say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello
          command: echo Hello, World!1
workflows:
  service3-say-hello-workflow:
    jobs:
      - common-say-hello
      - service3-say-hello
  service2-say-hello-workflow:
    jobs:
      - common-say-hello
      - service2-say-hello
  service1-say-hello-workflow:
    jobs:
      - common-say-hello
      - service1-say-hello

うん。よさそう

実行すると

こうなった。やったーヽ(=´▽`=)ノ

事前に用意しておいても

ところで、設定ファイルの生成を2つのステップに分割したのは、マージしたい config.yml のリストを事前に書いておいてもいいかもなぁって思ったから

config.yml の数ってそんなに頻繁に変わらないと思うので、リストを .circleci/config-list.txt として書いておいてコミットに含めておいてもいいのかなって

そういう気も少ししてる。また今度もう少し考えてみる

次は

ブランチごとに合成方法を変えたりできるかなぁ?か、変更があったサービスのジョブだけ実行したりできないかなぁ?のどっちかを考えてみたいな。できるかどうか分かんないけど!

恒例の宣伝

興味あったら今日試してみたやつのお話を雑談したりできると思うので、ぜひ遊びにきてー!

bufferings.hatenablog.com

CircleCI の設定ファイルを分割して CUE で合成してみたら割と簡単で便利そう

ぼーっと CUE のドキュメントを読みながら

CUE という設定用の言語・・・と呼んで良いのかな?のドキュメントを読みながら

「これ、いろんな機能があるけど、それは置いといて、YAML の合成が簡単にできるのでは?・・・とすると、CircleCI の設定を簡単に分割できて面白いかもなぁ」

と思ったので試してみた。わりとアリかもしれない

今回のサンプルコードはここ:

github.com

どういう感じ?

こんな感じに適当に分割した設定を

❯ tree .circleci/configs 
.circleci/configs
├── header.yml
├── job1.yml
├── sample
│   ├── job2.yml
│   └── mixed\ sample.yml
├── workflow1.yml
└── workflow2.yml

1 directory, 6 files

CircleCI の実行時に合成して、ワークフローを動かした。結果はこんな感じ:

ディレクトリ構造とかには特に制限はない

内容は適当にこんな感じで、バージョン部分だけ分けてみたり

header.yml

version: 2.1

ジョブを複数のファイルに分けて定義してみたり

job1.yml

jobs:
  say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: "Say hello"
          command: "echo Hello, World!"

job2.yml

jobs:
  say-hello2:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: "Say hello2"
          command: "echo Hello, World2!"

ワークフローを複数のファイルに分けてみたり

workflow1.yml

workflows:
  say-hello-workflow:
    jobs:
      - say-hello

workflow2.yml

workflows:
  say-hello-workflow2:
    jobs:
      - say-hello
      - say-hello2:
          requires:
            - say-hello

ジョブとワークフローを混ぜて定義したファイルを作ってみたりして

mixed sample.yml

jobs:
  say-hello3:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: "Say hello3"
          command: "echo Hello, World3!"

workflows:
  say-hello-workflow3:
    jobs:
      - say-hello
      - say-hello2:
          requires:
            - say-hello
      - say-hello3:
          requires:
            - say-hello

ファイル名にスペース入れてみたり、サブフォルダの中に入れてみたりした

それを CUE で合成

この分割したファイルを CUE で合成するんだけど、なかなか強力。たとえば job1.ymljob2.yml を合成するとこんな感じになる

❯ cue export job1.yml sample/job2.yml --out yaml
jobs:
  say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello
          command: echo Hello, World!
  say-hello2:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello2
          command: echo Hello, World2!

内部的には、YAML から CUE に変換して、合成して、それを YAML で出力してるのかな。CUE の合成のルールが面白いからぜひドキュメント読んでみてー

CUE には型があって、一度決定した値は上書きできないので、同じ名前のジョブやワークフローを定義してたらエラーになるのも便利そう

実際の合成部分

config ディレクトリの中の YAML ファイルを cue export に渡して生成

cd .circleci/configs
find . -type f -name "*.yml" | awk '{printf "\"%s\" ", $0}' \
| xargs -0 -I {} sh -c 'cue export {} --out yaml' | tee ../generated_config.yml

こういうの得意じゃないから、ここにいちばん時間がかかった気がするw

もっといい書き方あったら教えて欲しいです

CircleCI のダイナミックコンフィグ

さて、その合成をするのに、CircleCI のダイナミックコンフィグ機能を使う

ダイナミックコンフィグは、設定ファイルを動的に生成する機能

config.yml はこう

version: 2.1

# ダイナミックコンフィグのセットアップ用の設定だよーってしるし
setup: true

# 「生成した設定ファイルを使って起動してー!」てのに、この Orb を使う
orbs:
  continuation: circleci/continuation@0.3.1

jobs:
  build:
    docker:
      # CUE を入れたイメージを作っといた
      - image: bufferings/cimg-cue
    steps:
      - checkout
      # さっき書いたやつ
      - run:
          name: Generate config
          command: |
            cd .circleci/configs
            find . -type f -name "*.yml" | awk '{printf "\"%s\" ", $0}' \
            | xargs -0 -I {} sh -c 'cue export {} --out yaml' | tee ../generated_config.yml
      # 生成した設定ファイルを使ってパイプラインを実行
      - continuation/continue:
          configuration_path: .circleci/generated_config.yml

これが実行されると、分割された YAML を CUE で合成して generated_config.yml が生成されて、その生成された設定ファイルで CircleCI のパイプラインが実行される

ちなみに generated_config.yml の内容はこう

version: 2.1
jobs:
  say-hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello
          command: echo Hello, World!
  say-hello2:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello2
          command: echo Hello, World2!
  say-hello3:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Say hello3
          command: echo Hello, World3!
workflows:
  say-hello-workflow:
    jobs:
      - say-hello
  say-hello-workflow2:
    jobs:
      - say-hello
      - say-hello2:
          requires:
            - say-hello
  say-hello-workflow3:
    jobs:
      - say-hello
      - say-hello2:
          requires:
            - say-hello
      - say-hello3:
          requires:
            - say-hello

CUE かしこいー

ということで

CircleCI の設定ファイルを分割して CUE で合成してみたら割と簡単で便利そうでしたー

設定ファイルが大きくなってメンテしづらいなぁってときに便利かもしれない!

試してみたい人は、config.yml をそのままコピーして、configs ディレクトリの中に、分割した設定ファイルを入れたら遊べると思うー!

参考にさせてもらいました!

なるほどー!と思いながら読ませてもらいました!ありがとうございましたー!

bufferings/cimg-cue

cimg/gocue を足しただけの Docker Image:

https://github.com/bufferings/cimg-cue/blob/main/Dockerfile

今日も宣伝

ぜひ遊びにきてくださいー!

bufferings.hatenablog.com

意識低めの成長

とても雑記

個人の成長は必須かなぁ?

よーはつのツイートを見て、古川さんのスライドを見て、「グループや会社は成長して欲しいなぁって思うけど、個人の成長はどうなんだろう?僕は『今、自分が持ってるチカラで会社の成長を支える』ぐらいがいいなぁ」みたいなことをぼやーっと考えた

意識低い

最近の自分は「成長しなきゃ!」「そして自分の成長で会社の成長を支えなきゃ!」みたいなのはあんまりなくて、意識は低い方かなぁと思う。「それはそれ、これはこれ」な気持ち

単純に、新しいことを学ぶのは楽しいし、昨日できなかったことが今日できるようになると嬉しい。そして、成長したら会社の役に立てることが増えるだろうなぁ。それくらい

会社に対しては「今の自分が持っているチカラによって会社の成長を支えたい」って気持ち。ただ、成長したら支えることのできる幅が広がる(そして給料が上がる)からそれはそれで良い。でも、成長は自分の中で必須ではない

成長って何だっけ?

あれ?ちょっと待ってよ?「成長」って何だっけ・・・

「成長」ってのがよく分からなくなってきたんだけど、新しい知識を身に付けたり、これまでより上手に何かができるようになったら成長?それで考えたら、この1年くらいでこういうことができるようになった

  • React でフロントエンドアプリケーションの開発ができるようになった
  • Clojure でサーバーサイドアプリケーションの開発ができるようになった
  • AWSKubernetes、Terraform に慣れてきた
  • CircleCI のことを勉強した
  • 色んな外部サービスの使い方に慣れてきた: Rollbar, Honeycomb, DataDog etc...
  • あんまり形にとらわれずに、素早く開発を進めるのが少し上手になってきた
  • 英語で会話するのに少し慣れてきた

んで、次はこの辺やりたいなぁって思ってる↓

  • Golang でサーバーサイドアプリケーションの開発ができるようになりたい
  • CircleCI のことをもっと勉強したい
  • 英語の語彙を増やしたい(休憩中)

これ、ふつうに仕事したりプライベートで遊んだりしながら身に付けてきたけど、成長か・・・そうだな、成長かぁ

成長は必須ではないと思いつつ、面白いなぁって勝手に成長してるってことかぁ

なんかちょっと違うなって思う成長

じゃあ、僕が「なんかちょっと違うなって思う成長」って何だろう?

それは「今持っていないスキルを勘定に入れて立てた計画のための成長」かな。「しなきゃいけない成長」があんまり好きじゃない。そういう場合って「成長が足りない!」ってなりがち。それよりも「おー!成長したぶんプラスじゃん!」が好き

今持っているスキルで常に褒められてたいのだ

宣伝

きてー!

bufferings.hatenablog.com

7/27 (水) に CircleCI オフラインミートアップ大阪やりまーす!遊びにきてー!

7/27 (水) の19時から WeWork LINKS UMEDA でやります!ヨドバシに行ったときに、前を通り過ぎたことしかないから、なかどうなってるのか、楽しみ。

CircleCI を使ってくれてるみなさんのお話を聞きたいので、ぜひ遊びにきてください。ビールのんだりのまなかったりしながら、みんなとお話したいですー。個人的には、どんな機能があったらみんなが嬉しいのか興味あります!

使ったことがないけど興味ある方にとっては、実際に使ってる方の話が聞けたり、中の人に相談できたりする場になると思います!ぜひー!

僕は、そうだなぁ、ふだんどんな感じで開発してるかとかなら、お話しできるかもしれない!あと、最近プランターで育ててるバジルの話とか!

circleci.connpass.com

って、うぉー!

ぼっちだー!だれかー!このままだとひとりごと言いながら飲み続けることになってしまうー!遊びにきてー!今日の記事はビックリマークが多いー!

ちなみに

福岡でも 7/28 (木) にあるそうですー!福岡の方ぜひー!

circleci.connpass.com

JetBrains IDE を一部使いつつ最近の自分の Git 周りの操作。3ステップ。

最近の自分が、どんな風に Git を使ってるか、メモを残しておこうかなと思ったので書くことにした。こういうの、以前に書いたかもしれない?と思ったらあった↓

bufferings.hatenablog.com

この頃はコマンドだけ使って操作してたけど、最近は JetBrains の IDE から一部操作するようになったのだ!便利!

エイリアス

話に入る前に、使ってるエイリアスを紹介。自分で考えるの苦手なのでこの設定ファイルをコピーしてきて使ってる↓

https://github.com/timcharper/git_osx_installer/blob/master/assets/etc/gitconfig.default#L23-L41

とは言いつつ、最近おもに使ってるのは git l くらいかな

l = log --graph --all --pretty=format:'%C(yellow)%h%C(cyan)%d%Creset %s %C(white)- %an, %ar%Creset'

ステップ1:クローン→ブランチ作成

クローンからブランチ作成周りは、相変わらずコマンドでやってる。以前と違うのは checkout じゃなくて switch を使うようになったことかな。せっかくなので前回の記事と同じリポジトリを使ってみる

クローンしてきたらグラフを git l で表示

ラッキングブランチが苦手なので、一旦、ターゲットのリモートブランチに git switch -d で移動してしまう

❯ git switch -d origin/ch03
HEAD is now at 741d278 fix encoding

そうすると↓こんな感じで、ブランチを作らずに HEAD がそのコミットに移動するので

そこでブランチを git switch -c で作ってる

❯ git switch -c BUF-001/for-blog
Switched to a new branch 'BUF-001/for-blog'

以前は work みたいに適当な名前でローカルブランチを作ってたけど、今は JetBrains IDE を利用するようになったこともあって、リモートで使う予定の チケット番号/概要 みたいなブランチ名をローカルでも使うことが多い

そんな感じで git switch -c すると、HEADBUF-001/for-blog になる

ステップ2:変更→コミット

コミット周りは JetBrains の IDE から操作してる。IDEA と WebStorm を使ってる

Commit タブから、変更一覧を見ることができるので、そこで差分をチェックして

コミットに含めたいファイルにチェックを入れて(複数可)、コミットメッセージを書いて、Commit ボタンを押す

前回のコミットにマージしてしまいたい場合は、Amend のチェックボックスにチェックをいれて Commit ボタンを押すと Amend になる

ステップ3:プッシュ

IDE からもできるんだけど、なんとなくプッシュ周りはコマンドラインでやってる。git l で確認して

git push する

❯ git push origin BUF-001/for-blog
Enumerating objects: 13, done.

以上!

コミット周りを JetBrains の IDE でやるようになったので、だいぶシンプルになったかな。commit add status diff を使う機会が減った

まぁ IDE を使ってないものは、今まで通りコマンドで操作してるんだけども

もうちょっと JetBrains IDE の Git 周りを有効活用しても良いような気もしてるけど、今のところ、これくらいで満足してる

おまけ:他によく使う Git のコマンド

git fetch -p でリモートの更新を取得

  • ラッキングブランチや git pull が苦手なので、いつも git fetch -p

git rebase でブランチの移動

  • main ブランチが更新されたときに、たまに作業ブランチを付け替えたりする

git rebase -i でコミットの操作

  • コミットをまとめたり、コメントを書き換えたりするのに使う

git branch -m でローカルブランチのリネーム

  • プルリクエストがマージされてローカルブランチがいらなくなったら、別のチケット用にリネームして使ったりする

git branch -d でローカルブランチの削除

  • いらなくなったローカルブランチの削除ちょこちょこする。-D で強制削除したりもする

git reset で変更のやり直し

  • 例えば git reset HEAD~1 で、今いるコミットの変更を未コミット状態にして、変更をやり直したりする

git reset --hard HEAD git clean -df で変更を削除

  • 記録に残らなくていいものはこれで削除。コミットせずに git reset --hard すると元に戻せないので気をつけないと悲しいことになる。後で見たいかも?と思う場合はとりあえずコミットするようにしてる

git stash git stash --pop で一時的に退避

  • 作業中の変更を一旦横に置いておきたいときに使う

あれ?最近 git merge 使ってないなぁ。あんまり変更がかぶらないからかな。update-ref も全然使わないや。cherry-pick は、たまーに使うかなぁ

よく使うわけじゃないけど、覚えてるのが git reflog 。コミットさえしてれば、何かあったときに git reflog で元に戻せる!

また Git のドキュメントでも眺めて、自分が使いそうなコマンドを探してみよっと

僕の推し Git コマンド

やっぱり git switch かな!よかったらあなたの推し Git コマンドを教えて下さい!

自分の職務経歴書を公開

去年の夏頃に使ったやつ。なんとなく、公開しておいてもいっかなぁって考えてたことを思い出したので公開。住所とか会社名とかは消してる

考えてたことは

  • 忙しい中でパッと見て「話を聞いてみようかな」って思ってもらえたらいいなって気持ちで書こ
  • 経験を全部書いてもよく分からなくなりそうだから、3つくらいアピールできそうなこと書いとこ
    • ICとして働きたいからマネージメントよりもエンジニアリング経験アピールで
  • この歳で背伸びをしたり伸びしろアピールをしても仕方がないので、今の自分をそのままを書いとこ
  • 右側の一覧の、例えば Java 15年分のスキルがある感じはしないけど、まぁ嘘ではないし書いとこ

みたいな感じ。シンプルすぎるかなぁとも思いつつ、まぁ、これで書類通らないところとは、ご縁がなかったってことでいっかなーくらいの気持ちで

実際は、これと一緒にカバーレターを書いて、そっちに「どうして応募したのか、どう役に立てるか」みたいなのを書いてる

今書くなら、SRE の経験を外して、フルスタックエンジニアを足すかな

こういう書き方がどうなのかはよくわかんないけど、こういう風に書いた人もいるよってことで、誰かの何かの参考になれば嬉しいかな