Branch protection

[onionhammer]

How does this repository handle branch protection, requiring pull requests, etc from different branches? Everything seems to be geared towards pushing straight to the master branch.

It would be great to see some more configuration added around this to the .pages.yml file, and perhaps bundling up multiple pending page changes into a single commit / PR

[v4iv]

this and ability to reference other collections would turn pages cms into perfection

[hunvreus]

@onionhammer:

• Can you clarify what you mean by branch protection? Providing a specific user story would be helpful for me to wrap my head around what it is that you'd like to be able to do.
• About bundling up commits, I want to support triggering GitHub actions from the interface. This would allow you to work on an edit branch, and when you're ready to publish your changes you could click a "Publish" button that would trigger a GitHub Action which could merge the changes from the edit branch to main (for example). As long as you only use main to build the site, this should work, no?

@v4iv I'm going to add soon the ability to reference other collection entries and files. I'm also planning on letting you support custom autocomplete fields (as long as you can provide a JSON with key/value pairs).

[v4iv]

also a good demo of branch protection is decap cms' editorial workflow https://decapcms.org/docs/editorial-workflows/

[onionhammer]

Can you clarify what you mean by branch protection? Providing a specific user story would be helpful for me to wrap my head around what it is that you'd like to be able to do.

I'm referring to github's branch protection feature, which it will often nag to set up if you dont have it set up; you can
commonly use it to prevent pushes directly to master/main branch and force every change to go through pull requests.

About bundling up commits, I want to support triggering GitHub actions from the interface. This would allow you to work on an edit branch, and when you're ready to publish your changes you could click a "Publish" button that would trigger a GitHub Action which could merge the changes from the edit branch to main (for example). As long as you only use main to build the site, this should work, no?

This is an interesting idea. If you do that each user would have to configure some sort of stock 'publish' workflow. I think for a lot of folks who use github with things like Cloudflare Pages, Vercel, Azure Static WebApps, etc, most will already have automatic workflows that publish any open pull request (sometimes any open branch), so if you tried to create a github action based thing on top of that you might conflict with a lot of folks existing workflows.

Here's a flow that would work there, IMO:

sequenceDiagram

    participant U as User
    participant P as PagesCMS
    participant G as Github

    U->>P: User updates file 1
    P->>G: PagesCMS creates PR to master
    P->>G: PagesCMS tracks the change to PR
    U->>P: User updates file 2
    P->>G: PagesCMS tracks the change to same open PR
    U->>P: User hits 'Merge Changes'
    P->>G: PagesCMS merges PR to master
    G->>G: Github builds and deploys or Vercel or Netlify etc

Loading

[hunvreus]

I get that, but in what context do you see this applying to Pages CMS? You'd like native support of a workflow whereby editors make changes on branch and submit changes to publishing via a PR against main?

[BigBlueHat]

Our company has a "review first" policy typically enforced by branch protection rules. However, PagesCMS currently defaults to the default branch and encourages saving every file change--vs. a publishing flow where changes are collected across several files/media and then published (likely via a PR).

That would need to become the default for this to work for us.

We could completely block direct commits to main (including from the admins/code owners who have to install the PagesCMS GitHub App, but that would result in very confused UX on the PagesCMS side--where nothing would work until you discovered how to create a new branch...which is pretty hidden atm.

Essentially, I'd want main to be "hidden" and PagesCMS to always make a branch which would result in a PR. I'd currently leave the actual publishing action to the PR review/merging on GitHub (though eventually, that'd be slick to have in PagesCMS UX also).

Thanks for building this! It's very promising.