Skip to content
This repository has been archived by the owner on Sep 2, 2023. It is now read-only.

Feature: Sandboxed workflow #117

Open
graphicore opened this issue Aug 27, 2019 · 1 comment
Open

Feature: Sandboxed workflow #117

graphicore opened this issue Aug 27, 2019 · 1 comment

Comments

@graphicore
Copy link
Contributor

Mentioned in #114 and #115.

#115 describes one prerequisite for this to work: A designer or engineer working on a release of a font project will likely (because it's good practice) work on a feature branch that is not master (or, if we'll allow it the, a special gf-releases-upstream branch). In that process, the author will want to test the feature branch against the QA-assembly-line, but without merging into master all the time and without triggering an actual pull request .

Short term

I want to establish a switch, when initiating a new process, between: sandbox and production. That will change:

  1. the input spreadsheet file to a version that is only used in sandbox mode "[dashboard SANDBOX Copy] Google Fonts Upstream Repos" and the actual production file.
  2. the output repo, that we use to PR to, to a Sandbox/non-production fork of google/fonts currently graphicore/googleFonts

At the very moment, the deployed version of FBD is by default in the Sandboxed mode, but that means there's no way to make production PRs. Also, #115 blocks the Sandboxes mode to be actually useful for our engineers, who also asked in #114 to be able to play with the dispatcher without the worries of breaking stuff or annoying anyone.

The "feature branch workflow" also suggests, that once an engineer is happy with the branch, the branch will be merged into the master (gf-production) branch and from there the dispatcher can be used in "production" mode to create an actual PR to google/fonts, which will be recognized and assessed by the gf-engineers.

User Stories

  • @vv-monsalve and @eliheuer are working on different font projects in feature branches. They want to monitor and (re-)assess their efforts repeatedly before merging their feature branches into the production/master branches of their respective projects. Both can be trusted to be granted direct writing access to the "[dashboard SANDBOX Copy]" spreadsheet.

Mid Term

For the short term approach, we still need to give to trusted people access to the "[dashboard SANDBOX Copy]" spreadsheet or just do it via our engineers. But, if anyone is interested in releasing a font via google fonts, access to the QA tools (via the dispatcher) should be easy in sandbox mode. Further, switching the "input" spreadsheet only allows for one sandbox repository+branch per family, where in a distributed workflow many branches may be required to check different repos+branches in sandbox mode. Hence the sandbox mode should allow for easy registration and usage (maybe just per process -> copy the branch github url, maybe save in a personal profile) of a feature branch.

User Stories

  • a new contributor wants to check a new and unregistered project with our tools, quietly, before requesting the initial on-boarding of the new family
  • a project is enhanced with many new scripts made by many designers around the world at the same time, each designer wants to check their new, locally different version, against QA before merging (PRing) into the project master/release branch.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant