-
Notifications
You must be signed in to change notification settings - Fork 629
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package as an action/separate codebase from generated images #6
Comments
Thanks for the comments/insights! I definitely agree that the current setup is clunky, and that it should be adjusted. You've helpfully put forward one good option for how to clean things up. Some other things I was considering, but have not fully explored:
To anecdotally verify your point that the setup process is not ideal: I can see in my feed when users fork the repository, and I can easily check back several hours later to see whether they have completed the setup process. I don't have exact numbers for the success rates, but definitely less than 100% fully set the project up within a few hours after forking. I'm currently an undergrad in the midst of a chaotic semester, so this and other projects have unfortunately been on the back-burner. However, I do intend to clean the project up eventually since as of this reply the project is one of the top results on DuckDuckGo for "GitHub statistics" and "GitHub stats," which means there is a fairly steady stream of new users that try and follow the laborious setup process with varying degrees of success. I'll probably leave this issue open for discussion until I get around to settling on how to make the process better. On an unrelated note, thanks for your work on shields.io! |
As a minor update to this: I attempted to set up storing generated statistics image assets as "releases" instead of pushing them directly into the repository. I got it working, except GitHub returns SVG assets with MIME type I speculate that the justification for this is that SVG can execute scripts and have arbitrary inline HTML, and GitHub probably doesn't want to host XSS material on their primary At the moment, this means that storing images as "releases" is a no-go if they are to remain as SVGs. It is theoretically possible to convert the vector images to PNG or JPG images within the main action, but I would rather continue committing them to the main repository than be restricted to bitmap images. I have edited my previous comment on this issue to reflect that using releases seems to be a dead-end. |
For reference, see the attempted commit. If there is a known workaround to get GitHub to send the correct MIME type for releases assets that I'm not aware of, incorporating it would probably be the preferable solution to this problem. |
A short-term fix for this I am considering is turning this repository into a "template." (See this feature announcement.) This would fix the issue of users getting my commit history, and possibly make it easier to run the action (though they would still need to add an On the other hand, this may make it harder for users to see when I have made a meaningful update, patch, or fix to the main stats image generation code. |
The repo became a template to make the installation process easier. See issue #6.
dear @jstrieb, thank you for this amazing project. Have you considered to publish the generated images through github pages? you could do it directly in github workflow and with a proper action you could keep only the new images in a different branch like
I could submit you a PR if you like this solution |
Hi @bunop! I thought I replied to your comment days ago, but I guess it slipped through the cracks – sorry! Serving images through GitHub pages is a really interesting idea that I hadn't considered before. I am concerned that it if implemented, it would add steps to an already unwieldy setup process. I also don't totally know how it would differ from images being generated, committed to a branch, and served via the That being said, I really like your idea of committing to a separate branch as a way to reduce clutter in the commit history – the fact that code and data are kept all in one place is definitely not ideal. I am going to think more about committing to a branch, and will possibly run an experimental version in a private fork to see if there are any unintended side-effects of doing it that way. Thanks for taking the time to share your ideas! I'll be sure to respond here if there are any developments. |
I recently discovered (in another repository) that GitHub Actions workflows are disabled automatically if repositories are considered "inactive." This leads to an unintended benefit of pushing stats images to the repository: the repo is kept "active" indefinitely, and the Action will not be automatically shut off. For reference, consider the warning here that reads:
|
At the moment this project has potential, but the suggested install process is a bit clunky because when I fork it, the code comes with your generated images. As soon as a user starts generating their own images and the histories diverge, it then it becomes potentially fiddly to pull in any changes or bugfixes from upstream into the forks.
If the action code were decoupled from your generated image history in a separate repo with an
action.yml
the "install" process for a new user could be more like: Create an empty repo and create a workflow:which would be much slicker as each user repo would only contain the user's own image history.
The text was updated successfully, but these errors were encountered: