beddalumia / minecraftverse Goto Github PK

At the moment the last game badge actually tracks the last commit on master branch. Which by any means is really the "last game" (updates to README, yaml, .git stuff and all of that...).

Thinking about issue #1 I came to the idea of defining a new branch, exclusively dedicated to gaming commits, which I think would solve the problem.

As for now the octomap is in a hidden folder (at least in ~unix) and displayed in the readme when markdown is rendered (so on the web). So we could pretend that it's not something we intend to keep updated and sensible in the games branch. Nevertheless I think we should address the problem of keeping it updated (together with other changes in readme and all of that), without messing too much the gaming history log. Can we do that?

• Problem: the solution of issues [#1] and [#2] heavy relied on the strong isolation of games branch with respect to the master; if we break that we may be doomed.

• We may consider again the github-artifact route, but that would mean to give up versioning of the octomap; which honestly seems just dumb.

• If we could guarantee the minimum isolation requirement between the two branches, as to be able to fast-forward games to the tip of master we may have a solution. I'm quite pessimistic about that though.

We don't want to get a new commit by repo-visualizer for each commit we do. 'Cause if we mix these commits with actual gaming commits we mess up the gaming log!

Instead we want, either:

• A new repo-visualizer commit only when a mcworld is actually updated (excluding .md and .git* related commits) [subideal, still a lot of commits..]

  • it could be done, approximately, by discriminating pushes from local clones from commits directly done from github [even less ideal]
  • or we can somehow modify the yaml script to check which paths have been changed [seems difficult]
  • or we can manually add some flag to be parsed on the commit logs [too manual, but seems easy]

• Total remotion of automation, just manual-triggering the octomap generation [way too manual!]

• Figure out how to use the github-artifacts to avoid committing regardless of the frequency of the action.

  • note that any concern about storage quotas for artifacts is most probably irrelevant, given the actual sizes of these .svg files! :)