Open Sgitario opened 2 years ago
This is big!
However, it can't be part of the pie workflow, as they can be extremely modified and break for irrelevant reasons.
Alternatives:
This is big!
However, it can't be part of the pie workflow, as they can be extremely modified and break for irrelevant reasons.
Alternatives:
- pre release workflow
- periodically
- post merge
+1
I will configure it to be triggered post merge (to detect breaking changes) + weekly (to get updates from sb examples)
@jacobdotcosta , atm the snowdrop spring boot examples are using 2.5.8.Beta1 which is not up to date with the repository and branch spring-boot-bom/sb-2.5.x.
To be concrete, I'm missing this line: https://github.com/snowdrop/spring-boot-bom/blob/sb-2.5.x/pom.xml#L127. As without this property, we can't overwrite the Dekorate version to use and therefore we can't implement this enhancement.
@jacobdotcosta do you know if the final version of the snowdrop-dependencies
bom dependency will be up to date and will include this property? Also, any estimation about when the bom dependency will be released?
I'm not sure I understand the problem with the pom.xml
file.
https://github.com/snowdrop/spring-boot-bom/blob/sb-2.5.x/pom.xml#L127 refers to the dekorate.version
version property which exists, and has the same value, on both the 2.5.8.Beta1 tag as well as on the 2.5.x branch.
I created a PR for checking the differences between branch 2.5.x and the 2.5.8.Beta1 tag and apparently the pom.xml
file is has exactly the same contents. https://github.com/snowdrop/spring-boot-bom/compare/sb-2.5.x...2.5.8.Beta1
@Sgitario can you clarify the issue?
PS I'm hoping we'll make the final release next week.
The problem is that 2.5.8.Beta1 has the dekorate version hardcoded in the dependencies, where in the sb-2.5.x, It's using a property dekorate.version.
I did check the 2.5.8.Beta1 from Maven repository and there is no property with dekorate.version: https://repo1.maven.org/maven2/dev/snowdrop/snowdrop-dependencies/2.5.8.Beta1/snowdrop-dependencies-2.5.8.Beta1.pom
Therefore, at some point, we're losing these properties.
I think this might be the culprit.
As of the Flatten Maven Plugin documentation, Its variables are resolved.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<inherited>false</inherited>
<executions>
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
<configuration>
<updatePomFile>true</updatePomFile>
<outputDirectory>${project.build.directory}/effective-pom</outputDirectory>
<flattenedPomFilename>snowdrop-dependencies.xml</flattenedPomFilename>
<flattenMode>oss</flattenMode>
<pomElements>
<dependencyManagement>expand</dependencyManagement>
<pluginManagement>expand</pluginManagement>
<properties>remove</properties>
<repositories>keep</repositories>
<pluginRepositories>keep</pluginRepositories>
</pomElements>
</configuration>
</execution>
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
I'll check if this flattening is a requirement or not.
Update: the snowdrop springboot bom has been fixed and we're waiting for the 2.5.8.Final
version to be released: https://search.maven.org/search?q=a:snowdrop-dependencies
The following repositories are using Dekorate to run the tests in OCP 3.11 and in K8s (using Helm):
Dekorate would be benefit of covering these examples to ensure we don't add breaking changes in Dekorate and increase the code coverage.
Moreover, the examples follow the same pattern to run the tests: using the same script, so the adoption and cost of maintenance would be minimal.