gansheer commented on issue #4639: URL: https://github.com/apache/camel-k/issues/4639#issuecomment-1669752083
> Is the configmap resource to be deleted after the build ? As we are not in charge of its creation it is like for other external configmap/secret used we do not take care of its lifecycle. We would still need it if we need to re-create the integration kit for any reason. The management of the configmap's lifecycle by the operator is an old issue : https://github.com/apache/camel-k/issues/1235. If a user want to ensure a configmap is not modified it could be declared as [immutable](https://kubernetes.io/docs/concepts/configuration/configmap/#configmap-immutable) but it doesn't avoid any change if it is deleted then recreated. > The use case scenarios are important to be able to test the different types of files, for example files with different encodings and not plain text files. One relevant aspect is the context are to be copied two times, so the task should ensure the final file is the same as the original. It depends on the code's ability to can manage configmap's data and binaryData. I don't know if binaryData works. And to check if two copies of a same context has the same result there is always digests compute. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
