- Configuration variables and secrets
- Sharing configuration between flows
- Organizing your repositories (projects)
- Setting the configuration values
This page shows you how to authenticate flows with other services and apps so that they can automate tasks that involve those services and apps. For example, a flow that deploys data or builds to a distribution platform might need keys to access that platform.
Many of the values that you will need to configure for common flows to work involve secrets. Secrets are keys (non-interactive equivalents of passwords) that allow flows to transfer data to other services, such as Steam, TestFlight, AWS, and Google, or communicate with other apps, such as Slack and Jira.
WVS provides two places where you can configure your secrets. One is in in each project’s setting, while the other is in a group. In both cases, only “maintainers” of that project or group can see those secret values.
By the time your project is finished, you may have quite a number of flows that you had added over time. If you had to configure each flow individually, you may end up duplicating a lot of configuration effort since many flows require the same configuration values.
WVS gives you the flexibility of configuring each flow individually (after all, you might want one flow to send a build to one Steam account, and another one to a different Steam account). However, where possible, flows are set up to use standard default configuration values so that if you configure those values once for your organization, the flows will simply use that configuration by default.
You have a choice of two places where you can set these default configuration values. One is in your project. The other is in a group.
If you set your shared configuration values in your project, then all flows you add to your project can use those configuration values and will default to them as relevant. However, if you create another project, then you will need to set all of those values up for that project as well.
If you set up your shared configuration values in a group, then any project that belongs to that group will have access to the values. As you add projects, you will not have additional configuration work.
The appropriate approach for you depends on your organization, the nature of your projects, and the nature of your collaborators. If you are a company where you mostly use the same accounts and infrstructure for all our projects, then setting up your repositories under a common group and putting shared settings in that group is absolutely the right way to go. If, on the other hand, each project has a different set of external collaborators and you do not share accounts / infrastructure between projects, then setting up configurations on a per-project basis may be right.
The rest of the instructions in this document are relevant whether you choose to configure on a per-group basis or a per-project basis
You must be a project or group “maintainer” in order to follow these instructions.
- Go to Project Settings or Group Settings, as relevant to your situation.
- Choose the CI/CD category
- Expand the Variables section
- Using the tables, Add variable one by one as relevant
Please make sure to careful check the values and settings for each variable
Configure the variables in this section to set the default values for accessing your AWS account.
|WVSUSR_AWS_KEY||Access key id||no||yes||Generated when you created a key on AWS|
|WVSUSR_AWS_SECRET||Secret access key||no||yes||Generated when you created a key on AWS|
|WVSUSR_AWS_S3BUCKET||Name of bucket||no||no||The name of the default S3 bucket to use. This should be the name of the bucket and not the full URL. Must exist and have R/W permission for above key.|
Using an organization wide Shared Derived Data Cache is highly recommended by Epic. To use one on WVS, you have to request one and will receive they key for it that you use for the configuration below.
|WVSUSR_UE_DDC_KEY||Shared DDC id||no||yes||Request from account contact|
|WVSUSR_UE_DDC_SECRET||Shared DDC key||no||yes||Request from account contact|
Oculus apps have several different means of distribution, including the officials store and the App Lab. While the means of distribution for a specific app is controlled on the Oculus developer site, they use a common means for submitting builds to be distributed through various channels. To use the standard deploy to Oculus flow, you need to set the variables below to values obtained from the API page for your app on the Oculus developer site.
|WVSUSR_QUEST_APPID||The Oculus App ID||no||yes||Set to the value of “App ID” on the API settings page for your app.|
|WVSUSR_QUEST_APPSECRET||The Oculus AppSecret Token||no||yes||Set to the value of “App Secret” on the API settings page for you r app|