Remove registered_name suggestion for the .toml via the cli

💡 Feature Requests
,
1

Description of the limitation and why it is relevant to address

As a developer I want that the cli does not warm about using registered_name in .toml over the --registered-name flag. In a DTAP (Development, Test, Acceptation, Production) system, this does not work because a single Github/Devops repository is used for publishing to multiple apps.

image
image1505×225 16.2 KB

I think this is relevant for the VIKTOR platform because not all developers work with 1 repo for 1 app as mentioned. As a result, you each time get the extra question when publishing when the answer is always the same.

Submitter proposed design (optional)

Remove the suggested .toml change when publishing. It is already documented in the documentation.

Current workarounds

None

2

Hi Vincent, thanks for the request!

This suggestion has been implemented in the CLI since publishing is often perceived as a difficult step by developers, as well as to create awareness of the possibility to configure the registered_name.

For more experienced developers it may indeed be annoying. As a workaround you could commit something like this:

...
registered_name = "-"
1 Like
3

This doesn’t address your problem now, but here is a feature request that you might find interesting: Pinning a version of an application to a workspace

We think that it would be great if you only have a single application for these different stages of the DTAP flow. You can still have different workspaces, pinned on different versions of the application. Do you think this is indeed a good approach?

4

Roeland indeed mentioned this to us. A few things that cross my mind with this:

  1. You sometimes have different app variables per DTAP phase. Each version for examples points to another DTAP version of an API we use.
  2. That also means that you manually have to update workspaces to assign a new app version. The UI needs to support bulk updating the version of multiple workspaces then.
  3. Maybe you can introduce special DTAP tags to workspaces then to at least make filtering easier (for example to select workspaces in point 2).
  4. The UI will need an option to cleanup previous versions because now the app is just overwritten

Personally, I don’t mind having different apps for DTAP. It keeps things nicely separated without the need for selections in a single apps like which version or app variables.

2 Likes
5

Thanks for the tip. Seems like a simple workaround now.

6

Thanks a lot for sharing your thoughts on this!