静岡大学などの研究チームは3月13日、花粉の出ない新たな「無花粉スギ」を開発したと発表した。正常に花粉を形成できない現象「雄性不稔」の遺伝子を持ちつつ、成長や材質などにも問題のないスギの選抜に成功。研究チームはこのスギを「春凪」(はるな)と命名した。
花粉を出さないスギ「春凪」、静岡大が開発 研究期間15年の成果 「花粉症に苦しんだ時期に静かに暮らせるように」 - ITmedia NEWS
⇧「無花粉ヒノキ(檜木・檜)」の方の研究の状況も気になりますな...
なお、花粉の少ないヒノキについても品種の開発に取り組んでおり、令和6(2024)年3月時点で、少花粉ヒノキ等159品種が開発されている。
花粉の少ないヒノキ苗木の生産量は令和4(2022)年度で約200万本であり、ヒノキ苗木の生産量の約3割となっている(*22)。ヒノキについては、採種園において着花を促す薬剤処理技術等の課題があるため、採種園における種子の生産工程の短縮技術が確立されておらず、現在、増産に向けて林木育種センターが短期間で安定的に種子を生産する技術の開発に取り組んでいる。
⇧ 研究は継続されているらしい。
後は実地に適応できている状況はいかほどなのかということを知りたいところですな...
年毎に、
- 従来のスギ、ヒノキの生育本数(県毎)
- 無花粉のスギ、ヒノキの生育本数(県毎)
推移を統計したものを可視化して公開して欲しいところですな...
対応状況が全く持って分からないので...
GitHub Actionsのworkflow_dispatchは動的な入力に未対応。故のrepository_dispatch?
ネットの情報を漁っていたところ、
⇧「GitHub Actions」の「トリガー」に指定する「イベント」の内の1つである「workflow_dispatch」については、今のところ「動的」のインプットに対応できていないらしい。
つまり、事前に決め打ちした値しか利用できない...
現状、「GitHub Actions」の「トリガー」に指定する「イベント」で「動的」のインプットに対応しているのは、「repository_dispatch」のみとなっていそうな気はする。
「repository_dispatch」はというと、
https://docs.github.com/ja/rest/repos/repos?apiVersion=2022-11-28#create-a-repository-dispatch-event
https://docs.github.com/ja/rest/repos/repos?apiVersion=2022-11-28#create-a-repository-dispatch-event
⇧ とあり、「REST API」の「Create a repository dispatch event」というリクエストの「パラメーター」の1つである「client_payload」で、任意のデータを渡すことができますと。
ということは、
- 「案件」を一意に識別できる情報を「GitHub Actions」の「ワークフロー(.github/workflows/*.yml)」で受け取れるようにしておく
- イベントrepository_dispatch
- 「案件」を一意に識別できる情報の一覧のファイル
- シェルスクリプトなどでREST APIを実行する
のような流れで、処理対象が複数の場合に一括処理ができると。
■「ワークフロー(.github/workflows/*.yml)」
on: repository_dispatch: types: - deploy_app jobs: example_matrix: runs-on: ubuntu-latest steps: - name: Checkout Repository uses: actions/checkout@v4 - name: Install Ansible and Docker modules run: | pip install ansible ansible-galaxy collection install community.docker - name: Create tmp vault password file run: | echo "{{ secrets.VAULT_PASSWORD }}" > inventory/tmp-vault-password.txt - name: Run Ansible Playbook run: | ansible-playbook -i inventory/hosts.yml ./ansible/playbook.yml --vault-password-file inventory/tmp-vault-password.txt --extra-vars "matter_list=${{ github.event.client_payload.matter_ids }}"
■matter-list.txt
matter-00000001 matter-00000002 matter-00000003 matter-00000004 ... matter-00010001
■イベントrepository_dispatchを発火するリクエストを実行するシェルスクリプト
#!/bin/bash # GitHub設定 GITHUB_TOKEN="your_personal_access_token" # GitHubのパーソナルアクセストークン REPO_OWNER="your_github_username_or_organization" # リポジトリのオーナー REPO_NAME="your_repository_name" # リポジトリ名 EVENT_TYPE="deploy_app" # イベントタイプ(任意で変更可能) API_URL="https://api.github.com/repos/${REPO_OWNER}/${REPO_NAME}/dispatches" # matter-list.txt ファイルのパス MATTER_LIST_FILE="matter-list.txt" # matter-list.txt からすべてのmatter_idをリストとして読み込む MATTER_LIST=$(<"$MATTER_LIST_FILE" tr '\n' ',' | sed 's/,$//') # GitHub APIに送るpayload PAYLOAD=$(jq -n \ --arg event_type "$EVENT_TYPE" \ --argjson matters "[$MATTER_LIST]" \ '{ event_type: $event_type, client_payload: { matter_ids: $matters } }') # repository_dispatchイベントを送信 curl -X POST "$API_URL" \ -H "Authorization: Bearer $GITHUB_TOKEN" \ -H "Accept: application/vnd.github.v3+json" \ -d "$PAYLOAD" echo "Dispatched event with matters: $MATTER_LIST"
⇧ といった感じで、外部から「可変」な情報を「GitHub Actions」の「ワークフロー(.github/workflows/*.yml)」渡すことができると。
リクエストは、
⇧「Rate limit」の制約を考慮した形にする必要がありますが...
もう一つ、別に「ワークフロー(.github/workflows/*.yml)」を用意して、
- DEV環境(DEVELOPMENT:開発環境)
- STG環境(STAGING:ステージング環境)
- PRD環境(PRODUCTION:本番環境、商用環境)
毎のブランチで「PR(Pull Request)」がマージされたことをトリガーに自動テストなども事前に行うような形にするのが良いんでしょうね。
となると、「matter-list.txt」のような対象のリストをどう管理して取得するかって話になって来るのだが、外部のサービスで保管するのが一般的という気もするので、「ワークフロー(.github/workflows/*.yml)」内で、取得リクエストを実施する感じになるんかな?
「RDBMS(Relational DataBase Management System)」なんかで管理するのが一般的な気はするが...
リクエストのAPIを実行するための認証情報などは、「GitHub Actions」の「Secrets」で管理する感じになるんかね?
毎度モヤモヤ感が半端ない…
今回はこのへんで。