You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Could we try directly generating images from the built version's github-stats within CI/CD? #149
Since the compiled and released is already, is it possible to directly download the latest github-stats within the github action workflow and then directly generate the image?
This eliminates the need to use the entire repository as a template.
Hi! It would be easy to modify the Actions workflow to do this. If you'd like to do it on your copy, I'm happy to help you get it set up.
I don't this on my version for a specific reason: the releases only rebuild when a new version tag is pushed to Git. As a result, the compiled binaries lag a bit behind the latest master commit, but I want the images to be built off of the tip of master.
To make this change, you could drop the Zig install step, and replace the zig build --release part of the workflow with something like this:
+1 to that—it would be much easier to be able to run this as an action without creating a copy of the repository. That would greatly simplify the process of deploying this rop, as well as receiving changes and updates.
@jstrieb To be honest, I don’t quite understand what exactly you’re trying to achieve by building images from the tip of the master branch. It seems this could lead to unstable behavior in case of changes. Instead, you could use the version jstrieb/github-stats@2 or a hash to specify the exact commit for the changes.
Directly downloading github-stats to generate images is helpful for those who aren't in a rush to build and generate images using the latest code in master.
Rebuild and regenerate the project after cloning it from GitHub Actions; this is for those who always want to use the latest code.
This way they don't need to copy a copy of the code/repo.
The Actions workflow that runs needs to live somewhere, and the generated images also need to live somewhere. If a user already has another Actions workflow that runs daily, they might want to pull in a pre-compiled github-stats binary, and thereby avoid copying this repo. But I doubt that describes most of the users.
The detailed README instructions are targeted towards people who have a freshly-made GitHub account, don't necessarily know much about code, and want to add stats to their profile. I don't think directly downloading github-stats helps them, because they will still need a repo with a daily Actions workflow to generate and commit their stats. Instructing them to create all that from scratch seems harder than instructing them to make a copy of this.
I would like to make this as easy to set up as possible, but it's not clear to me how the proposed change helps the majority of users. For users who already have their own workflow, it should be pretty clear that they can just pull in the pre-compiled binary and run it. I can maybe add specific instructions for this, but I don't see how it would replace the main set of instructions.
To be honest, I don’t quite understand what exactly you’re trying to achieve by building images from the tip of the master branch. It seems this could lead to unstable behavior in case of changes. Instead, you could use the version jstrieb/github-stats@2 or a hash to specify the exact commit for the changes.
As weird as it may seem, I still think of this repo primarily as a solution to my own problem, but one that just happens to be modestly popular. So when I push a change, I have already tested it locally and usually just want it to immediately take effect for my own stats.
That could lead to unstable behavior I guess, but I'm not really thinking of the project in those terms. Also I try to make sure stuff works before pushing. And changes don't automatically propagate to users, so if something breaks, it only affects new users between when it breaks and when I fix it. That's not ideal, but is acceptable for me given how little time and thought I spend on this project.
As weird as it may seem, I still think of this repo primarily as a solution to my own problem, but one that just happens to be modestly popular. So when I push a change, I have already tested it locally and usually just want it to immediately take effect for my own stats.
Okay, here’s an example of what I think will be one of the most popular use cases: as a developer, I want to add stats to my profile. Here’s what I want to do
In my repository, I add the corresponding action (jstrieb/github-stats@2)
I create a GitHub Token
I configure the parameters needed to run the action
(access_token:excluded_repos: etc.)
We mark the original repo with a ⭐️))
Bonus
We’ll get Dependabot support to keep everything up to date
That’s it—the action runs and generates images in the profile repository.
Instead, here’s how it works now
Create a fork of the repository
Configure the action
Configure the branch and image output
As a result, we end up with +1 repository that doesn’t actually serve any useful purpose,
and the generated profile images are stored in a different repository, which is a bit confusing. If the API becomes outdated or there are other changes related to image generation, you have to manually check and update the repository (update the fork, update the action version, etc.).
Therefore, I added examples that allow downloading or directly building github-stats to generate images without creating a repo; there are two examples of GitHub Action YAML in my pr.
This allows for the needs of both groups to be met simultaneously: it doesn't affect authors' need for the latest code to build and generate images, while also allowing others to generate images directly without creating a repository.
This simply involves updating README.md and adding some examples.
Activity
jstrieb commentedon Apr 21, 2026
Hi! It would be easy to modify the Actions workflow to do this. If you'd like to do it on your copy, I'm happy to help you get it set up.
I don't this on my version for a specific reason: the releases only rebuild when a new version tag is pushed to Git. As a result, the compiled binaries lag a bit behind the latest
mastercommit, but I want the images to be built off of the tip ofmaster.To make this change, you could drop the Zig install step, and replace the
zig build --releasepart of the workflow with something like this:mkdir -p zig-out/bin curl \ --location \ --output 'zig-out/bin/github-stats' \ 'https://github.com/jstrieb/github-stats/releases/latest/download/github-stats_x86_64-linux' sudo chmod +x zig-out/bin/github-statsmaks-oleksyuk commentedon Apr 21, 2026
+1 to that—it would be much easier to be able to run this as an action without creating a copy of the repository. That would greatly simplify the process of deploying this rop, as well as receiving changes and updates.
@jstrieb To be honest, I don’t quite understand what exactly you’re trying to achieve by building images from the tip of the master branch. It seems this could lead to unstable behavior in case of changes. Instead, you could use the version
jstrieb/github-stats@2or a hash to specify the exact commit for the changes.Sestunnwed commentedon Apr 22, 2026
Can add a PR related to the following.
This way they don't need to copy a copy of the code/repo.
jstrieb commentedon Apr 22, 2026
The Actions workflow that runs needs to live somewhere, and the generated images also need to live somewhere. If a user already has another Actions workflow that runs daily, they might want to pull in a pre-compiled
github-statsbinary, and thereby avoid copying this repo. But I doubt that describes most of the users.The detailed README instructions are targeted towards people who have a freshly-made GitHub account, don't necessarily know much about code, and want to add stats to their profile. I don't think directly downloading
github-statshelps them, because they will still need a repo with a daily Actions workflow to generate and commit their stats. Instructing them to create all that from scratch seems harder than instructing them to make a copy of this.I would like to make this as easy to set up as possible, but it's not clear to me how the proposed change helps the majority of users. For users who already have their own workflow, it should be pretty clear that they can just pull in the pre-compiled binary and run it. I can maybe add specific instructions for this, but I don't see how it would replace the main set of instructions.
Am I missing something?
jstrieb commentedon Apr 22, 2026
As weird as it may seem, I still think of this repo primarily as a solution to my own problem, but one that just happens to be modestly popular. So when I push a change, I have already tested it locally and usually just want it to immediately take effect for my own stats.
That could lead to unstable behavior I guess, but I'm not really thinking of the project in those terms. Also I try to make sure stuff works before pushing. And changes don't automatically propagate to users, so if something breaks, it only affects new users between when it breaks and when I fix it. That's not ideal, but is acceptable for me given how little time and thought I spend on this project.
Sestunnwed commentedon Apr 22, 2026
I think you have a point. Detailed documentation is more beneficial to users. Could I try writing the documentation?
maks-oleksyuk commentedon Apr 22, 2026
I’ve already tried implementing an action for this before, and it worked well and was much more convenient than having a separate repository.
https://github.com/maks-oleksyuk/github-stats/blob/action/action.yml
Maybe we should try creating this as an action with tag support and see how it works; if everyone is satisfied with it, that would be great.
jstrieb commentedon Apr 22, 2026
@maks-oleksyuk I already knew what you meant, but I still don't understand the situation where it is useful. Can you please explain the use case?
maks-oleksyuk commentedon Apr 22, 2026
Okay, here’s an example of what I think will be one of the most popular use cases: as a developer, I want to add stats to my profile. Here’s what I want to do
jstrieb/github-stats@2)(
access_token:excluded_repos:etc.)Bonus
We’ll get Dependabot support to keep everything up to date
That’s it—the action runs and generates images in the profile repository.
Instead, here’s how it works now
As a result, we end up with +1 repository that doesn’t actually serve any useful purpose,
and the generated profile images are stored in a different repository, which is a bit confusing. If the API becomes outdated or there are other changes related to image generation, you have to manually check and update the repository (update the fork, update the action version, etc.).
Here are some examples that already use the action:
https://github.com/lowlighter/metrics
https://github.com/Platane/snk
https://github.com/cyprieng/github-breakout
This package really does provide great cards with statistics, and it would be great to see this as an action
Sestunnwed commentedon Apr 22, 2026
Therefore, I added examples that allow downloading or directly building
github-statsto generate images without creating a repo; there are two examples of GitHub Action YAML in my pr.This allows for the needs of both groups to be met simultaneously: it doesn't affect authors' need for the latest code to build and generate images, while also allowing others to generate images directly without creating a repository.
This simply involves updating
README.mdand adding some examples.