experiment with less resource wasting

[maelle]

Fix #135

@krlmlr I have been thinking about wasting resources cf https://www.ryanfiller.com/blog/why-my-blog-stopped-using-deploy-previews

With this workflow, to get a preview one adds the "needs-preview" label. I'd like to merge this to then try again as currently I think the PR workflow from master applies? I see the label workflow works but I am not sure it posts the URL as commit status.

[maelle]

Ah I think it now really works (the regex in the pkgdown workflow was catching this branch 😅 )

[maelle]

@krlmlr I'm hoping it'd also work for forks.

[krlmlr]

Can we deploy automatically, but only if the documentation changes?

We're still running a huge build matrix...

[maelle]

Can we deploy automatically, but only if the documentation changes?

Do you mean pre-pkgdown building or do you mean post-pkgdown building? It's unclear to me where we'd store information on what the last deploy website and source were. 🤔

With this change we'd manually decide whether to label the PR as needs-preview so I assume less often than at each commit.

[krlmlr]

We'd assume that gh-pages contains the last deployed website, and deploy to Netlify only if the current state has changes? Of course this requires stable pkgdown builds, which isn't always given.

Let's put this on the backburner for now.

[krlmlr]

The biggest waste is running the big check matrix, I'm mitigating this by only doing this for contributed PRs. Might consider switching to weekly checks (instead of daily) for all packages too.

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This PR was closed without merging. If you still want to merge this PR, re-open it.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.