Dockerfile/Ability to run this in a pipeline about message-segment-calculator HOT 4 CLOSED

Hey @brandonmcclure thanks for the suggestion. Actually the whole refactoring we did few weeks ago was to create a package to do exactly what you need. It's an npm package, so you can install it on any server / docker image / GitHub actions without having to clone this entire repo. The usage instructions are in the README of this repo. I would advice against using the repo directly, since there are several artefacts that are not needed to run the core functionality (e.g. calculating the number of segments an SMS would take).

When the business requests a new SMS message sent out, I want them to submit the message as code into our git repository

I'm not sure how are you planning to design this service. The best approach is to create your own API services for your client that take the message body, calculate the segments using the sms-segments-calculator and return the number of segments. Alternatively you can use the browser release of the package to provide this functionality in the frontend (i.e. browser). Can you clarify what advantage the Docker image can bring over the npm package? It seems to me a bit of an overkill in this use case

I have created a Dockerfile and Makefile that I used to run the playground/index.js file
As mentioned above, this is not the way this repo is intended to be used. The main reusable component released with this repo are the npm and the browser package (more on this below)

I had to move the devDependencies into the Dependencies property of the package.json file to get it to run and I am not sure of the effects of that
This is needed only because the playground is not the intended way to use the code. Adding devDependencies to dependencies will have an impact on the npm package, so I'm not keen on doing that.

Also what is the difference between playground and dist?
Let me explain a bit more how this repo is organised (most of this info are in the README):

• src: this contains the Typescript code of the library
• dist: this contain the transpiled code (from the typescript code in src) for the package. This is the same code that gets uploaded to npm in sms-segments-calculator. It's standard practice to not have the dist folder in the repo, so we may remove it at a later stage.
• playground: this folder gives you an example of how to use the npm package code. The main purpose of it is to experiment with the transpiled code (and any local changes you make to it) in the dist folder. But you can achieve the same without having to clone the repo. You simply have to follow the nodeJS usage instructions in the README
• doc: this folder has two purpose: It's used by GitHub pages to serve the static files you access at https://twiliodeved.github.io/message-segment-calculator/ and contains the browser version of this package (segmentsCalculator.js). Once again, you don't need to clone this repo to use this library, and you can just follow the usage instructions in the README (section "Browser")

Let me know if that clarify how this repo should be used.

from message-segment-calculator.

Thanks for the explanation! That does clarify a lot!

I enjoy building via docker images because it simplifies the dependencies needed for a developer to build/run the app (Where I work we don't have much node experience). It also makes it easier for me to build/test different branches. If my dockerfile installs via the npm package but I want to test out some custom development from my/other's forks then I need to hack around my dockerfile to make it work with the patched code.

I don't have a good example on gihub, but this article outlines the general idea of building/test/release all via a single multi-stage dockerfile/multiple different images: https://medium.com/@cyril.delmas/how-to-keep-the-build-reports-with-a-docker-multi-stage-build-on-jenkins-507200f4007f

If I stood up a API service I would do so via docker/k8s, so personally I would prefer a docker image that is officially released vs one that I am managing via the npm package because it would be less work for me :-)

from message-segment-calculator.

Thanks @brandonmcclure for getting back. The docker image is definitely an interesting idea. Jut to make sure I understand, your ideal flow would be to spin a docker image on your laptop and use the script (e.g. playground/index.js) to calculate the number of segments. Am I correct?

I still think that this repo contains too many artefacts and scripts that are not really needed in a docker image. If you confirm that the flow is the one above, I can attempt to create a small docker image that only contains the node environment, dependencies and the playground/index.js script.

from message-segment-calculator.

Looks like this issue is stale, closing - but do let us know if you would like any help using the package in your docker image.

from message-segment-calculator.