Prevent reordering of env in kubernetes deployment

[antoniomacri]

Description

I'm using the kubernetes extension to generate the manifest files for my application, which are then committed into a repository.

However, sometimes variables inside the env part of the deployment are reordered, causing unwanted changes in the git history.

Would it be possible to produce the env vars in a fixed order? For instance they could be sorted alphabetically by name.

Implementation ideas

No response

[quarkus-bot]

/cc @geoand (kubernetes), @iocanel (kubernetes)

[geoand]

@iocanel would processing KubernetesEnvBuildItem in a defined order be enough or would this require changes in Dekorate as well?

[iocanel]

@iocanel would processing KubernetesEnvBuildItem in a defined order be enough or would this require changes in Dekorate as well?

All decorators are sorted and applied in a specific order. This is done usually by type. Maybe in the case of Env vars we could also take content into consideration. But yeah most probably this is something that we should better do in dekorate.

[antoniomacri]

@iocanel @geoand any news on this? or an issue on dekorate I could follow?

[antoniomacri]

@iocanel would processing KubernetesEnvBuildItem in a defined order be enough or would this require changes in Dekorate as well?

All decorators are sorted and applied in a specific order. This is done usually by type. Maybe in the case of Env vars we could also take content into consideration. But yeah most probably this is something that we should better do in dekorate.

Hi @iocanel could you give me some pointer to the code on the sorting logic?

I'm having some difficulty trying to implement this in dekorate, so I'm also looking to the kubernetes extension.

@geoand You mean something like this?

Stream<KubernetesEnvBuildItem> itemStream = Stream.concat(config.convertToBuildItems().stream(),
        envs.stream().filter(e -> e.getTarget() == null || KUBERNETES.equals(e.getTarget())));
if (config.idempotent) {
    itemStream = itemStream.sorted(Comparator.comparing(e -> EnvConverter.convertName(e.getName())));
}
itemStream.forEach(e -> {
    result.add(new DecoratorBuildItem(KUBERNETES,
            new AddEnvVarDecorator(ApplicationContainerDecorator.ANY, name,
                    new EnvBuilder().withName(EnvConverter.convertName(e.getName())).withValue(e.getValue())
                            .withSecret(e.getSecret()).withConfigmap(e.getConfigMap()).withField(e.getField())
                            .build())));
});

Do you think it's a viable option?
I could prepare a PR if that's ok.

[geoand]

@iocanel is the SME here, so let's wait to see what he says

[guaido79]

Hi there,

I have the same problem with the

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-kubernetes</artifactId>
</dependency>

When adding variables, the random generated order of env properties in the kubernetes.yml files cause unwanted merge with just different order in the pipelines

Is there a solution?

[iocanel]

I will try and addreess that both in dekorate and here too.

[antoniomacri]

Hi @iocanel, any news on this?

How can I help?

[iocanel]

@antoniomacri I started working on that on the dekorate side of things , till I got distracted.
All help is more than welcome really. You can even pick it up from where I am currently at and I would be more than glad to help you through it.

[antoniomacri]

@antoniomacri I started working on that on the dekorate side of things , till I got distracted. All help is more than welcome really. You can even pick it up from where I am currently at and I would be more than glad to help you through it.

Do you have a branch to look at?