@agilecustoms/envctl 0.23.15 → 0.23.20
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -6
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -21,7 +21,7 @@ npm view @agilecustoms/envctl version # show latest version available (without i
|
|
|
21
21
|
## npmjs setup
|
|
22
22
|
|
|
23
23
|
1. Login in npmjs.com
|
|
24
|
-
2. Create organization
|
|
24
|
+
2. Create organization "agilecustoms" this will create scope `@agilecustoms` (one org => exactly one scope, also scope can be created w/o org)
|
|
25
25
|
3. Go to your user > Access Tokens > Generate New Token > Granular Access Token
|
|
26
26
|
1. Token name: `agilecustoms-ci`
|
|
27
27
|
2. Packages and scopes
|
|
@@ -38,11 +38,11 @@ npm view @agilecustoms/envctl version # show latest version available (without i
|
|
|
38
38
|
created in `env-api` and then 'managed' by `env-api`: it deletes env when it is not in use anymore OR can extend lifetime.
|
|
39
39
|
Creation API yields unique ID, so you can safely manage env (delete, extend lifetime) via this ID. But creation API
|
|
40
40
|
needs to be secured. There are two main use cases:
|
|
41
|
-
1. create environment from CI (mainly ephemeral envs)
|
|
42
|
-
2. create env from dev machine
|
|
41
|
+
1. create an environment from CI (mainly ephemeral envs)
|
|
42
|
+
2. create env from a dev machine
|
|
43
43
|
|
|
44
|
-
I (Alex C) have chosen IAM authorization as common denominator:
|
|
45
|
-
1. on CI — use OIDC to assume role `/ci/deployer`
|
|
44
|
+
I (Alex C) have chosen IAM authorization as a common denominator:
|
|
45
|
+
1. on CI — use OIDC to assume a role `/ci/deployer`
|
|
46
46
|
2. on dev machine — use SSO and profile chaining to assume role `/ci/deployer`
|
|
47
47
|
|
|
48
48
|
Then as `/ci/deployer` --call--> `env-api` HTTP API (exposed with API Gateway with IAM authorizer)
|
|
@@ -52,6 +52,6 @@ quickly became bulky and hard to maintain. Then I thought about Node.js - it is
|
|
|
52
52
|
in GitHub actions (namely in Ubuntu runners). How to distribute it? First I thought about using `ncc` to bundle in one
|
|
53
53
|
big .js file (as I do for `release-s3` and `gha-healthcheck`) but it will be hard to use on dev machine...
|
|
54
54
|
|
|
55
|
-
So I ended up publishing this client as npm package in npmjs
|
|
55
|
+
So I ended up publishing this client as an npm package in npmjs
|
|
56
56
|
- CI environments can install it via GH action `agilecustoms/envctl`
|
|
57
57
|
- developer will install it globally via `npm install -g @agilecustoms/envctl`
|