painless-continuous-delivery

painless-continuous-delivery copied to clipboard

Signed-off-by: Carole Hamer [email protected]

This small change fixes the default docker_registry option that is offered by the cookiecutter cli when the user selects "Rancher" as a cloud platform. Without this change, the default docker_registry is "Rancher" (which is not a docker registry, hence creates a broken .gitlab-ci.yml file). With this change, the registry options are based on the choice of ci-service, same as with APPUiO.

The line that was changed was already barely-readable, and the hacky logic in this change makes it worse. It might be better to refactor the templating code in the cookiecutter.json file to make it clearer and more maintainable.

I was looking at this part of the code because I had thought it might be a good idea to replace the line - docker login -u gitlab-ci -p ${REGISTRY_PASSWORD} ${REGISTRY} with the line - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY in the .gitlab-ci.yml file as described in the gitlab documentation here.

But, upon reflection, I think that's probably only a simplification if your registry is set to public, which is not the default use case, so maybe we should not make that change.

Okay, but wouldn't the thing you propose be the appropriate solution for "everything with GitLab"?

- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

We may want to fix this in the template that generates the related portion of the CI setup.

I think, it makes sense to leverage the CI platform features to allow for a much simpler, easier to understand CI configuration.

Do you want to give this a try? Ping me, if you want to pair up for this.

Okay, but wouldn't the thing you propose be the appropriate solution for "everything with GitLab"?

- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

Maybe it is, actually.

I was thinking that it wouldn't work for a gitops setup because the gitops repo would still need special account credentials in order to pull the image (that was pushed by the ci pipeline of the application repo). But if both repos are in GitLab in the same project group, the above would probably work for both. In which case the above change should logically eliminate the manual step of creating the KUBE_TOKEN.

We may want to fix this in the template that generates the related portion of the CI setup.

I think, it makes sense to leverage the CI platform features to allow for a much simpler, easier to understand CI configuration.

Do you want to give this a try? Ping me, if you want to pair up for this.

Changing the template for the .gitlab-ci.yml file is the easy part. The trickier part is to clean up the templating code in the cookiecutter.json file so that it can offer this option in a way that is not confusing to the user.

The simplest solution (following the conventions of that template) would be to set the default "registry_user" to "$CI_REGISTRY_USER" -- which is confusing unless the user happens to be looking at the page of documentation I linked above. Maybe it would make sense instead if picking GitLab for the repo, registry, and pipeline would suppress the "registry_user" option and automatically use the above registry login. But that would require changing some logic in the cookiecutter.json template.

suppress the "registry_user" option and automatically use the above registry login

I don't know how this is done (or even, I fear this can't be done) with the Cookiecutter prompts. Let's think this through together in front of the screen.

suppress the "registry_user" option and automatically use the above registry login

I don't know how this is done (or even, I fear this can't be done) with the Cookiecutter prompts.

That's unfortunate -- I think there are real use-cases for it (including this one)

Let's think this through together in front of the screen.

Sounds good. I do have some other meetings this afternoon, but I'm sure we can find time.