dvc.org: `merge-schedule` gh action can't merge to master

@julieg18 done:

Write should be enough if PR is approved by at least 1 person

~Could exclude admins from the merge protection, and use an admin account GITHUB_TOKEN in the action?~

Could use a bot account GITHUB_TOKEN in the action to do the merge?

Should work if e.g. giving the bot (@iterative-olivaw) ~admin~ write permissions on this repo.

Some links I’ve found regarding future posts in Gatsby:

• https://dilshankelsen.com/create-future-blog-posts-in-gatsby/
• https://www.raresportan.com/how-to-handle-future-posts-in-gatsby/
• https://stevenmercatante.com/publish-posts-after-date-in-gatsby
• https://www.jerriepelser.com/blog/schedule-posts-gatsby-netlify/
• https://www.npmjs.com/package/gatsby-blog-post-scheduler

Could use a bot account GITHUB_TOKEN in the action to do the merge? Should work if e.g. giving the bot (@iterative-olivaw) admin write permissions on this repo.

That could work! Reopening this issue! Though I only have a role of Maintain on dvc.org. We need a Admin role to give a bot write permissions. @iterative/websites, who has an Admin role?

We can make a ticket for writing a scheduling feature in our blog engine, it’s still something we’ll want even if this implementation isn’t the way we do it.

Some links I’ve found regarding future posts in Gatsby:

As Roger mentioned, hiding posts before the scheduled time should be easily achievable on the Gatsby side, but we need to ensure that the build gets triggered on time.

If we can trigger the Heroku build from GHA, I think simple schedule action that runs daily should be enough. If we are also able to check if there are any scheduled posts on GHA then we can also skip unnecessary builds.

I’m not referring to scheduling PRs, I’m talking about scheduling the display of posts that are merged into the repo before they’re supposed to show up. I think compared to this solution, trying to schedule PR merges is flaky for the reasons you’ve given (among others).

The code logic for scheduling blog posts should actually be pretty easy

Probably not once you take into account all the possible states the PR could be in e.g. unapproved, failing tests, merge conflicts, etc. which are pretty much unpredictable.

The code logic for scheduling blog posts should actually be pretty easy, with the most difficult thing being ensuring the site actually rebuilds when the time comes. Even then, that could be as simple as a GHA cron action that tells our heroku server to rebuild.

Currently, we add the date in the filename like Jekyll (e.g. 2022-03-31-stale-models.md), if I understand correctly that date is the one we’d want to use as a publish date. Even if the functionality isn’t built-in, it shouldn’t be much of a problem to parse and work with this filename date if that’s what we want.

We recently discussed this on a call and @iesahin suggested instead of scheduling merges (fragile) we should consider implementing a feature in the blog engine to hide posts until a certain date (specified in frontmatter). I agree this wound be better since it unlinks publishing from git flow a little.

Agreed that a merge scheduler is probably not the best way to accomplish blog post publishing! And while we could look into some alternative ways using frontmatter, we are planning to move the blog and implement CMS soon… Should we start looking into a way to schedule blog posts with our current blog engine or should we just wait till we are using CMS for our blogs posts?

Seems like the blog is going in a different direction. Is this still relevant @julieg18 ? Thanks

We’re sticking with PR blog posts for now and we do want still blog scheduling but the merge-schedule probably isn’t the best way to do it. I’ll go ahead and close this and we can refer to this issue’s discussion when we get around to looking into Gatsby blog post scheduling.

I did just realize that another hangup in Gatsby-controlled post scheduling would be ensuring that writers can see their posts even if the posts are intended for the future. This also shouldn’t be too difficult to account for, as we can do dev checks in Gatsby node creation without it leaking into our prod code.

We recently discussed this on a call and @iesahin suggested instead of scheduling merges (fragile) we should consider implementing a feature in the blog engine to hide posts until a certain date (specified in frontmatter). I agree this wound be better since it unlinks publishing from git flow a little.