Squash commits made by the workflow

[ranile]

The workflow makes a new commit every x amount of time. It would be better if the workflow amended the previous commit or made a new commit and squashed it with the previous one. This way the commits won't pile up, cluttering up the commit history the repo.

[Zenoo]

I'm not sure this would be beneficial.
Changing the git history is never a good idea in my opinion.
The git history is here to track changes on a repo, here, there are indeed changes, that should be tracked like anything else.
Plus, if you commit something else in your repo in between two metrics commits, this could have bad repercussions.

[ranile]

I don't think giving an option would be bad though. I personally don't like having same commits (consecutive metrics commits, in this case) over and over again.
In case there are commits between two metrics commits, we can just make a new one and not do anything else.

[spenserblack]

Another possible repercussion of squashing the merges is that I think GPG signatures will be lost on any commit that needs to be rebased due to having a new parent. This is something you might want to consider if you want your commits to be verified.

---

While I agree in theory that changing git history isn't a good idea, especially if it's a scheduled task changing history, I think the danger wouldn't be severe if metrics is committing to a separate branch, not master or main.

For example, it's not uncommon to rewrite the history on the gh-pages branch (it's even part of Vue's documentation).

[lowlighter]

I agree with @Zenoo, git history rewriting can be dangerous, especially if it's automated. In addition I'm not sure whether it's possible to amend commits directly through GitHub API.

However, maybe you can use one of the below workaround to achieve something that look like what to you want though:

1 Use GitHub gist instead

If you create a gist, you can ask the action to push renders to it instead, and use its image urls in place of repository assets.
There's still a concept of history in gists, but it's less visible that on git repositories.

- uses: lowlighter/metrics@main
  with:
    output_action: gist
    committer_gist: #gist id#

2 Manually handle commits

I haven't tested this solution, but in theory it should work.

If output_action is set to none, renders files should be available on the worker in /rendered or /metrics_renders (I don't remember which one it is). You could then make the workflow checkout on your repository, move renders in it and finally git add them and git amend.

- uses: lowlighter/metrics@main
  with:
    output_action: none

- uses: actions/checkout@v2
  with:
    fetch-depth: 0

- run: |
    mv /rendered/* .
    git add .
    git commit --amend -m "Update metrics"
    git push

[spenserblack]

Just a slight change, I think the last git push would have to be git push -f.

[ranile]

The option 1 works and is nice. Thanks

[TheNetAdmin]

How about publishing metrics svg files as release artifacts? This approach does not mess up the git history, nor brining any binary file into the repo.

[Nixinova]

My method is to shove the SVG onto a separate branch of the profile readme to avoid cluttering anything. Then you keep the history without it affecting the main branch.

[spenserblack]

This is a good approach IMO 👍 Just started doing it, too, based on this suggestion.
One addition: the separate branch can be an orphan branch (it looks like @Nixinova did this, just thought I'd clarify). That way, just like your main branch doesn't get cluttered, your metrics branch doesn't get cluttered by the history of your main branch.
This should do it

git clone <your repo> github-profile
cd github-profile
git checkout --orphan=metrics
git reset # Creating an orphan will add the existing files to be tracked in the orphan by default, so we un-track them
git commit --allow-empty -m "Init metrics branch" # If all goes well, this will be an empty commit. The purpose is to initialize the branch
git push -u origin metrics

And then in your workflow file

- uses: lowlighter/metrics@<commit-ish>
  with:
    # other options
    committer_branch: metrics

---

Edit:
I also deleted the metrics.svg commit history from my main branch with

git rebase -i --root

Then, editing the rebase todo in vim, :g/Update metrics/d, which deleted all commits from the rebase todo with the message matching the regex Update metrics. The end result is that the rebase removed all old metrics.svg commits.
Use with caution! Editing the history in this way can lead to unexpected results. I'm leaving these rebase instructions here as an example of what can be done, not necessarily as a recommendation.

[jayvdb]

Another approach to this "problem" is to reduce the number of commits by not updating the "Last updated" timestamp unless there is an update to the data.

i.e. I see little value in doing a commit which only changes the "Last updated" timestamp in the result, e.g. jayvdb/jayvdb@e3217bb

I would actually prefer that the "Last updated" timestamp reflect when the data/stats changed, rather than when the latest render was performed.

The tool could detect this and exit before writing the new output.

Alternatively there might be a CI recipe which inserts a step before the metrics step, which first checks if there was a change to the data - this seems less likely to be useful for everyone, esp when there are plugins which pull data from other systems, or include stats which change despite the user being inactive. I suspect it isnt too hard to build a very simple step to check if the user has done anything since the last run, and use that to bale out early.

[lowlighter]

Another approach to this "problem" is to reduce the number of commits by not updating the "Last updated" timestamp unless there is an update to the data.
The tool could detect this and exit before writing the new output.

This is a good idea 👍
Will track implementation in #599