Scheduled builds

[sftim]

This is a Feature Request

What would you like to be added
Trigger a site build via the Netlify API every n hours

Why is this needed
Scheduled builds enable other features, including:

• Automatic updates using data from external sources (eg release information)
• Future-dated blog articles that publish automatically

Comments
Based on an idea mentioned in kubernetes/contributor-site#160 (which suggested triggering a build using a GitHub Action)
/kind feature

[sftim]

@kbhawkey @onlydole I would welcome your thoughts on this and whether we should prioritize it / deprioritize it.

[onlydole]

I'm in favor of this, both in creating and prioritizing. I see a lot of value in using this for link checking or other similar tooling.

[sftim]

Another thing scheduled builds ties into well: a shortcode to fetch from other repos (a bit like a Git submodule, but fetched at render time and tied specifically to GitHub).
See kubernetes/contributor-site#93 (comment) for an example.

[irvifa]

I’m in favor of using this as well.

[kbhawkey]

Hi. Some things to think about:

• How would these periodic jobs be scheduled with/into the existing workflow?
• Do you want a way to trigger a new PR/update content when the release repo/site publishes updated information (patch updates)?
• Can you explain what you mean about Future-dated blog articles that publish automatically? How would this work?
• Creating a periodic job to check the site's links seems to be a different type of job. The site's content is not updated.
  The job could run occasionally and report the results from running the current link checker. This seems lower priority because the link checker can be run locally and authors can update the content. There is no need to wait for a report or reminder of link problems.

[sftim]

How would these periodic jobs be scheduled with/into the existing workflow?

After adding periodic triggers, either of the following would trigger deploying https://kubernetes.io/

• a push to master
• a timer

[sftim]

Do you want a way to trigger a new PR/update content when the release repo/site publishes updated information (patch updates)?

That sounds like a different feature. Scheduled builds would reduce the window between a depended-on artifact changing and that being reflected on the live Kubernetes websites.

[sftim]

Creating a periodic job to check the site's links seems to be a different type of job. The site's content is not updated.
The job could run occasionally and report the results from running the current link checker. This seems lower priority because the link checker can be run locally and authors can update the content. There is no need to wait for a report or reminder of link problems.

Yes, it's not as valuable as the blog publishing or the automatic updating based on external sources.

[sftim]

https://k8s.dev/ is an example of a site that publishes blog articles automatically.
There are 3 steps.

1. Someone submits a PR that adds a blog article. The blog article is future-dated. The preview includes the blog article.
2. Someone else merges the PR. https://k8s.dev/ rebuilds. The live site does not yet include the blog article.
3. Eventually, the article due date passes. The next time that the timer GitHub Action for https://k8s.dev/ triggers a rebuild, the blog article goes live. Now, the live site includes the new blog article.

[sftim]

Based on #24351 (comment)
/triage accepted
/priority important-longterm

[k8s-ci-robot]

@sftim: The label(s) triage/accepts cannot be applied, because the repository doesn't have them

Details

In response to this:

Based on #24351 (comment)
/triage accepts
/priority important-longterm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sftim]

/triage accepted