At the moment, the application is not blessed with automated testing, yet.

A pull-request altering the core logic quite a bit has been merged already, and another with less to worry about (thanks to third-party tools robustness like prettier and eslint) are pending at the moment.

However, we might want to change this state for the best by putting together a continuous integration pipeline. Perhaps, GitHub actions would be enough here.

As a result, there are few options

• [ ] travis-ci
• [ ] circleCI
• [x] GitHub Actions
• [ ] Codeship
• You name it (by commenting)?

We could take the opportunity offered by @TheGuit with https://github.com/guillaume-rygn/Twitter-header-bot/pull/8 to go one step further and having basic tests running, hence preventing dreaded regressions.

To begin with, I'd suggest that a single test run would be enough only for ensuring workflows or builds to be triggered on pull-request creation

Hey @guillaume-rygn,

Awesome share! Thanks 🙏🏼!

Please let me know if you'd rather have some of this pull-request modifications merged, removed or altered.

Hello,

I add a dockerignore file. To be sure we don't send to docker's context all data in current folder (.git folder, current node_modules folder).

It reduce amount of data sent from 32 MB to 290kB.

Then I ensure that we don't do any magic operation during node modules installation.

Using npm ci is mandatory on those context because we don't want to have a magic resolution of dependency. We want to stick to exact version listed in package-lock.json file.

For example it will not install a newer version, remember all that compromised dependency ...

To response to other topic listed here : https://github.com/guillaume-rygn/Twitter-header-bot/pull/8#issuecomment-1222470639

This Dockerfile should be made with the state of art and do not provide any way of testing if the repository is inconsistent. T hoses topics should be addressed by adding à CI pipeline like mentioned in https://github.com/guillaume-rygn/Twitter-header-bot/issues/11 . All commit need also to be consistent and all commit must build.

There are different kinds of documentation starting to emerge for

• configuration
  • there is a Makefile ready to be put to good use maybe?
  • the .env file to be created is in the README.md at the moment
• installation (pretty much straightforward for some not that obvious nonetheless)
  • with docker
  • without docker
  • with asdf
  • in continuous integration
• deployment (in notion) as far as I know

Perhaps we could

• [ ] Create a directory with separate files(?) or is it too early and
• [ ] The README.md will be totally enough for a while(?)

There is also the matter of automating as much as possible chunks of documentation for which copy-paste might be replaced with

• [ ] a Makefile target (configuration example) or
• [ ] a npm run scripts (examples provided by @TheGuit) for linting for example

Two additional questions for you, @guillaume-rygn

Thanks!

The possibility of a Makefile introduction has been suggested with https://github.com/guillaume-rygn/Twitter-header-bot/pull/6

However, it brings some complication with an additional scripting language that is to say bash "only" for creating a .env file. In my experience, not having to copy-paste snippets of code usually help with automation.

Still, introducing a Makefile with two targets might be a little too early, too overkill for

• printing the documentation in a terminal by running

make help

• [configuration] the Twitter header bot by running

make configure 

Besides it brings a dependency on GNU Make

There are also Pros, it will provide users with a standard entrypoint for

• configuring the project
• accessing the help manual
• running the bot
• running future test or continuous integration workflow step

I also imagine npm scripts could be put to good use here with these exact same goals in mind as well.

I guess, the decision is your hands @guillaume-rygn :

• [ ] Sticking with npm run and the likes
• [x] Introducing a somewhat more general tool like Makefile with phony targets

It would allow one to create the .env file by running the following command (after filling in the blanks, of course 😅)

API_KEY= \
API_SECRET= \
ACCESS_TOKEN= \
ACCESS_SECRET= \
SCREEN_NAME='revue_2_presse' \
make configure

Adding dockerfile to run this on docker container

1. Build image using : docker buid -t twitter-banner-bot . in folder that contains Dockerfile
2. Run image using : docker run --name twitter-banner-bot -e API_KEY="" -e API_SECRET="" -e ACCESS_TOKEN="" -e ACCESS_SECRET="" -e SCREEN_NAME="" twitter-banner-bot

This should works, let me know if everything seem okay.

You can also build this containers and push into github docker registry

Petit refactor de la fonction qui mettait à jour la location avec le nombre de followers, parce que tous ces if/else me donnaient envie de me tirer une balle 😅