Open plsalvado opened 3 years ago
Sounds good @plsalvado 🚀
@doitadrian thinking a bit more about this... Environments are an important CI/CD feature, in particular the protection rules around approvals, wait times, etc. This is important for a better developer experience, and the overall quality control of code releases. Customers running on public repos or private repos under GH Ent shouldn't see their experience degraded.
So can we think of a solution where we keep Environments for the cases where these are supported, and fallback to the Secrets option - with a somehow degraded experience - for all other cases?
Sounds great @plsalvado 👍🏻
This issue is stale because it was opened 120 days with no activity. Remove the "stale-issue" label or leave a comment to revive the issue. Otherwise, it will be closed in 7 days.
@plsalvado @doitadrian We soon hope to setup CI/CD but this will hold us up unless there are other workarounds. Enterprise is significantly more expensive ($21/per mo/per user vs. $4) and is not feasible for organizations/teams/agencies who have many contributors and users on multiple (non-Webiny) projects.
Issue should now resolved per https://github.com/webiny/webiny-js/pull/2586.
The current CI/CD scaffold for GH relies on GH Environments. Environments are not supported by private repos, unless these are under a GH Ent account (link).
When the scaffold runs against a private repo*, the following error is thrown:
✘ Creation of pr, dev, staging, and prod code repository environments failed with the following message: Not Found
As things stand today CI/CD doesn't work for private repos*.
* unless the private repo is under a GH Enterprise account.
This is:
Specifications
Expected Behavior
We expect the scaffold to work even for private repos - whether it relies on Environments or any other mechanism.
Actual Behavior
Scaffold throws an error (see above) and CI/CD can't be used at all for private repos.
Steps to Reproduce the Problem
yarn webiny scaffold
and answer the questions asked,Possible Solution
doitadrian and I discussed a potential solution where we'd move away from Environments, and use Repository Secrets instead. Since Secrets is a flat store of data, we'd have create tuples of secrets specific to each environment, prefixed by the environment name, e.g. DEV_AWS_ACCESS_KEY_ID, DEV_AWS_SECRET_ACCESS_KEY, etc - same would apply to PROD and other envos.
We'd also have to update the build-test declarations under
/webiny-js/packages/cli-plugin-scaffold-ci/src/githubActions/files/workflows/.github/workflows