Allow client to optionally specify branch to pull from

[PurpleGuitar]

It would be great if the client could specify which branch to pull from besides master. This has been requested by the content team, who are developing a condensed version of the en_tn resource, so that they can preview what the changes will look like in the IRG before pushing to master.

[markalolo]

I believe this is a duplicate of issue #84 can they be merged?

[abycurley]

While I think this has value for the content team, I don't think it should be a permanent option for everyday users of DOC. Is this something we could introduce, then phase out when the condensed TN are pushed into production?

Or is there something on the back office/development side IT could make for the content team to run sample condensed TN on demand for testing purposes? My preference is that this feature not be public.

[linearcombination]

One option is to make it available through just the backend and not the UI. Then specialists/coders could request a document via the backend API and specify a particular branch. I am not necessarily recommending this as it introduces complexity, but it is possible.

[markalolo]

Perhaps it would be better for the content team to fork the project into its own repo, rather than managing it via a branch. Then that separately named resource would be available for selection. This would require no changes to DOC.

[abycurley]

We should be careful not to make something publicly available that is not fit for public consumption. The content team would like to use this function to run tests and check-ups on their project, but I don't want someone to stumble upon a draft and think it's the final. Does that makes sense?

[linearcombination]

@markalolo , given @abycurley's comment, maybe we should consider a comment I made above:

"One option is to make it available through just the backend and not the UI. Then specialists/coders could request a document via the backend API and specify a particular branch. I am not necessarily recommending this as it introduces complexity, but it is possible."

This would limit its use to someone using a client other than the UI, e.g., a script, postman, etc., to trigger a document request. We could introduce API keys or some other control mechanism to deny access to the backend API. Then the content team could execute such a client, say postman or a script, to generate a document, but it would not be available through the UI.

Perhaps you @markalolo and @abycurley could consider that as an option, or maybe that will make you think of other options too. Hope this is helpful.

Another option could be a locally running instance with this option via Docker for the purpose of proofing content. I.e., locally on one person's machine using a special branch of the project checked out from github having the desired functionality. A technical person at WA would need to show the appropriate person on the content team how to run the app in Docker in this way. Perhaps this would be an option to consider as well.

[abycurley]

I definitely don't understand anything @linearcombination said here, but I'm happy to discuss further in a more simplified version. Unless this is as simplified as it gets, in which case, I trust whatever @linearcombination and @markalolo recommend...

[markalolo]

@linearcombination let's just hold off on implementing it for now. I think it's an unusual enough edge case that it doesn't make sense to spend development time on it.