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

Automate attic maintenance #1225

Closed
guusdk opened this issue Oct 13, 2022 · 4 comments
Closed

Automate attic maintenance #1225

guusdk opened this issue Oct 13, 2022 · 4 comments
Labels
Editor Tooling Issue relates to process/tooling

Comments

@guusdk
Copy link
Contributor

guusdk commented Oct 13, 2022

Ensuring versions showing up in the attic is a manual process, which should be automated. There should be some automation which detects addition of a <revision> block, tags the commit, builds the thing and pushes it into the attic.

For the point above to work correctly, it is required that a revision block is only ever added after all changes belonging to that revision. Hence, it must be enforced that a PR does not change a document in any commit after the one adding a revision block.

@Echolon
Copy link
Member

Echolon commented Oct 25, 2022

Thank you Georg for the support!

  • Estimated workload: 30 h
  • Assumption: Knowledge of Github Automation

@Echolon
Copy link
Member

Echolon commented Oct 25, 2022

Some further input from Jonas:

attic maintenance + email notification both have a core issue, which is that
they need to keep state somewhere. Once the state-keeping is resolved, the
implementation is quite trivial, because tooling does exist for both archiving
stuff to the attic (maybe it needs like 5 lines of extra bash to automate the
commit, pulling and modifying a quote from Edgar Allan Poe's The Raven and
pushing, but that's about it)
.
This state-keeping would then also be extremely helpful for automating the
publication of new documents
; with the current process of building without
keeping state, we have to expect to pay significant CI fees soon, because
we're building not only HTML but also PDF versions from scratch every time, a
task which takes about 10-15 minutes on my 8-core machine when it does nothing
else.
On the other hand, there is not much, if any, tooling for XEP-0001 conformance
checking. Hence a person would have to first understand XEP-0001 and the
implications and then implement a tool to check that and provide useful
feedback to the PR author. I.e. there's much more work to do here than for the
other three tasks I mentioned so far
, especially if one makes use of the
synergies between them.

@mwild1 mwild1 added the Editor Tooling Issue relates to process/tooling label Nov 4, 2022
@Kev
Copy link
Member

Kev commented Nov 4, 2022

Just leaving further information from Jonas in xsf@. It needs it to do a diff of the old and new git master (which means keeping the state of the last master) and do calculations based on that.

( I proposed an approach:

foreach xep in *.xml:
   extract ver
   if not check attic for ver:
     git tag
     copy to attic
     commit attic
     push to attic and xeps.git

that doesn't use Git diffs, so isn't what's needed)

@horazont
Copy link
Contributor

horazont commented Nov 5, 2022

Closed in favour of #1236 and #1241, which should make for more clearer work packages. Re-open if you disagree.

@horazont horazont closed this as not planned Won't fix, can't repro, duplicate, stale Nov 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Editor Tooling Issue relates to process/tooling
Projects
None yet
Development

No branches or pull requests

5 participants