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

Support Deleting Tweets #208

Open
IstoraMandiri opened this issue Sep 24, 2022 · 15 comments
Open

Support Deleting Tweets #208

IstoraMandiri opened this issue Sep 24, 2022 · 15 comments
Labels
feature New feature or request

Comments

@IstoraMandiri
Copy link
Contributor

What’s missing?

The ability to delete existing tweets.

Why?

Currently the only way to delete a published tweet is for the owner of the account to remove it.

If a twitter account is maintained primarily by a twitter-together repo, there should be a way to delete tweets from this repo, in case there's a mistake or a retraction needed.

How?

To maintain a record of deletions, perhaps a field to flag .tweet files with deleted: true, or deleted: [tweet url].

@gr2m
Copy link
Contributor

gr2m commented Sep 26, 2022

I feel this falls outside of the scope of this action. But I'm happy to leave the issue open and to see if there is broader interest. Personally, I didn't run into the need to delete a tweet once. And if it came to it, I'd login into the account directly and delete it, instead of using the action.

@MattIPv4
Copy link
Member

My concern here would be less with scope, but more with a conventional way to represent this. What feels conventional would be that the action detects a .tweet file being deleted, but .tweet files don't keep track of the tweet they produced.

@IstoraMandiri
Copy link
Contributor Author

IstoraMandiri commented Oct 2, 2022

One way to implement this is to include a new delete option in FrontMatter. Instead of modifying an existing .tweet, contributors would just add a new .tweet with just following content.

---
delete: https://twitter.com/xxx 
---

This both preserves history and means the action can hook into the same "git added a file" trigger without having to look for updates to existing tweets each time the action runs.

Users can come up with their own naming schemes such as:

221004-[delete]-my-tweet.tweet
221004-my-tweet.tweet
221005-hello.tweet

or

hello.tweet
my-tweet.tweet
my-tweet-delete.tweet

@MattIPv4
Copy link
Member

MattIPv4 commented Oct 2, 2022

I agree that adding a frontmatter property to delete tweets would work, but I fear this does not feel like the canonical solution in the land of git, where files are versioned controlled. As an end user, my default would be to expect to be able to delete a tweet file, and it'd delete the tweet.

@IstoraMandiri
Copy link
Contributor Author

If the action relied only deleting the file, how would it know which tweet to delete, given there is no reference to a Tweet ID?

@MattIPv4
Copy link
Member

MattIPv4 commented Oct 2, 2022

Yes, that was the exact dilemma I posed 4 comments above.

@IstoraMandiri
Copy link
Contributor Author

I don't see the dilemma; if the canonical git land solution just isn't possible, shouldn't it be ruled out?

@MattIPv4
Copy link
Member

MattIPv4 commented Oct 2, 2022

I never said it wasn't possible, and I don't think it is impossible. There are ways in which one could track the associated tweet ID with a tweet file.

@IstoraMandiri
Copy link
Contributor Author

In what ways might it be tracked?

@MattIPv4
Copy link
Member

MattIPv4 commented Oct 2, 2022

You could lean on artifacts to store tweet IDs (though there'd be a theoretical 90 day limit if there were no activity), or the action could push through a follow-up commit that associates the ID once tweeted.

@IstoraMandiri
Copy link
Contributor Author

IstoraMandiri commented Oct 2, 2022

... or the action could push through a follow-up commit that associates the ID once tweeted.

This makes a lot of sense, and would also help keep track of published tweets.

Something like adding a comment or additional field to the .tweet's Front Matter?

Or, probably less ideally, stored in some kind of separate key-value store?

@MattIPv4
Copy link
Member

MattIPv4 commented Oct 2, 2022

Yah, I would envision this probably just pushing a new id property into the .tweet file frontmatter once published (or storing kv data via artifacts, but this seems problematic due to the retention etc.)

@IstoraMandiri
Copy link
Contributor Author

A couple of considerations with this approach though.

Can actions publish directly to a protected branch, or would this additional commit need to go through review itself?

How can a deletion be re-triggered if something goes wrong on the github action side or twitter glitches out during the action, since the file is already deleted?

@MattIPv4
Copy link
Member

MattIPv4 commented Oct 2, 2022

Can actions publish directly to a protected branch, or would this additional commit need to go through review itself?

Having read through https://github.com/orgs/community/discussions/25305, it looks like Actions cannot be configured to bypass branch protection, which sucks.

I think the closest we'd be able to get is the action opening a PR to add the ID in once the tweet has been sent, and a human could then merge that as they see fit (though we could probably add a setting to allow direct pushing for folks that aren't using branch protection rules).

How can a deletion be re-triggered if something goes wrong on the github action side or twitter glitches out during the action, since the file is already deleted?

Re-running the action run.

@IstoraMandiri
Copy link
Contributor Author

IstoraMandiri commented Oct 2, 2022

I think the closest we'd be able to get is the action opening a PR to add the ID in once the tweet has been sent, and a human could then merge that as they see fit (though we could probably add a setting to allow direct pushing for folks that aren't using branch protection rules).

While possible, this is less than perfect from a maintenance POV, especially if more than one approval is required.

In any case, for audibility, I can imagine that many projects may want to retain a clear history of which tweets have been made in the past, even if deleted, just by glancing at the directory structure rather than the whole git commit history. Seemingly this cannot be achieved with a pure canonical git approach.

Another potentially easier to implement and use solution, that mimics a familiar pattern, is to have a trash or deleted-tweets folder. In a single commit, users could move tweets they want to delete into this folder, by doing so gets picked up by the action, which can then read the id field, which was added in the same commit to tell the action which tweet to delete. The tweets folder remains in sync, and the trash folder keeps a record of deleted tweets.

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

No branches or pull requests

3 participants