Open MikeTheCanuck opened 5 years ago
The 2017 API containers have drifted pretty far from the 2018/2019 API configuration and CI/CD setup, so it is first necessary to upgrade the 2017 API, container and Travis configurations before the CloudFormation migration will ever succeed:
Follow the steps outlined here: https://github.com/hackoregon/civic-devops/issues/260#issuecomment-520180942
The actual changes to master.yaml
ultimately result in:
2017Transport
Resource to the # 2017 API Services - Fargate
section (currently around here) transportService
Resource block from master.yaml
.The newly-created Resource will have a new Service name in the ECS interface (e.g. hacko-integration-2017Budget-YOMCBA6UTARG-Service-1F3RKQ7TN48S
) which will need to be used as the ECS_SERVICE_NAME variable in the associated Travis repo's Settings:
https://travis-ci.org/hackoregon/transportation-backend/settings
Until the Travis configuration knows of the new ECS Service Name, any deployment via Travis will fail its attempt to deploy the Travis-build container image to the old Service (which will be gone as soon as the CloudFormation migration strategy is underway).
Delete the old value and create a new one (and feel free to make it non-secret - it's more important to be able to review the Travis env var settings when troubleshooting future problems, than it is to protect configuration parameters like this that aren't really secret. NOTE: you will need elevated privileges in the associated GitHub repo to be able to access and update the Travis repo Settings.
Addresses #244 for the 2017 Transportation API. Mirrors the work in #259 and #260, and implements similar changes as hackoregon/hackoregon-aws-infrastructure#84. Uses the migration procedure documented here.
Acceptance Criteria
Tests that will confirm the container has successfully migrated: