Skip to content
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

Open
chris48s opened this issue Oct 13, 2020 · 8 comments
Open

Package as an action/separate codebase from generated images #6

chris48s opened this issue Oct 13, 2020 · 8 comments

Comments

@chris48s
Copy link

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:

name: Generate Images
on:
  schedule:
    - cron: '0 * * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Generate Images
        uses: jstrieb/github-stats@master
        with:
          ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
          EXCLUDED: ${{ secrets.EXCLUDED }}

which would be much slicker as each user repo would only contain the user's own image history.

@jstrieb
Copy link
Owner

jstrieb commented Oct 21, 2020

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:

  • Storing images as "releases" rather than committing them to the repository – not sure if this would actually be cleaner/better
  • Having a GitHub App that takes care of most of the setup process (including the annoying secret key part that may deter some users)
  • Storing user images in their [user]/[user] repository (e.g. my jstrieb/jstrieb repo)
  • Some combination of the above options

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!

@jstrieb
Copy link
Owner

jstrieb commented Nov 21, 2020

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 application/octet-stream instead of the required image/svg+xml, so using the asset URLs in src attribute of img tags causes the images to not display at all.

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 github.com domain name.

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.

@jstrieb jstrieb pinned this issue Nov 21, 2020
@jstrieb
Copy link
Owner

jstrieb commented Nov 21, 2020

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.

@jstrieb
Copy link
Owner

jstrieb commented Dec 8, 2020

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 ACCESS_TOKEN secret, which is one of the most annoying parts of the setup process in my opinion).

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.

jstrieb added a commit that referenced this issue Dec 13, 2020
The repo became a template to make the installation process easier. See
issue #6.
@bunop
Copy link

bunop commented Feb 9, 2021

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 gh-pages. Moreover, github pages will serve images with the proper MIME type. Take a look to my modifications at bunop/github-stats. Here are the generated images that are placed in gh-pages and that are served by github (I will add them soon to my personal website):

I could submit you a PR if you like this solution

@jstrieb
Copy link
Owner

jstrieb commented Feb 19, 2021

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 raw.githubusercontent.com links that are currently used. Unless I'm missing something, the process is very similar to how it's done now, and serving files via GitHub Pages doesn't remove the need to commit to the repo.

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.

@jstrieb
Copy link
Owner

jstrieb commented Jun 13, 2021

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:

Warning: To prevent unnecessary workflow runs, scheduled workflows may be disabled automatically. When a public repository is forked, scheduled workflows are disabled by default. In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.

@maks-oleksyuk
Copy link

Hi @jstrieb. Great idea to do it as a GitHub Action.
I tried to implement this in my fork. Please review and provide feedback on possible improvements. If everything goes well, I will create a PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants