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

Scheduled builds #24351

Closed
sftim opened this issue Oct 3, 2020 · 16 comments
Closed

Scheduled builds #24351

sftim opened this issue Oct 3, 2020 · 16 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@sftim
Copy link
Contributor

sftim commented Oct 3, 2020

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

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 3, 2020
@sftim
Copy link
Contributor Author

sftim commented Oct 3, 2020

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

@onlydole
Copy link
Member

onlydole commented Oct 3, 2020

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
Copy link
Contributor Author

sftim commented Oct 3, 2020

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
Copy link
Member

irvifa commented Oct 3, 2020

I’m in favor of using this as well.

@kbhawkey
Copy link
Contributor

kbhawkey commented Oct 5, 2020

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
Copy link
Contributor Author

sftim commented Oct 31, 2020

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
Copy link
Contributor Author

sftim commented Oct 31, 2020

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
Copy link
Contributor Author

sftim commented Oct 31, 2020

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
Copy link
Contributor Author

sftim commented Oct 31, 2020

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
Copy link
Contributor Author

sftim commented Oct 31, 2020

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

@k8s-ci-robot k8s-ci-robot added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Oct 31, 2020
@k8s-ci-robot

This comment has been minimized.

@sftim
Copy link
Contributor Author

sftim commented Oct 31, 2020

/triage accepted

@k8s-ci-robot k8s-ci-robot added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Oct 31, 2020
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 29, 2021
@kbhawkey
Copy link
Contributor

@sftim, Is there more work to do?

@sftim
Copy link
Contributor Author

sftim commented Jan 30, 2021

This is done
/close

@k8s-ci-robot
Copy link
Contributor

@sftim: Closing this issue.

In response to this:

This is done
/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

6 participants