[kots]: create dev channels in KOTS and formalise the release process #8689
Conversation
|
NB I have kept the envvars with |
install/kots/README.md
Outdated
| ## Authentication | ||
|
|
||
| Two environment variables are required to be able to publish to our Replicated account: | ||
| The following environment variables are required to be able to publish to our Replicated account: | ||
|
|
||
| - `REPLICATED_APP`: the unique application slug |
There was a problem hiding this comment.
We still use gitpod-pov, right? Eventually, we will use gitpod for prod but still keep a different dev app slug, right? Should we mention the app slugs in use here?
By the way: What do you think of renaming gitpod-pov to gitpod-dev (or create if renaming does not work)?
There was a problem hiding this comment.
Yes, we are using gitpod-pov which is what's defined by the REPLICATED_APP value. I'm not against documenting in there, but I don't think it's necessary
I can see why gitpod-dev would be preferable, but I'm not that bothered by renaming it. If the majority want to rename it, that's fine, but it's effectively our internal dev service so it's fine as is.
I think we'll likely abandon gitpod-pov in future and just use gitpod but that's a future discussion
There was a problem hiding this comment.
I'm not against documenting in there, but I don't think it's necessary
How does a new colleague know which value to set here? Maybee, we need also a link to the vendor portal where an API key can be generated. Would make the onboarding of new folks easier when we have this written down somewhere and why not here in the readme?
There was a problem hiding this comment.
Ok. I've changed the wording slightly.
The vendor portal is linked in the REPLICATED_API_TOKEN. I'm reluctant to duplicate too much of their development readme in ours as it means we then have to maintain that as well as our own application.
There was a problem hiding this comment.
Ok. I've changed the wording slightly.
The vendor portal is linked in the
REPLICATED_API_TOKEN. I'm reluctant to duplicate too much of their development readme in ours as it means we then have to maintain that as well as our own application.
Awesome! Thanks a lot! 👍
There was a problem hiding this comment.
/hold
looks good to me, adding hold in case @Pothulapati will check this as well or if you would like to add something for #8689 (comment)
There was a problem hiding this comment.
Change Looks good to me! Thanks for taking the time @mrsimonemms
|
/werft with-clean-slate-deployment 👎 unknown command: with-clean-slate-deployment |
mrsimonemms
dismissed stale reviews from Pothulapati and corneliusludmann
via
2406ff9
mrsimonemms
force-pushed
the
sje/kots-channels
branch
from
6f9bf93 to
2406ff9
Compare
|
/werft help 👍 You can interact with werft using:
|
|
/werft run with-clean-slate-deployment 👍 started the job as gitpod-build-sje-kots-channels.2 |
|
@mrsimonemms: Installing preview env fails due to exceeded quota. Why not using … ? /werft run no-preview 👍 started the job as gitpod-build-sje-kots-channels.3 (since this change has no effect on the preview env (does it?) a preview env would indeed unnecessary) |
|
(I'm tired and just want Werft to work 😄 ) |
Description
Formalise the development and release process in the KOTS ecosystem. This came as a result of a conversation with @Pothulapati where it was clear a lot of the process was in my head rather than formally documented
Related Issue(s)
Fixes #8688
How to test
Follow readme
Release Notes
Documentation