-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Last semester, I set up an endpoint /gtfs-date that exposed when we last automatically fetched the GTFS data from the link that TCAT provided us. GTFS stands for General Transit Feed Specification and is just a zip file containing text files with route id, trip id, bus stop, and etc information that we use to stuff into code we got from Graphhopper so that we can get the routes.
To give some context, our server transit-prod right now has a node image and a python image for ithaca-transit-backend and ithaca-transit-tcat-microservice respectively. We have another server transit-ghopper that has an image of the ghopper directory in ithaca-transit-backend. iOS pings the endpoints only running from the node image, and the code in the node image pings the python microservice and ghopper.
We have GTFS data in the python microservice and in ghopper in order for ithaca-transit-backend to properly return routes to the iOS client. The Dockerfile for ghopper already contains the command to fetch GTFS data from the url TCAT gave us, so all I have to do in order to update ghopper with the recent GTFS data is just build it and deploy it to transit-ghopper. However, for the microservice, I have to download the zip myself, put it in the microservice, build the image, and deploy it to transit-prod.
So, the tasks to be done is once I get the /gtfs-date endpoint set up to return the date that the GTFS data is no longer valid for, it'd be great to have integration ping that endpoint to:
- slack the transit-integration-results channel that the GTFS data is about to expire
- build a new image of the microservice and ghopper and deploy them to their servers