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
We could establish a convention that only branches beginning with iss trigger the deployment of a branch version of the site. This would avoid clutter in the branch versions directory, especially from branches that don't actually update the site content and only change configuration or documentation.
Consequently, any changes beyond the most minor updates to the site, such as fixing spelling mistakes, should have their own issue and branch.
The text was updated successfully, but these errors were encountered:
An alternative would be to create the directory v/iss{ISSUE_NUMBER} while taking the ISSUE_NUMBER automatically from the CI, instead of relying on the branch name. But since we do not known the issue number while being in a PullRequest/Branch, maybe the best automatic choice would be: take the PullRequest number. I can fairly well imagine that sometimes, a single PullRequest may answer to closely related Issues (though it is not strictly following a Git workflow). If things are well done, the PullRequest is referring to the/all related GitHub Issues.
JeremyMcCormick
changed the title
Only build preview site for 'iss' branches
Only build preview site for iss branches
May 23, 2024
An alternative would be to create the directory v/iss{ISSUE_NUMBER} while taking the ISSUE_NUMBER automatically from the CI, instead of relying on the branch name. But since we do not known the issue number while being in a PullRequest/Branch, maybe the best automatic choice would be: take the PullRequest number. I can fairly well imagine that sometimes, a single PullRequest may answer to closely related Issues (though it is not strictly following a Git workflow). If things are well done, the PullRequest is referring to the/all related GitHub Issues.
It seems more natural to connect the branch versions to issues in the tracker. If a PR resolves multiple issues, it should just use one of them.
I really prefer though that issues are scoped in a way that would typically connect them to a single PR, aside from small patches and fixes. Having a PR that resolves multiple issues shouldn't be the typical pattern and I would discourage it.
Plus the idea here is that some PRs for small fixes/patches don't need a site version built. So we have to filter on some part of the branch name to do this automatically.
We could establish a convention that only branches beginning with
iss
trigger the deployment of a branch version of the site. This would avoid clutter in the branch versions directory, especially from branches that don't actually update the site content and only change configuration or documentation.Consequently, any changes beyond the most minor updates to the site, such as fixing spelling mistakes, should have their own issue and branch.
The text was updated successfully, but these errors were encountered: