Building code for previews and for production
That song with the "I like to move it-move it" lyrics must have been about pushing code to production...right?
At the moment, we have both of our codebases all set up, and we have all of the accounts in place. What remains to do is put the code on GitHub and actually make Cloudflare deploy a site from the application code.
It's finally time to publish the very first, virgin version of our design system components. Logically, we need to have code in GitHub first, so that's where we will start.
Before continuing, make sure that you've created any accounts that are needed, as instructed throughout module 1.
Committing and pushing code to GitHub#
Setting up the component library repository#
Go to GitHub. Click New in the left-hand side menu bar, and select the Repository option.
In the following dialog, enter a name for your repository. We already have a basic README file and the other items, so there's no need to pre-create anything for us.
You can probably use a private repository without a hitch, but I am assuming you'll make it a public one.
Next up we need to set two secrets
FIGMA_TOKEN corresponding to your such values—so that our GitHub Action will run. Under Settings, the Secrets and variables pane leads to the Actions page where these can be set.
Later, we will need a third (
CHROMATIC_TOKEN), but you can wait with that until later.
Pushing the code to GitHub#
Navigate to your component library codebase and run the following, first having substituted
REPO for your user name and repository name.
This will set the folder up with Git, add all of the files, commit them to Git, and then push them to the new repository under a branch called
main is quickly becoming the new standard for the mainline or trunk branch, replacing the old convention, which went by the name
Verify that the GitHub Action works as intended#
The code includes a basic GitHub Actions workflow that will run when you push to the
main branch. Specifically, this workflow just runs Webpack and builds the components. We should verify that the workflow performs as expected.
In GitHub, navigate to the repository and go to the Actions tab. You should see that the build is passing.
If a pipeline fails for some reason that does not have to do with the code being bad, you can easily retry a pipeline in the Actions page in GitHub. Use that instead of pushing code if you actually just need a good old retry.
If you would have deployed the application in its current state, you'd quickly run into it crashing since it uses the component library that is only available to you locally. For the time being, we will therefore deactivate any custom components and just make the first deployment without any of those in order to verify that the infrastructure works as intended.
src/views/DemoView.jsx, update it to no longer include the demo component: