Update k14s support with local deploy and image specified based on sha #108
Conversation
Also switch to separate image values in ytt data to better enable bumping of image, see github.com/cloudfoundry/uaa for an example of this pattern
|
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
Default install simplified by removing need to set REGISTRY_HOSTNAME and REGISTRY_PROJECT when using make kapp-deploy
edwardecook
force-pushed
the
k14s-local-deploy
branch
from
cf36aaf
to
36b831e
Compare
edwardecook
changed the title
[#173681350] Signed-off-by: Glen Rodgers <grodgers@vmware.com>
Signed-off-by: Ed Cook <ecook@vmware.com>
| @@ -0,0 +1,29 @@ | |||
| platform: linux | |||
There was a problem hiding this comment.
This workflow doesn't make too much sense to me. I believe it exists so that someone could kapp deploy the latest images by pulling down the repo and running make kapp-deploy (non-local deployment). However, in my opinion, a non-local deployment should just use the artifact produced by CI (ie. projects-operator-1.2.3.tgz). That is, we discourage make kapp-deploy non-local outside of CI. Curious what you all think.
There was a problem hiding this comment.
One of the main benefits of bumping image ref is that it allows repos that use projects-operator as a dependency to pull in by commit sha and have the appropriate image referenced (which is the current flow in our main repo). If we switched to only tagged and released versions being consumable we would need to make two changes:
- we would need to release a new version of projects-operator every time we made a change for the benefit of the upstream repo
- we would still need a workflow that updated the contents of the release artefact (currently a trimmed down version of the repo, see https://github.com/pivotal/projects-operator/blob/master/ci/scripts/assemble-build-artefact.sh)so that it referenced an appropriate image either by sha ref or tag
Note that the flow we implemented is one that is used by several other OSS projects such as https://github.com/cloudfoundry/capi-k8s-release and https://github.com/cloudfoundry/uaa
We are definitely not wedded to this approach and would be interested in hearing your thoughts on this and/or potential alternatives.
This contains work intended to make the k14s flow easier to use with local development. In addition by pinning the projects-operator image used by sha it makes it easier to use projects-operator as a dependency.