Feat/axios

[VictoryJu]

🎫 [지라 티켓 번호]

🛠️ 작업 내용

기존 사용했던 fetch대신 axios로 변경하였습니다.

📱 작업 화면

화면 이름	스크린샷
ViewName

🗒️ Note (optional)

[gbwlxhd97]

@VictoryJu 서버 api 환경변수 적용하면 좋겠습니당

[gbwlxhd97]

ga관련 키값도 환경변수로갈까요

[VictoryJu]

@gbwlxhd97 환경변수 적용해두는게 좋을것같네유 의견감사합니다!

[VictoryJu]

해당부분 env로 변경하였으나, 배포하게되면 aws에서 env환경변수가 적용되지않아 api호출이 안될것같습니다.

server쪽에서 확인 한번 한 다음 머지하도록 하겠습니다.

@gbwlxhd97 @emibgo2 @shine-jung

[emibgo2]

해당부분 env로 변경하였으나, 배포하게되면 aws에서 env환경변수가 적용되지않아 api호출이 안될것같습니다.

server쪽에서 확인 한번 한 다음 머지하도록 하겠습니다.

@gbwlxhd97 @emibgo2 @shine-jung

기본적으론 S3는 정적 웹사이트만 지원해주기 때문에 환경변수 셋팅이 없습니다만
react build 시에 환경변수를 주입해주는걸로 가면 될것 같습니다.

다만 환경변수가 늘어나면 늘어날수록 action 등 수정할께 많아짐으로 AWS SSM Parameter Store를 사용하시는것을 권장합니다.

빌드시 환경변수는 AWS Access Key, Secret Key만을 주입하고 코드 내부에선 Parameter Store의 환경변수를 불러와 사용하면 관리포인트가 줄어듭니다.

mongle-server의 loadParameterStoreValue를 참고해주세요

추가적으로 Parameter Store는 /를 통해 계층적 구조를 만들 수 있습니다.
web에서 사용할 prefix를 포함시켜주세요
ex) /mgmg/web/api/baseUrl

[gbwlxhd97]

해당부분 env로 변경하였으나, 배포하게되면 aws에서 env환경변수가 적용되지않아 api호출이 안될것같습니다.
server쪽에서 확인 한번 한 다음 머지하도록 하겠습니다.
@gbwlxhd97 @emibgo2 @shine-jung

기본적으론 S3는 정적 웹사이트만 지원해주기 때문에 환경변수 셋팅이 없습니다만 react build 시에 환경변수를 주입해주는걸로 가면 될것 같습니다.

다만 환경변수가 늘어나면 늘어날수록 action 등 수정할께 많아짐으로 AWS SSM Parameter Store를 사용하시는것을 권장합니다.

빌드시 환경변수는 AWS Access Key, Secret Key만을 주입하고 코드 내부에선 Parameter Store의 환경변수를 불러와 사용하면 관리포인트가 줄어듭니다.

mongle-server의 loadParameterStoreValue를 참고해주세요

추가적으로 Parameter Store는 /를 통해 계층적 구조를 만들 수 있습니다. web에서 사용할 prefix를 포함시켜주세요 ex) /mgmg/web/api/baseUrl

그럼 환경변수를 deploy.yml 작동할 때,
action에서 env 추가하고
git secret key로 관리하면 어떨까요?
@VictoryJu
@emibgo2

[emibgo2]

해당부분 env로 변경하였으나, 배포하게되면 aws에서 env환경변수가 적용되지않아 api호출이 안될것같습니다.

server쪽에서 확인 한번 한 다음 머지하도록 하겠습니다.

@gbwlxhd97 @emibgo2 @shine-jung

기본적으론 S3는 정적 웹사이트만 지원해주기 때문에 환경변수 셋팅이 없습니다만 react build 시에 환경변수를 주입해주는걸로 가면 될것 같습니다.

다만 환경변수가 늘어나면 늘어날수록 action 등 수정할께 많아짐으로 AWS SSM Parameter Store를 사용하시는것을 권장합니다.

빌드시 환경변수는 AWS Access Key, Secret Key만을 주입하고 코드 내부에선 Parameter Store의 환경변수를 불러와 사용하면 관리포인트가 줄어듭니다.

mongle-server의 loadParameterStoreValue를 참고해주세요

추가적으로 Parameter Store는 /를 통해 계층적 구조를 만들 수 있습니다. web에서 사용할 prefix를 포함시켜주세요 ex) /mgmg/web/api/baseUrl

그럼 환경변수를 deploy.yml 작동할 때,

action에서 env 추가하고

git secret key로 관리하면 어떨까요?

@VictoryJu

@emibgo2

git secret이 action secret 말씀하시는건가요

만약에 action secret이면 제가 이미 Organization 단위로 secret key 잡아 놓은게 있습니다.

