Closed kaihendry closed 4 years ago
CI is failing here since it's not building in the more controlled Dockerfile environment
I need to update .travis.yml
https://github.com/unee-t/frontend/blob/master/.travis.yml#L23
WIP, don't have time to work on it.
It appears running tests in the docker environment is pretty tricky.
CI is failing here since it's not building in the more controlled Dockerfile environment
This is actually not accurate AFAICT: when the tests are run on the node js 12 image built by Travis CI then the tests are passing:
See https://travis-ci.org/unee-t/frontend/builds/647650880 for an example of this.
There are indeed a few warnings flagged in the tests but apparently nothing fatal.
One solution might be to: 1- get Docker to build an image similar to the image that Travis CI node js 12 builds <-- get a working Docker image. 2- Optimize our code to make sure we are addressing the warning flagged by the build
@kaihendry what do you think of this methodology?
Docker installs meteor 1.9.
Travis CI seems to be using an older (unspecified AFAICT) meteor version
See the latest build: https://travis-ci.org/unee-t/frontend/builds/647920287
https://travis-ci.org/unee-t/frontend/jobs/647935938?utm_medium=notification&utm_source=github_status has the same node_js as https://travis-ci.org/unee-t/frontend/builds/647650880 and it fails. meteor npm install --save bcrypt
is probably something to do it.
There was a similar looking issue here: https://github.com/laverdet/node-fibers/issues/409. Need to check if the fix implemented will also work for us.
Spent too much time getting the proprietary travis env working here. I rather defer to https://github.com/unee-t/frontend/pull/897 and use CodeBuild & focus on solely using the Dockerfile as the build env as before
The should deploy via https://ap-southeast-1.console.aws.amazon.com/codesuite/codepipeline/pipelines/frontend/view?region=ap-southeast-1
But now the problem here is that the env in the code deploy was not updated since https://github.com/unee-t/frontend/blob/master/buildspec.yml#L36 only updates the image name, not the environment.
The workaround I think is to do a manual ./deploy.sh
to refresh/resync the env and create a new task. There might be a automated way of doing it by somehow mapping SSM secrets into the ECS docker-compose, but I am not sure how to do that.
But now the problem here is that the env in the code deploy was not updated since https://github.com/unee-t/frontend/blob/master/buildspec.yml#L36 only updates the image name, not the environment.
Moving to a logic where the Docker image in seen as a separate entity from the rest of the code as described in Issue #895 might be worth considering to have a clean way of maintaining our codebase... See this article for a description of the “Docker repo” pattern
Just ran a ./deploy.sh
that created the new task https://ap-southeast-1.console.aws.amazon.com/ecs/home?region=ap-southeast-1#/taskDefinitions/meteor/394 with the updated API_ACCESS_TOKEN.
Changing a secret across the env amongst the frontend, backend and the all the lambdas presents a lot of challenges and it would take quite some work to automate.
https://github.com/unee-t/frontend/pull/750 which I think solves https://github.com/unee-t/frontend/pull/892#issuecomment-583220464 because it locks down to .meteor/release