You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We want Nickel documentation to be on the website, for both major releases and for current Nickel master. The Nickel documentation lives in the https://github.com/tweag/nickel repo. They happen asynchronously to updates in this repo. We can trigger a new deploy to production manually, but that's work. So we can automate this instead.
Describe the solution you'd like
Make the current production deploy workflow be triggered on a nightly schedule, not just by pull requests.
Replace the current submodule pointer to Nickel with flakes. Tell flakes to checkout the tip of each release branch and the tip of master. Build against whatever is the latest from each of these branches (see below regarding reproducibility).
Describe alternatives you've considered
An alternative is to record the tips of the release+master branches in the Git history at each deploy. However, if deploys happen on at least a nightly schedule, then the vast majority of the history in Git will be about that, because we don't update the website assets that often. I'd argue that the history of updates is not useful information. And we don't need the Git history to reproduce exactly a specific deploy.
Is your feature request related to a problem? Please describe.
We want Nickel documentation to be on the website, for both major releases and for current Nickel
master
. The Nickel documentation lives in the https://github.com/tweag/nickel repo. They happen asynchronously to updates in this repo. We can trigger a new deploy to production manually, but that's work. So we can automate this instead.Describe the solution you'd like
master
. Build against whatever is the latest from each of these branches (see below regarding reproducibility).Describe alternatives you've considered
An alternative is to record the tips of the release+master branches in the Git history at each deploy. However, if deploys happen on at least a nightly schedule, then the vast majority of the history in Git will be about that, because we don't update the website assets that often. I'd argue that the history of updates is not useful information. And we don't need the Git history to reproduce exactly a specific deploy.
cc @garbas. Original discussion: #5 (review).
Blocked on #7.
The text was updated successfully, but these errors were encountered: