[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#911185: marked as done (commit hash not found in translation-check header breaks the wml build)

Your message dated Mon, 18 Feb 2019 15:31:26 +0100
with message-id <2508b7ac-f299-c189-4eaa-56df6c576dc8@debian.org>
and subject line commit hash not found in translation-check header breaks the wml build
has caused the Debian Bug report #911185,
regarding commit hash not found in translation-check header breaks the wml build
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
911185: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911185
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: www.debian.org
Severity: wishlist

Dear all
When there is a mistake in the hash of the translation-check header in a
wml file, the build fails. Here's an example when doing "make" with a
wml file with a translation-check header containing "test" instead of
the git hash:

wml -q -D CUR_YEAR=2018 -o UNDEFuES:index.es.html@g+w   index.wml
ePerl:Error: Perl runtime error (interpreter rc=0)

---- Contents of STDERR channel: ---------
count_changes() ERROR: commit rev1 test not found in revisions of
../..//english/reports/index.wml
------------------------------------------
** WML:Break: Error in Pass 3 (rc=1).
../../Makefile.common:119: recipe for target 'index.es.html' failed

I wonder if we'd like that instead of failing, the script would handle
this issue and build the page using the tag "originalolder" (then, the
translated file would be available, with a warning "Wrong translation
version!").

I'm attaching a patch that generates this behavior, but I have some
concerns:

* I'm not sure if we should change all the occurrences in the code where
a commit is not found from failure to this behaviour (see the diff, 4
occurrences)
* I'm not sure if we want that, or we prefer that the build fails and
make the CI not ignore these errors (then I guess the person committing
the file with wrong translation hash would get a mail, and hopefully fix
the file. If the page is built, maybe these kind of issues pass by
unnoticed).

Comments?

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

diff --git a/Perl/Local/VCS_git.pm b/Perl/Local/VCS_git.pm
index 9c76c0ba969..6f065f290a3 100644
--- a/Perl/Local/VCS_git.pm
+++ b/Perl/Local/VCS_git.pm
@@ -467,12 +467,12 @@ sub cmp_rev
 	}
 	if ($pos1 == -1) {
 	    # Not found
-	    print STDERR "ERROR: commit rev1 $rev1 not found in revisions of $file\n";
-	    $ret = undef;
+	    $self->_debug("WARNING: commit rev1 $rev1 not found in revisions of $file\n");
+	    $ret = -1;
 	} elsif ($pos2 == -1) {
 	    # Not found
-	    print STDERR "ERROR: commit rev2 $rev2 not found in revisions of $file\n";
-	    $ret = undef;
+	    $self->_debug("WARNING: commit rev2 $rev2 not found in revisions of $file\n");
+	    $ret = -1;
 	} elsif ($pos1 == $pos2) {
 	    $ret = 0;
 	} elsif ($pos1 < $pos2) {
@@ -562,12 +562,12 @@ sub count_changes
 	}
 	if ($pos1 == -1) {
 	    # Not found
-	    print STDERR "count_changes() ERROR: commit rev1 $rev1 not found in revisions of $file\n";
-	    $ret = undef;
+	    $self->_debug("count_changes() WARNING: commit rev1 $rev1 not found in revisions of $file\n");
+	    $ret = -1;
 	} elsif ($pos2 == -1) {
 	    # Not found
-	    print STDERR "count_changes() ERROR: commit rev2 $rev2 not found in revisions of $file\n";
-	    $ret = undef;
+	    $self->_debug("count_changes() WARNING: commit rev2 $rev2 not found in revisions of $file\n");
+	    $ret = -1;
 	} else {
 	    $ret = $pos1 - $pos2;
 	}

--- End Message ---
--- Begin Message --- 
Hi all

Automatic builds of the Debian website via Gitlab CI were setup during
September-October 2018 (see <20180914134901.GC29596@grep.be>
and <20181011191247.GA2733@grep.be>  (and the corresponding threads in
debian-www mailing list) for context).
The file README.gitlab-ci.yml on top of the webwml tree, when renamed to .gitlab-ci.yml, builds the website both for English and translations, and the result (the html files) can be browsed via artifacts. 

On November 2018 Salsa (Gitlab) settings for webwml project were set to keep
artifacts 1 week (default was 4 weeks) in order to save space.
Unfortunately the builds use too much resources, affecting salsa's ability
to serve other users.

So the settings were tweaked again to disable the use of shared runners,
and this file has been renamed from .gitlab-ci.yml to README_CI.gitlab-ci.yml
So, for now, to tackle the build breaks when commit hash is not found in translation-check headers, our recommendation for translators is to do "make" in the local folder prior to commit, to be sure that everything is ok.
Another option is that translators or committers can rename the README_CI.gitlab-ci.yml file to .gitlab-ci.yml in their salsa fork, and the CI build will run (occasionally) in their Salsa account.
I'm closing this bug, and open a new bug to document the status of GitLab's CI for the Debian website. 

Kind regards,
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

--- End Message ---
Reply to: