I'm using the release-plugin v2.5.1 and I'm often encountering two 
recurring stories with failed releases

1) Now the release can fail due to errors in the javadoc. This is not a 
problem, the problem is that IF there are problems in the javadoc the 
release doesn't complete but the two commits and the tag has been done so 
after fixing the javadoc I need to reset the git repo to right before the 
failed released AND I have to remove the tag to try again. I am releasing 
from jenkins so the resume flag is set to false. if something fails we 
start from the beginning, which makes sense in a build server IMO. My 
suggestion here would be to generate all those artifacts (javadoc and 
source) before committing and tagging the code, that way if they fail, the 
repo is not in an invalid state. Another option would be improvement #2

2) Very often the dryRun succeeds but the real release fails, to the point 
where the dryRun is meaningless. This defeats the whole purpose of a 
dry-run. The problem is that the dry run is over simplified. For example, 
again, if there are javadoc problems they won't be spotted because the 
dry-run doesn't run javadoc generation. Anything that's part of the real 
build should be run on the dry-run except for things that make persistent 
changes. Another problem I encounter often is that the real release fails 
because the tag already exists in SCM (leftover from a previous failed 
release). This should also be validated by the dryRun. If a real release 
can fail because a tag is already present then the dry run should fail if 
the tag is already present

What do you guys think? If these points are considered valid I will open a 
ticket at least for the second one, which is the worse of the two


Alejandro Endo | Software Designer/Concepteur de logiciels 


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Reply via email to