Implement Page Deletion Based on 'ToBeDeleted' Label

[Miker91]

This PR introduces a new feature that allows for automatic deletion of pages based on the presence of a 'ToBeDeleted' label.

Changes include:

1. Added a check for the 'ToBeDeleted' label in the metadata of a page.
2. If the label is present, the page is deleted using the DeletePage API call.
3. A fatal log message is generated upon successful deletion of the page.
4. This feature helps in automating the cleanup of pages that are no longer needed, based on the 'ToBeDeleted' label.

How to Test:

1. Apply the 'ToBeDeleted' label to any page.
2. Run the program.
3. The page with the 'ToBeDeleted' label should be deleted and a log message indicating the deletion should be generated.

Any suggestions, improvements are more than welcome since I have 0 experience with GO.

[mrueg]

How would this workflow look like? Is there a way you would add the label automatically?

Couple of thoughts on how it is right now:

• Use a prefix for the label, e.g. mark:ToBeDeleted
• Enable it via a config flag only --delete-pages, so folks don't accidentally delete pages.

[Miker91]

Sometimes people want to get rid of the confluence page managed by Mark.
This works just like any other label in the readme:
Adding
<!-- Label: ToBeDeleted -->
will cause the confluence page to be deleted.
Ewentually, when
<!-- Label: ToBeDeleted -->
is removed from Readme, page will be recreated.

[mrueg]

I see, I personally think mark should publish what is inside a given repository (I think synchronizing will be hard).

We could think of providing the option of a deletion-file. This could be a simple CSV file with the space and title of a page), that mark would use to delete old pages.

With the current implementation, if there's a page in your repository with that label, that means on every run of mark it would create the page just to delete it later again?

[c-p-b]

@mrueg

Would a simple --delete mode or flag or other workflow path be significantly outside of the scope of mark's design and intention? The way we use mark is by locking Confluence down and designating the git repository as the ultimate source of truth, so a way to purge all Confluence pages that exist in Confluence but not in git would be a great feature.

If something like that sounds sensible and aligned with what mark is intended to do, I would be happy to take a stab at an approach that might do something like that.

[c-p-b]

So absent of a path forward in mark for this we implemented a simple idempotency script that wraps mark to force it to match the state of what is checked into the repository. What we do is run some python that essentially reconstructs the hierarchy that mark creates, by parsing the markdown, and delete any pages that are present in confluence but missing from github.

• So we run that Python first, that purges anything before the sync that is present in confluence but missing in github
• Then we run the sync, just a normal mark invocation
• Then we run the same Python again, as the sync may have created orphans itself in the process.

So far have been running said script with no issues with state drift/discrepancy for several months now. We accomplished this in ~150 lines of python. A large portion of that was essentially imitating the hierarchy that mark builds - probably if it was embedded within mark where all of that hierarchy and context is already present such a thing could be implemented in significantly less lines of code and in a performant fashion.

[Jikodis]

@c-p-b , I like the idea of a --delete mode flag. One of my ideas was to NOT use the --changes-only flag. In essence, any file with a timestamp older than the recent mark invocation would be considered stale and could be deleted.

Something like this might be my number one request for this repo.