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
This issue will affect #6, which may not be able to complete without it.
This issue relates to cases in which the config yaml for a given microservice lives with the source code. A (Tekton) pipeline that builds this source repo will,
docker build
docker tag
docker push
"promote config/* to the configured 'dev' gitops repo"
This latter step involves raising a pull request that takes config/* from the checked out version of the source repository and 'promotes' it to /services/service-name/base/config/* in the target gitops repository - frequently referred to as 'dev'.
In the first case we can assume that service-name is the name of the source repository.
Currently, promote --from /path/to/local/repo --to ur.to.target.repo --service svc-name will look for /services/svc-name/base/config/* in the source repository, since that is the behaviour for when promoting between repositories.
We need the CLI to differentiate between promoting between gitops repositories, and from a source repo into a gitops repo. This was discussed at length in Slack today. We may also later need to differentiate between uploading service config, and that of an application.
For a first pass under this issue, we need to decide between:
Add new CLI arguments, or a new command, for this situation, or
When --from is a local path, assume that we're in this mode, and so copy /path/to/local/repo/config/* to url.to.target.repo/services/svc-name/base/config/*.
The text was updated successfully, but these errors were encountered:
This issue will affect #6, which may not be able to complete without it.
This issue relates to cases in which the config yaml for a given microservice lives with the source code. A (Tekton) pipeline that builds this source repo will,
This latter step involves raising a pull request that takes config/* from the checked out version of the source repository and 'promotes' it to /services/service-name/base/config/* in the target gitops repository - frequently referred to as 'dev'.
In the first case we can assume that service-name is the name of the source repository.
Currently,
promote --from /path/to/local/repo --to ur.to.target.repo --service svc-name
will look for /services/svc-name/base/config/* in the source repository, since that is the behaviour for when promoting between repositories.We need the CLI to differentiate between promoting between gitops repositories, and from a source repo into a gitops repo. This was discussed at length in Slack today. We may also later need to differentiate between uploading service config, and that of an application.
For a first pass under this issue, we need to decide between:
/path/to/local/repo/config/*
tourl.to.target.repo/services/svc-name/base/config/*
.The text was updated successfully, but these errors were encountered: