Docker deployment

[4l1fe]

What do you think about wrapping it up with in a docker container to let people pull\build and run it where they would like on, not Vercel only?

As an image registry Github or Docker Hub can be taken.

[rickstaa]

@4l1fe I did consider making a GRS GitHub action some weeks ago, so I like your proposal. I, however, am not yet sure where the output SVG from such an action/docker should be placed. It could be added to a README.md file, which can mess up user formatting. Alternatively, it could be stored as an SVG under the action's repository. How were you planning to use it?

[4l1fe]

Good question. I consider using docker on my own server, not Github Actions. So it could be better to find a solution which is unbound to Github platform or any others.

To be honest, i didn't read the source code and ,therefore, i have no clear idea about how it should be.

[4l1fe]

Well, in a case of Github Actions you could save an output from /api response to an svg file in a root of repo workdir. Then users could link to it in their README.md file as they will be aware of it's name and location, for example default name is github-stats.svg. An svg file's name can be an option of Github Actions, i'm not sure about GA functionality.

[4l1fe]

In a case of pure docker container, wherever it has been ran, the /api response output is capturing by a command line and saving into an svg file. Then a user is pretty free to serv the file as need.

[rickstaa]

Looks good to me! That container can then also be used in a GitHub action. 🚀

Let's discuss the implementation for a bit. I think the SVG files can be saved using the fs library. How were you planning on receiving the query parameters? Should people pass a full query string to the docker container (i.e. username=anuraghazra&show_icons=true&theme=radical)? Or do you want to receive the query parameters as separate docker inputs? I think the last option would break when we update the main repository. For the last option, we could use the URLSearchParameters class to parse the queries and pass them to the GRS API. Lastly, do you have any ideas on telling the docker container which card you want to generate?

[4l1fe]

How were you planning on receiving the query parameters? Should people pass a full query string to the docker container (i.e. username=anuraghazra&show_icons=true&theme=radical)?

If we pass the query params to a container then a webserver should be added to simply forward them to it to get them parsed as is. No additional code. But the werbserver has to listen to one request only and then get stopped. The downside here is the adding a webserver.

Second option means, instead of adding a webserver, a cli interface should be added which can convert\map the cli arguments to the query params docker run grs --username=name --show-acions=true -> map_args(args): return username=anuraghazra&show_icons=true and then they are handling as is. The downside here is it takes a bigger effort to code args convertation\mapping logic. But it's a proper cli approach, command has been executed in a container and a result is returned.

[rickstaa]

