|Resolved||kai.nissen||T157560 Use GitHub Repository for Fundraising Frontend contents|
|Resolved||gabriel-wmde||T157578 Create branch structure in Content Repo|
|Resolved||Pablo-WMDE||T157575 Create deployment of the content repository|
|Resolved||Pablo-WMDE||T157577 Create webhook to deploy new content|
|Resolved||gabriel-wmde||T164943 Outline needed changes to github-webhook|
|Declined||None||T164945 Extend to wmde/github-webhook to deploy fundraising-frontend-content|
|Declined||None||T164946 Create deployment playbook for wmde/github-webhook|
Created the test branch and protected the master branch.
@Pablo-WMDE Not sure why you changed the description for the master branch from test to master. I think test makes more sense from the perspective of the workflow of the fundraising team: They open the page in Github and see the test branch because it's the default (no need to switch branches). They make direct edits to test. The changes are reflected after some seconds in the test environment, where they can see the result of their work. When they're satisfied, they merge test into master.
Having the master branch as the default means they will accidentally create feature branches and pull requests for master.
What was your thinking behind specifying master as default?
I believe these changes were created together during story time, don't remember the individual arguments, but believe we can agree on the following principles:
- production content should be protected (no direct edits)
- using github as the editing UI, the default branch should point to test, so edits become visible there directly
If we do not insist the traditional VCS/git branch "master" name, we can just call the "branches" like the stages they are used on, "test" and "prod", and let "test" be the default one... (pretty much like the description before the change, but w/o "stage")