Well crap. I found another odd dependency that throws off the masscheck
processing thrown off when commits are done outside the few hour window:
https://wiki.apache.org/spamassassin/InfraNotes2017#nitemc
automc@sa-vm1:~$ ~/svn/trunk/build/mkupdates/run_nightly
+ promote_active_rules
+ pwd
/usr/local/spamassassin/automc/svn/trunk
+ /usr/bin/perl build/mkupdates/listpromotable
HTTP get: http://ruleqa.spamassassin.org/1-days-ago?xml=1
no 'mcviewing', 'mcsubmitters' microformats on day 1
URL: http://ruleqa.spamassassin.org/1-days-ago?xml=1
+ exit 25
This is a critical cron job that sets up the new rule promotions daily.
I will dig into this one deeper but it seems that if the masscheck SA
revision gets out of sync with new commits that may not even be
ruleset-related, then days have to pass with no commits before the stars
will align properly again. Geez. What a mess with this workflow!
I think we need to carefully document the current SVN workflow and
redesign it to handle this better. The masscheck processing of rulesets
only needs to be tied to the ruleset revision staged in the rsync area
for the current 24 hour period. Maybe we need a new masscheck-specific
tag separate from the rule promotion tags today?
Rule promotions can happen at any time, multiple times a day as long as
they pass a lint check.
Masscheck validation are currently only done once a day.
My intial thoughts are parts of the scripts are using the latest SVN
revision and part are using the latest tagged revision from rule
promotions. When these get out of sync, we don't get enough
masschecking of the proper revision to keep moving everything forward.
Dave
On 11/02/2017 07:46 AM, Kevin A. McGrail wrote:
On 11/2/2017 8:40 AM, Merijn van den Kroonenberg wrote:
The checkout works as you would expect. But its just very confusing a
revision is used which is not inside the spamassassin project.
It might also cause side effects in other part of the process as David
mentioned. But the check out part is not actually broken.
I do have some considerable experience with subversion....the problem
is more what the intention of the code should be ;)
My recommendation is do not try and unravel the thought process behind
the code. Stay focused on the goal which is to produce rules and
distribute them. Anything you do towards that goal is good. If we
break some eggs to make some omelets, great.
Ideally, I would like to publish more daily rulesets, focus on
optimization, etc.
Regards,
KAM
