You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the proposals at the moment is that we could use GitHub Secrets in the samples.
On the one hand, this could be nice for people who are used to using GitHub's system, but it leads to a potential for drift and conflict:
If a user deploys a sample using this method but isn't deeply familiar with what we're asking them to do, then we run the risk of them using the defang config set command down the line and accidentally overriding that config with the previously set GitHub secret.
Essentially we'd be asking them to manage config in two places, or trusting that they know not to use defang config set when using the samples which strikes me as quite counterintuitive.
Right now, the workflow I've setup in the Portal is to provide a command that they can copy/paste into their terminal which will run the defang config set commands for all the config vars required by the sample.
I think that's workable, but suboptimal.
In the end, I think if we want the smoothest possible experience, we should provide the user with an opportunity to set the necessary env vars when they're going through the one-click deployment process. Ideally, I think we could provide a little bit of metadata for each environment variable so that the user can figure out exactly what they need when they're presented with the variable.
One of the proposals at the moment is that we could use GitHub Secrets in the samples.
On the one hand, this could be nice for people who are used to using GitHub's system, but it leads to a potential for drift and conflict:
If a user deploys a sample using this method but isn't deeply familiar with what we're asking them to do, then we run the risk of them using the
defang config set
command down the line and accidentally overriding that config with the previously set GitHub secret.Essentially we'd be asking them to manage config in two places, or trusting that they know not to use
defang config set
when using the samples which strikes me as quite counterintuitive.Right now, the workflow I've setup in the Portal is to provide a command that they can copy/paste into their terminal which will run the
defang config set
commands for all the config vars required by the sample.I think that's workable, but suboptimal.
In the end, I think if we want the smoothest possible experience, we should provide the user with an opportunity to set the necessary env vars when they're going through the one-click deployment process. Ideally, I think we could provide a little bit of metadata for each environment variable so that the user can figure out exactly what they need when they're presented with the variable.
See https://github.com/DefangLabs/portal/issues/69
The text was updated successfully, but these errors were encountered: