search

ivoa / ivoa-web

ivoa.net website static web pages
Creative Commons Attribution Share Alike 4.0 International
2 stars 2 forks source link

Only build preview site for `iss` branches #56

Open JeremyMcCormick opened 1 month ago

JeremyMcCormick commented 1 month ago

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.

gmantele commented 1 month ago

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 commented 1 month ago

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.