]
Max Rydahl Andersen commented on JBIDE-18985:
---------------------------------------------
A few observations:
- not sure it fits in an enforcer plugin since enforcer rules are executed *before* the
build and used to check if the conditions of the build are correct - these versions checks
are more a check of the build result.
- *why* should the buildalias be the same for all ? that implies we are rebuilding
everything when we are trying to move to builds that only update components that actually
needed to change.
- and shouldn't this test be more about ensuring that the *delta* between the builds
are consistent. i.e. that it is not going back, always incrementing and if the SHA's
are different for the binary content that the versions/qualifiers have changed
accordingly. i.e. between two non-released milestones (4.2.0.Alpha1 and 4.2.0.Beta2) the
versions can stay the same even if content changes but the build qualifier timestamp
should at least be different and higher than the former. when a milestone is released
then the next milestones (i.e. 4.2.0.Final to 4.2.1.Alpha1) the content and version must
be exactly the same or the version MUST have bumped. If not then we did a rebuild without
actually bumping where it should have been bumped (that should be marked as Error/Red
build fail)
provide tool to audit BUILD_ALIAS in feature qualifiers when
aggregated
-----------------------------------------------------------------------
Key: JBIDE-18985
URL:
https://issues.jboss.org/browse/JBIDE-18985
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: build, updatesite
Affects Versions: 4.3.0.Alpha1
Reporter: Nick Boldt
Based on discussion {quote}Do you have a test for "expected BUILD_ALIAS value in
feature qualifiers" ?{quote}
Some tests we can run (forgive this pseudocode):
{code}
// for builds up to a x.y.0 release
if ((BUILD_ALIAS in (Alpha*, Beta*, CR*) and jbosstools.version endsWith(".0"))
{
// make sure all features end in the same BUILD_ALIAS, or Final
// if anything doesn't match WARN (want a build to be yellow, not red)
}
{code}
{code}
// for GA builds and followup maintenance
if ((BUILD_ALIAS in (Final, GA)) {
// make sure all com.* features end in GA, and all others end in Final
// if anything doesn't match FAIL (want a build to be red)
}
{code}
Once we have that coded, perhaps into a maven enforcer plugin?, we can fine tune it for
cases like where Freemarker does an update in Alpha and then does nothing for 4 months,
waiting for CR/GA.
Should they have to keep updating their root pom just so the BUILD_ALIAS matches and
they're building against the correct target platform?
Or, should their code remain dormant, but their job's config.xml be updated to
override the BUILD_ALIAS & TARGET_PLATFORM values to the correct versions?