はじめに Node.js(Express)でWeb APIをCallする際のAPI Keyを環境変数にしていた場合に、GitHub ActionsでJestによるCIを回そうとして躓いたのでその時の解決方法を備忘録として残しておく。 どんなテストをしようとしたか？ Node.js(Express)で以下のようなソースコードを実装していて、これのAPIテスト（End Pointテスト）をJest×Supertestで実装し、それをCI上で回そうとしていた。 テスト対象のソースコード（抜粋）は以下。 ${process.env.COUNTRYSTATECITY_API_KRY}の部分で環境変数を使っている。 controller.js const axios = require('axios').default; // dotenv const dotenv = require('dotenv') dotenv.config(); // instance for get countries and cities const instance = axios.create({ baseURL: 'https://api.countrystatecity.in/v1/', timeout: 3000, headers: { 'X-CSCAPI-KEY': `${process.env.COUNTRYSTATECITY_API_KRY}` } }) const allCountries = async (req, res) => { try { const countries = await instance.get('countries') res.send({ countries: countries.data }) } catch (error) { errorHandler(res, error) } } // 省略 テストコードは以下。 test.js const request = require('supertest') const app = require('../../../src/server/app') describe('Get Endpoints (not mocking)', () => { it('/allCountries', async () => { const res = await request(app).get('/allCountries') expect(res.status).toEqual(200) expect(res.body.countries[0].name).toEqual('Afghanistan') }) // 省略 }) ソースコード全体は以下。 ※Jest×SupertestでのNode.js(Express)のAPIテストについてはこちらの記事を参照 解決方法（どうするのか？） GitHubのSecretsに環境変数の値を登録し、GitHub Actionsのパイプライン(yaml)でそれを読み込む。 yamlの方は以下のようになり、envコンテキストにCOUNTRYSTATECITY_API_KRY: ${{ secrets.COUNTRYSTATECITY_API_KRY }}を宣言する事で、Secretsに登録した値がsecrets.COUNTRYSTATECITY_API_KRYで取得でき、環境変数をCIのRunnerが動く環境に設定できる。 jest.yml name: Testing by Jest on: push: branches: - "**" jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: package-lockより環境構築 run: npm ci - name: テスト実行 env: GEO_NAME_USERNAME: ${{ secrets.GEO_NAME_USERNAME }} WAETHERBIT_API_KEY: ${{ secrets.WAETHERBIT_API_KEY }} PIXABAY_API_KEY: ${{ secrets.PIXABAY_API_KEY }} COUNTRYSTATECITY_API_KRY: ${{ secrets.COUNTRYSTATECITY_API_KRY }} run: npm test GitHub ActionsのSecretsはこんな感じになっており、secrets.で取得するkeyで値を登録してある。詳細は「ソースコード全体は以下」のリンクのリポジトリを参照。 実際のJob 上記の設定をせずCIを実行した失敗job : https://github.com/yuta-katayama-23/travel-app/actions/runs/902797963 上記の設定をしてCIを実行した成功job : https://github.com/yuta-katayama-23/travel-app/actions/runs/902827671 参考文献 React x Firebase のCIを Github Actions で組む方法

エラー内容 Mac の docker で node を使っていたら、以下のようなエラーが出ました。 (node:1753) UnhandledPromiseRejectionWarning: Error: connect ECONNREFUSED 127.0.0.1:3306 3306 ということでMySQLに接続できていないようなので、dockerの方を見てみる。 すると以下のエラーが出ていました。 [error] --initialize specified but the data directory has files in it. aborting. どうやらファイルが存在していて失敗しているよう。 だがvolumeやめぼしいファイルを消してみたり、ネットを検索して出てきた記事では解決できませんでした。 解決策 結果としては以下で解決しました。 Docker の Menu から Troubleshoot を選択 Clean / Purge data をする Reset to factory defaults をする どっちが効いたのかわからないけどこれで直りました。

Time Zone of Cloud Functions for Firebase Scheduler does not change Problem I am currently creating and deploying a function to be executed periodically in the Cloud Functions for Firebase scheduler as shown below. The key point is that I want it to be executed every day at 0:05 Japan time as .timeZone('Asia/Tokyo'). The deploy itself is working fine, but when I look at the content in GCP's Cloud Scheduler, the Time Zone is set to (America/LosAngeles) as shown in the image below, and the actual execution time is off from Japan time. I manually changed the time zone to Japan time in the Cloud Scheduler function management screen and confirmed that the desired behavior was achieved, but when I deploy the function again, it is still set to (America/LosAngeles). exports.XXX = functions.pubsub .schedule('every day 0:05') .timeZone('Asia/Tokyo') .onRun((context) => { /// Codes }); Solution It is reported as a bug of firebase-toolsv9.12.0. https://github.com/firebase/firebase-tools/issues/3425 At the time this issue was reported, the solution was to downgrade to firebase-tools version 9.11.0. However, 9.12.1 has now been released, and I have confirmed that using the latest 9.12.1 with Node.js version v16(with nvm) solves the above problem. If you don't know this and deploy the functions, the Time Zone in the scheduler will be set to America, and the app will start running at an unintended time. This will cause the app to fire at an unintended time, so be careful.

はじめに 発生したエラーに対していくらコードを見直しても原因がわからず苦戦したため、メモ 発生したエラー Error: EISDIR: illegal operation on a directory, readh （詳細省略） 原因 ディレクトリーに対してファイル読み取りfs.readFileSyncを行っていたことが原因 本来ファイルのみ存在しているディレクトリに、サブディレクトリを作っていたのが原因。いくらコードを見直しても解決できないのは当然ですね・・

node.jsで、A処理が終わったらB処理を実行するアレを今更書いてみる | ハイテク好きが楽しめるウェブメディア off.tokyo node.jsに限らず、非同期処理を書いてると、上から順番に処理が走らずに変数が未定義のまま次の処理が走ってしまうことがあります。 これを解決するためには、コールバックみたいなものを書いて、処理Aがリターンされたら、処理Bを実行するみたいなことを書かないといけません。 まあ、この手の詳しいことはいくらでも詳しく書いてる情報があるので、今回の記事は備忘録みたいな感じで書くだけです。 書いたコードはこんな感じです。 async function A() { try { // この中でawaitなりで非同期処理でapiとか叩く return "返り値"; } catch (err) { console.log("エラー発生"); console.log(err); } } こんな感じですね。tryの中でapiなりを叩いて、それを受け取ったらリターンする。 A().then(result => { console.log("Aの処理がリターンされたらBを発動させる"); B(result) }); resultはA()を実行して返ってきた値です。 非同期処理で普通に書いてると未定義で進んでしまうのを防ぎます。 node.jsで、A処理が終わったらB処理を実行するアレを今更書いてみる | ハイテク好きが楽しめるウェブメディア off.tokyo