Set Up CI/CD

Overview

To use it, simply run the following command from your project root:

yarn webiny scaffold

Once the list of all available scaffolds is shown, select the Set up CI/CD option and continue by answering the questions that follow.

Different CI/CD Providers

At the moment, the scaffold allows you to set up your CI/CD with GitHub Actions only. But in the future, we would certainly like to also bring support for more providers, depending on the interest from the community.

If you plan to use a different CI/CD provider, you can still create your workflows manually, by following all of the recommendations outlined in CI/CD key topics. Also, if you think your provider should be supported out of the box, please open an issue or contact us .

GitHub Actions

GitHub Actions

(click to enlarge)

GitHub Actions are often a good choice when it comes to setting up your own CI/CD, simply because of its tight integration with other existing GitHub concepts and resources.

✘ Creation of pr, dev, staging, and prod code repository environments failed with the following message: Not Found

What Actions Will the Scaffold Perform for Me?

No matter whether you choose to set up your CI/CD within an existing GitHub code repository or create a new one, during the scaffolding process, the following actions will be taken on your behalf:

1. push GitHub actions workflows
2. create protected dev, staging, and prod branches
3. set dev as the default branch
4. create dev, staging, and prod code repository environments

Workflows rely on GitHub Environments in order to establish environment protection rules and store all of the necessary secrets, for example AWS credentials or Pulumi Backend.

Next Steps

Once the scaffolding has finished, these are the steps we recommend you follow:

1. Ensure dev Branch Contains the Latest Code

While moving through the setup wizard, you get to choose whether you want to create a brand new GitHub code repository, or use an existing one.

In case of the former, note that, apart from the initial GitHub Actions workflows, the created code repository will be empty. In other words, during the scaffolding process, your project files are not automatically pushed into it.

In order to do that yourself, you can run the following commands:

# Skip this command if your code repository was already initialized locally.
git init

# Connect your local code repository with the just created remote one.
git remote add origin git@github.com:{GITHUB_USER}/{GITHUB_REPO_NAME}.git

# Commit all project files and push them into the default "dev" branch.
git fetch && \
git add -A && \
git commit -m "chore: initial commit" && \
git checkout dev && \
git merge master --allow-unrelated-histories -m "merge: pull changes from master" && \
git push -u origin dev

In case of the latter, if you’ve picked an existing GitHub code repository, then most likely your project was already previously pushed into it, and no additional actions are needed.

2. Delete Previous Default Branch (Optional)

By default, for every new code repository, GitHub sets the main (previously master) branch as the default one. Since during the scaffolding process, the dev branch was set as the new default, you can delete the previous one.

3. Setup Environments

Finally, go to your code repository settings and navigate to the Environments settings. In here, you should be able to see three different environments that were created during the scaffolding process:

GitHub Environments

(click to enlarge)

Respectively, these environments are assumed every time a change is pushed into dev, staging, and prod branches, in the build-test job within created devPush.yml , stagingPush.yml , and prodPush.yml workflows.

These enable two things:

1. provide deployment secrets - AWS credentials and Pulumi Backend.
2. establish environment protection rules - by default, every push to one of the long-lived branches requires a deployment approval on your behalf (you can edit this list via environments settings)

In order to enable automatic deployments, for each environment, you’ll need to set the following secrets:

1. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION

With credentials, we also need to specify the AWS region via the AWS_REGION environment variable.

2. PULUMI_SECRETS_PROVIDER and PULUMI_CONFIG_PASSPHRASE

And although Webiny does not store nor rely on this feature by default, we still need to define the PULUMI_SECRETS_PROVIDER and PULUMI_CONFIG_PASSPHRASE environment variables. This is simply a requirement set by the Pulumi CLI.

We suggest you use “passphrase” as the value of the PULUMI_SECRETS_PROVIDER secret, and, for the PULUMI_CONFIG_PASSPHRASE secret, that you simply generate a random string as its value.

3. WEBINY_PULUMI_BACKEND

Access Token

4. Start Developing

Note that, at this point, the staging and prod branches will still be empty, and no deployments will occur until you actually merge the dev branch into staging, and later the staging branch into production. Still, if you want to deploy these too, simply do the merging immediately, without waiting for first code changes from developers to arrive.