Add Editorial Workflow support for GitLab and BitBucket backends

[tech4him1]

- Do you want to request a feature or report a bug?
feature

The new GitLab and BitBucket backends do not support editorial workflow yet. Since GitLab's API does not support low-level metadata like GH does, we will need to find a different method.

Do you just need drafts?
If you really just need drafts and not necessarily the entire editorial workflow, please be sure to add a thumbs up to #942.

[erquhart]

Agreed - we need to start using a branch for metadata instead of an orphan ref.

[tech4him1]

I also think the metadata should contain as little actual information as possible, in the event it is deleted or lost.

[tech4him1]

@zanedev Do you have any thoughts on implementation of this in regards to BitBucket?

[zanedev]

@tech4him1 actually I haven't put much time or thought into how the whole editorial workflow is implemented for github yet. I did notice you can manage refs with the bitbucket api though, it may be possible in a similar way as github.

[zanedev]

I imagine after we plan it out here we would break out different tasks for each backend.

[arnaudschlupp]

Hi!, I would like to know if discussions about this one already started or if there are blockers to start this one out. Thanks a lot fo the amazing work you are doing here 👍

[marcos-abreu]

It would be good to understand the architecture used for Github and what were the requirements that led to it. Basically just an overview, so we could propose some solutions for it. I have some time and would love to help get this feature out of the door.

[Undistraction]

Is there currently any plan to support the editorial workflow on Gitlab in the near future?

[erquhart]

Anyone willing to take this on would need to dig into the GitHub backend to understand how it works. I'd like to see #1669 in place beforehand as well.

In a nutshell, the editorial workflow uses pull requests instead of just committing to a Git repository's main branch, and "publishes" entries by merging the PR, all of which happens via API. Things are complicated by our use of a separate metadata branch in the GitHub backend, and #1669 outlines a way forward. But that aside, automating the mechanics of pull requests (including rebasing logic) is all that's needed to add workflow support to a backend.

[ghost]

We'd like to contribute, and implement Editorial Workflows for GitLab, as it'd help us a lot to manage our documentation.

I'll go for the simplest solution, and won't try refactoring common things between backends, because it's been years since the last time I used JavaScript.

We'll see how far I get in a couple of days, then we'll figure out everything else.

-Rudolf

[ghost]

I managed to get Editorial Workflows for GitLab working (with localForage IndexedDB metadata storage).
I'm not yet sure whether the metadata could be inferred from branches and merge requests or have to be stored in a separate branch.

I noticed that deleting a published entry doesn't use workflow which might be confusing to users.

[ghost]

I ended up implementing metadata storage in a separate branch.
I couldn't find a way to create orphan branches with the GitLab API, so that branch have to be created manually with Git, but I hope this is an acceptable tradeoff.

We'll review and test the changes internally next week.

[davidkazuhiro]

Will this work with GitHub Enterprise as well?

[erquhart]

Do you mean GitLab? The GitHub backend supports GHE and already has editorial workflow support.

[davidkazuhiro]

Nope I meant GHE. Thanks for the clarification!

[emilio-martinez]

Is looks like the PR that used to be open for Gitlab support (#1817) is stalled due to the user deleting their account. Has anybody picked it up or does anybody have it in their queue?

[erquhart]

No sir. Interested?

_{Sent with GitHawk}

[emilio-martinez]

For sure—I'm still getting acquainted with Netlify CMS but I'd be up to pick this up after I'm a bit more familiar

[jamezrin]

I have tried improving gitlab adding a way to create an orphan branch and everything - there is so much technical debt. I can't figure my way around how gitaly in specific works (the part that interacts with git).
The big issue is that gitlab's API doesn't support this, otherwise it would be trivial to improve this PR and finish it.

[erquhart]

@jamezrin that's actually not a problem, see my comment here: #1817 (comment)

[erquhart]

I added a note about this to the OP, but wanted to ping folks watching this issue already: if you really just want drafts and don't necessarily need the entire editorial workflow, please go thumb up (or add some reaction to) #942. Thanks!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nop33]

Nooooooooooo!

[andreacfromtheapp]

please keep this alive.

[tomrutgers]

I think the Nooooooooooo pretty much covered that lol

[erquhart]

Attention all watchers: this issue is officially in progress!! 🎉🎉

[mushkin-v]

What's the date of the release?)

[erquhart]

Soon :)

[erquhart]

@erezrokah I'm thinking we should use labels and no other metadata for this (orphan refs not supported by GitLab/Bitbucket) in the spirit of #1669 and #2977. The critical metadata for the current editorial workflow is the collection name, so we’ll probably need to infer that based on the path (and filters). Basically reverse of how we determine which entries to load for a collection.