[VictoryJu]

해당부분 env로 변경하였으나, 배포하게되면 aws에서 env환경변수가 적용되지않아 api호출이 안될것같습니다.

server쪽에서 확인 한번 한 다음 머지하도록 하겠습니다.

@gbwlxhd97 @emibgo2 @shine-jung

기본적으론 S3는 정적 웹사이트만 지원해주기 때문에 환경변수 셋팅이 없습니다만 react build 시에 환경변수를 주입해주는걸로 가면 될것 같습니다.

다만 환경변수가 늘어나면 늘어날수록 action 등 수정할께 많아짐으로 AWS SSM Parameter Store를 사용하시는것을 권장합니다.

빌드시 환경변수는 AWS Access Key, Secret Key만을 주입하고 코드 내부에선 Parameter Store의 환경변수를 불러와 사용하면 관리포인트가 줄어듭니다.

mongle-server의 loadParameterStoreValue를 참고해주세요

추가적으로 Parameter Store는 /를 통해 계층적 구조를 만들 수 있습니다. web에서 사용할 prefix를 포함시켜주세요 ex) /mgmg/web/api/baseUrl

그럼 환경변수를 deploy.yml 작동할 때,
action에서 env 추가하고
git secret key로 관리하면 어떨까요?
@VictoryJu
@emibgo2

git secret이 action secret 말씀하시는건가요

만약에 action secret이면 제가 이미 Organization 단위로 secret key 잡아 놓은게 있습니다.

action secret key 확인했습니다. 프론트에서 사용되는 key가 부족한것같아 따로 추가해서 해당 레포지토리에서만 이용하게 하는건 어떨까요?
@emibgo2 @gbwlxhd97

[VictoryJu]

추가로 궁금한것이있는데요,

현재 github action을 위해 ci.yml 파일과 deploy.yml파일이 있습니다.

ci.yml파일에서 빌드를 진행하고
deploy.yml 파일에서 배포를 진행하는것으로 보입니다.

      - name: Install Dependencies
        run: npm install

      - name: Build
        run: npm run build

ci.yml 파일이 먼저 실행되고 빌드 파일이 만들어지는것같은데,
npm run install , npm run build 하는 과정이 deploy.yml에서는 필요없지않을까 생각되서요.

두번 빌드하면 배포할때 시간이 더 걸릴것같아서 한번만 빌드하면 배포시간을 줄일수있지않을까 싶습니다.
@emibgo2 @gbwlxhd97

[emibgo2]

추가로 궁금한것이있는데요,

현재 github action을 위해 ci.yml 파일과 deploy.yml파일이 있습니다.

ci.yml파일에서 빌드를 진행하고

deploy.yml 파일에서 배포를 진행하는것으로 보입니다.

      - name: Install Dependencies

        run: npm install



      - name: Build

        run: npm run build

ci.yml 파일이 먼저 실행되고 빌드 파일이 만들어지는것같은데,

npm run install , npm run build 하는 과정이 deploy.yml에서는 필요없지않을까 생각되서요.

두번 빌드하면 배포할때 시간이 더 걸릴것같아서 한번만 빌드하면 배포시간을 줄일수있지않을까 싶습니다.

@emibgo2 @gbwlxhd97

1. 두개의 워크 플로우는 서로 트리거되는 이벤트가 다릅니다.
2. 액션은 기본적으로 워크플로우마다 다른 인스턴스가 잡히기때문에 배포속도엔 영향이 없습니다.

[VictoryJu]

추가로 궁금한것이있는데요,
현재 github action을 위해 ci.yml 파일과 deploy.yml파일이 있습니다.
ci.yml파일에서 빌드를 진행하고
deploy.yml 파일에서 배포를 진행하는것으로 보입니다.

      - name: Install Dependencies

        run: npm install



      - name: Build

        run: npm run build

ci.yml 파일이 먼저 실행되고 빌드 파일이 만들어지는것같은데,
npm run install , npm run build 하는 과정이 deploy.yml에서는 필요없지않을까 생각되서요.
두번 빌드하면 배포할때 시간이 더 걸릴것같아서 한번만 빌드하면 배포시간을 줄일수있지않을까 싶습니다.
@emibgo2 @gbwlxhd97

1. 두개의 워크 플로우는 서로 트리거되는 이벤트가 다릅니다.
2. 액션은 기본적으로 워크플로우마다 다른 인스턴스가 잡히기때문에 배포속도엔 영향이 없습니다.

서로 다른 이벤트라면 동일하게 넣어주어야되겠군요 이해했습니다 감사합니다!

secret key 추가해서 github action 에서 빌드할때 추가하도록 하였습니다.
추가커밋 -> 8e8eb72 @gbwlxhd97