Conversation
The pom files for our published artifacts are sent to maven central during Elastic's release process, but we may not found out until then that we have inadvertently broken the pom structure, as has happened several times before. This commit adds validation of the pom file specifically for the rules required by maven central.
|
Pinging @elastic/es-core-infra (:Core/Infra/Build) |
mark-vieira
left a comment
There was a problem hiding this comment.
Left a couple of comments, otherwise LGTM.
|
|
||
| @Override | ||
| public void apply(Project project) { | ||
| project.getTasks().withType(GenerateMavenPom.class, generateMavenPom -> { |
There was a problem hiding this comment.
FWIW, doing withType here is going to eagerly create those generate pom tasks. But we are in a bit of a pickle becuase using configureEach is going to barf here as you can't register a task in a lazy task config block.
Perhaps we can key this off of the publications themselves instead of the generate pom task. We know for each publication there's going to be a generate pom task, maybe do that instead? So something like publishing.publications.all { // create validate task }?
I realize this is being a bit pedantic about not doing eager task creation but this seems like a challenge you're up to 😉
| import java.util.function.Consumer; | ||
| import java.util.function.Predicate; | ||
|
|
||
| public class PomValidationTask extends DefaultTask { |
There was a problem hiding this comment.
Should we make this extend PrecommitTask so it creates a marker file and thus could be UP-TO-DATE when the pom doesn't change? Right now this task will always run because it produces no output.
| @TaskAction | ||
| public void checkPom() throws Exception { | ||
| MavenXpp3Reader reader = new MavenXpp3Reader(); | ||
| Model model = reader.read(new FileReader(pomFile.getAsFile().get())); |
There was a problem hiding this comment.
We should probably put this in a try-with-resources block.
| validateNonNull("scm", model.getScm(), () -> validateString("scm.url", model.getScm().getUrl())); | ||
|
|
||
| if (foundError) { | ||
| throw new GradleException("Pom file [" + pomFile.getAsFile().get() + "] failed validation"); |
There was a problem hiding this comment.
Maybe add a message like "see console log for details".
There was a problem hiding this comment.
Also, let's use one of these verification failure prefixes so that when we search for failures in Gradle Enterprise, this kinds of failures show up as a "verification" failure, which is what it is.
|
@elasticmachine run elasticsearch-ci/docs |
The pom files for our published artifacts are sent to maven central during Elastic's release process, but we may not found out until then that we have inadvertently broken the pom structure, as has happened several times before. This commit adds validation of the pom file specifically for the rules required by maven central.
The pom files for our published artifacts are sent to maven central during Elastic's release process, but we may not found out until then that we have inadvertently broken the pom structure, as has happened several times before. This commit adds validation of the pom file specifically for the rules required by maven central.
The pom files for our published artifacts are sent to maven central during Elastic's release process, but we may not found out until then that we have inadvertently broken the pom structure, as has happened several times before. This commit adds validation of the pom file specifically for the rules required by maven central.
The pom files for our published artifacts are sent to maven central
during Elastic's release process, but we may not found out until then
that we have inadvertently broken the pom structure, as has happened
several times before. This commit adds validation of the pom file
specifically for the rules required by maven central.