Add CI action to sync published versions simple example to sandbox repository #10273
Conversation
.github/workflows/test.yml
Outdated
| @@ -157,7 +162,7 @@ jobs: | |||
| runs-on: ubuntu-latest | |||
| name: GreenFrame | |||
| needs: [e-commerce] | |||
| if: success() && github.ref == 'refs/heads/master' | |||
| if: success() && github.ref == 'refs/heads/master' && github.ref_type != 'tag' | |||
There was a problem hiding this comment.
thought: on the contrary, we could run the Greenframe analysis only when a new tag/version is released, as opposed to any commit on master which might be a little too often. Wdyt?
There was a problem hiding this comment.
@fzaninotto any opinion?
There was a problem hiding this comment.
I agree that we should only test greenframe when releasing a new version
.github/workflows/test.yml
Outdated
| - name: Use Node.js LTS | ||
| uses: actions/setup-node@v3 | ||
| with: | ||
| node-version: '16.x' |
There was a problem hiding this comment.
| node-version: '16.x' | |
| node-version: '18.x' |
To be consistent with other jobs of the workflow
Makefile
Outdated
| @@ -172,3 +172,6 @@ storybook: ## Launch the storybook | |||
| build-storybook: ## Build the storybook | |||
| @echo "Building storybook..." | |||
| @yarn build-storybook | |||
|
|
|||
| update-sandbox: ## Push the local version of the simple example to the sandbox repository | |||
| ./update-demo.sh | |||
There was a problem hiding this comment.
| ./update-demo.sh | |
| ./update-sandbox.sh |
(there is no update-demo.sh)
.github/workflows/test.yml
Outdated
| node-version: '16.x' | ||
| - name: Update Sandbox Repository | ||
| env: | ||
| SSH_DEPLOY_KEY: ${{ secrets.SSH_SANDBOX_DEPLOY_KEY }} |
There was a problem hiding this comment.
| SSH_DEPLOY_KEY: ${{ secrets.SSH_SANDBOX_DEPLOY_KEY }} | |
| SSH_SANDBOX_DEPLOY_KEY: ${{ secrets.SSH_SANDBOX_DEPLOY_KEY }} |
To be consistent with the actual script
scripts/update-sandbox.sh
Outdated
| # Allow empty commits because even though we may have published new version of the enterprise packages, | ||
| # the demo code may not have changed. However we still want it to be redeployed and, as we don't keep its | ||
| # yarn.lock, it should use the new packages |
There was a problem hiding this comment.
I understand the rationale, but I believe @fzaninotto was in favor of actually computing and committing the yarn.lock file, in order to reduce the sandbox startup time
Problem
As explained in #10252, Stackblitz is currently very slow. Besides, we can't use codesandbox to open a subpath of our monorepo anymore.
Solution
We now have a dedicated repository for the simple example: https://github.com/marmelab/react-admin-sandbox
This PR adds a CI action that sync the monorepo simple example with the sandbox repository.
It does so only when a new tag is released, except for
next,betaandalphatagsAdditional Checks
masterfor a bugfix, ornextfor a feature