@4l1fe I would not spin up the webserver since we can compile the code and pass the arguments directly to the API (see https://github.com/anuraghazra/github-readme-stats/blob/master/tests/api.test.js#L86 for an example). I think we can take in a list of CLI arguments and give these to the function. We should then throw a warning when an argument does not exist. This would result in the following workflow: Docker + --card-type flag and CLI arguments --> run javascript file that uses card-type to forward CLI arguments to the right API (i.e. https://github.com/anuraghazra/github-readme-stats/tree/master/api)--> save SVG to folder OR throw an error when CLI argument does not exist. What do you think?

In that case, you only have to build a simple docker recipe based on the node js docker image. This recipe should fetch the repo code and run a simple javascript file that passes arguments to the right API and saves the cards.

[4l1fe]

we can compile the code and pass the arguments directly to the API

If we call await api(req, req) then the biggest effort is gone, that's cool.

What do you think?

I think mostly the same.

Docker + --card-type flag and CLI arguments

One improvement on it. Instead of --card-type flag , specific entry script can be added according to each type of the cards:

entrypoints/
|__stats.js
|__pin.js
|__wakatime.js
|__lang.js

And the container command:

docker run --rm --volume=/path/to/host/stats.svg:/path/to/container/stats.svg grs stats.js --username=name --show-icons=true

---

save SVG to folder OR throw an error when CLI argument does not exist. What do you think?

Not necessary. I think a folder argument is not mandatory here, but optional. A containerized entry script MUST generate an svg file and a default folder has to be predefined for it, and while running a container as above , you can simply map the default folder or svg file to a host one. Volume mapping is a one of the containerization concepts.

At the same time --svg-file-path option has to be added for a case if a user simply runs $ node entrypoins/stats.js --svg-file-path=host/path/to/file.svg in it's host system without Docker. Docker is a layer, a script should be able to be ran without it.

In that case, you only have to build a simple docker recipe based on the node js docker image. This recipe should fetch the repo code and run a simple javascript file that passes arguments to the right API and saves the cards.

File with the js dependencies is required here as a next step after fetching the repo, install them.

[rickstaa]

File with the js dependencies is required here as a next step after fetching the repo, install them.

You are right; I forgot to list those steps. I think the proposal above sounds great. Feel free to create a PR and tag me so I can review it. 👍🏻

[4l1fe]

I'm not sure if i can get it done with Nodejs, but creating a Docker file is a typical routine for me. Anyway, i'll pay some time for coding cli.

Could you recommend me a node lib of cli interface?

[rickstaa]

@4l1fe, Of course, happy to help. I quickly created an example script that can be used to save the stats card. Please be aware that currently, a PAT needs to be set as a PAT_1 variable this might create some security issues that need to be handled correctly.

const fetchStats = require("../src/fetchers/stats-fetcher");
const {
  renderError,
  parseBoolean,
  parseArray,
  clampValue,
  CONSTANTS,
} = require("../src/common/utils");
const renderStatsCard = require("../src/cards/stats-card");
const fs = require("fs");

// Variables (Should be replaced with CLI arguments)
const username = "rickstaa";
const count_private = true;
const count_all_commits = true;
const hide = "";
const show_icons = true;
const hide_title = true;
const hide_border = true;
const hide_rank = true;
const include_all_commits = true;
const line_height = 25;
const title_color = "#000000";
const icon_color = "#000000";
const text_color = "#000000";
const bg_color = "#ffffff";
const custom_title = "Rick Staa";
const border_radius = "1";
const border_color = "#000000";
const theme = "light";
const locale = "en";
const disable_animations = true;

const run = async () => {
  // Retrieve stats
  const stats = await fetchStats(
    username,
    parseBoolean(count_private),
    parseBoolean(count_all_commits),
  );
  console.log(stats);

  // Create card
  const card = renderStatsCard(stats, {
    hide: parseArray(hide),
    show_icons: parseBoolean(show_icons),
    hide_title: parseBoolean(hide_title),
    hide_border: parseBoolean(hide_border),
    hide_rank: parseBoolean(hide_rank),
    include_all_commits: parseBoolean(include_all_commits),
    line_height,
    title_color,
    icon_color,
    text_color,
    bg_color,
    theme,
    custom_title,
    border_radius,
    border_color,
    locale: locale ? locale.toLowerCase() : null,
    disable_animations: parseBoolean(disable_animations),
  });
  console.log(card);

  // Save card
  if (!fs.existsSync("cards")) {
    fs.mkdirSync("cards");
  }
  fs.writeFileSync(`./cards/${username}.svg`, card);

  console.log("finish");
};

run();

Placing all the docker-related scripts in a docker folder is best, so we don't mess with the original GRS code. For a good CLI parser, see https://openbase.com/categories/js/best-nodejs-cli-arguments-libraries. I have only used commander, but minimalist also looks good. Hope that helps.

[rickstaa]

@4l1fe Somebody just implemented an express version of GRS. You can check it out at #2447.

[4l1fe]

Thank you. I got stuck with JavaScript cli implementation and didn't approach to it anymore. I should let you know it, sry.

[rickstaa]

@4l1fe no problem at all. If you still need it, there now is #2447.

[rickstaa]

This feature was merged into the main branch in #2525.