search

LiveRamp / reslang

A language for describing resource-oriented APIs & turning them into Swagger or resource diagrams. Oriented around the concepts we want to expose in the APIs.
Apache License 2.0
23 stars 7 forks source link

Reslang Build is Broken #110

Closed njaczko closed 4 years ago

njaczko commented 4 years ago

The Reslang build is broken right now because the ./reslang executable in the root of the repo was deleted in the commit linked below, but the Dockerfile still relies on the executable.

https://github.com/LiveRamp/reslang/commit/57d3566370a98e9b3dd8b362291800dc0b59dc41

The installation script does not work unless ts-node is installed globally, but this dependency is not documented anywhere.

I can open a PR at some point, but I don't have time at the moment.

njaczko commented 4 years ago

whoops didnt mean to close!

liveandrew commented 4 years ago

fixed, please retest

njaczko commented 4 years ago

@liveandrew This is how you can tell if the build is broken.

Screen Shot 2020-09-18 at 2 20 03 PM

The Dockerfile is still referring to a file that has been deleted: https://github.com/LiveRamp/reslang/blob/master/Dockerfile#L16

I feel like we're rushing a bit here.

liveandrew commented 4 years ago

I feel like we're rushing a bit here.

thanks, helpful input.

liveandrew commented 4 years ago

please retest

njaczko commented 4 years ago

The build has been fixed now - you can see that the red X has turned into a green check.

Screen Shot 2020-09-18 at 2 41 59 PM
njaczko commented 4 years ago

It looks like the ts-node dependency has also been removed, but the "installation" is definitely unconventional. It generates a user-specific file that must be present in the local clone of the reslang repository... it is not gitignored but it also should never be checked in. Regardless, running git clean will "uninstall" reslang, which would definitely be unexpected behavior. We should definitely come up with a better solution before this project is open sourced. We can create a separate issue for this because the problems I enumerated when I opened this issue have been fixed.

For the record, it is much more conventional to have these sorts of discussions on a Pull Request. That way we could make sure everything works before it ends up in production, and not break production while we're waiting for changes to be tested.