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
The editorial workflow should display any PR that changes a file that CMS is configured to edit, even if there are multiple such files and/or files that the CMS is not configured to edit.
Context
This issue coincides with #1669 (probably a prerequisite) and provides groundwork for #192 and #1025.
The editorial workflow can only surface pull requests created by the CMS, and only deals reliably with pull requests that consist entirely of CMS created commits. This is not great for:
existing projects that add the CMS
projects that want to publish non-CMS changes together with content changes
teams that want to use some mix of Git, GitHub, and the CMS in their workflow
Solution
Pull in any pull request and infer all necessary info, Eg. which collection an entry belongs to. Make the workflow trivial to opt in/out of per pull request.
Proposed changes
Pull requests can be filtered by checking for changes to a file whose path matches the configuration for a collection.
Pull requests that have not already been interacted with by the CMS would appear in a separate column or location in the workflow.
Leaning on Improving metadata handling #1669, an isomorphic control such as GitHub's labels would be used to indicate pull requests that are actively in the workflow.
Removing the isomorphic control would cause the PR to show in the area with PR's that are not active for the CMS, and may be reactivated
Editorial workflow branches with multiple CMS entry files will show those files, and each can be edited.
Publishing can be optionally disabled specifically for workflow branches that include changes to files that the CMS cannot edit, such as source code
It would be helpful if branch switching could be introduced agnostic of the editorial workflow given that EW is exclusive to GitHub. I outlined a use-cases in #2964
tl;dr
The editorial workflow should display any PR that changes a file that CMS is configured to edit, even if there are multiple such files and/or files that the CMS is not configured to edit.
Context
This issue coincides with #1669 (probably a prerequisite) and provides groundwork for #192 and #1025.
Also satisfies #2236.
Problem
The editorial workflow can only surface pull requests created by the CMS, and only deals reliably with pull requests that consist entirely of CMS created commits. This is not great for:
Solution
Pull in any pull request and infer all necessary info, Eg. which collection an entry belongs to. Make the workflow trivial to opt in/out of per pull request.
Proposed changes
Out of scope
The text was updated successfully, but these errors were encountered: