[JIRA] (OVIRT-1385) Support installing latest version of specific pkgs

[Vojtech Szocs (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vojtech Szocs updated OVIRT-1385:
-
Description: 
​There are multiple oVirt projects (see below) which contain a 
{{build.packages.force}} (or similar) file, along with the following code in 
their build script:

{code}
# The "build.packages.force" file contains BuildRequires packages
# to be installed using their latest version.
# Force CI to get the latest version of these packages:
dependencies="$(sed -e '/^[ \t]*$/d' -e '/^#/d' 
automation/build.packages.force)"
yum-deprecated clean metadata || yum clean metadata
yum-deprecated -y install ${dependencies} || yum -y install ${dependencies}
{code}

Used in projects: ovirt-engine-dashboard, ovirt-engine-nodejs-modules, 
ovirt-web-ui

Is it possible for CI to support this out of the box, using {{.force}} file 
convention? (basically a suffix to standard {{.packages}} files)

I've looked at OVIRT-921 and IIUC the yum cache is cleaned every 2 days, so an 
alternative to above proposal would be to have this interval configurable 
per-project.

Not sure what's the best approach here, please advise.

  was:
​There are multiple oVirt projects [1] which contain a
`build.packages.force` (or similar) file, along with the following code in
their build script:

  # The "build.packages.force" file contains BuildRequires packages
  # to be installed using their latest version.
  # Force CI to get the latest version of these packages:
  dependencies="$(sed -e '/^[ \t]*$/d' -e '/^#/d'
automation/build.packages.force)"
  yum-deprecated clean metadata || yum clean metadata
  yum-deprecated -y install ${dependencies} || yum -y install
${dependencies}

[1] ovirt-engine-dashboard, ovirt-engine-nodejs-modules, ovirt-web-ui

Is it possible for CI to support this out of the box, using .force file
convention? (basically a suffix to standard .packages files)

I've looked at OVIRT-921 and IIUC the yum cache is cleaned every 2 days, so
an alternative to above proposal would be to have this configurable
per-project.

Not sure what's the best approach here, please advise.


> Support installing latest version of specific pkgs
> --
>
> Key: OVIRT-1385
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1385
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Vojtech Szocs
>Assignee: infra
>
> ​There are multiple oVirt projects (see below) which contain a 
> {{build.packages.force}} (or similar) file, along with the following code in 
> their build script:
> {code}
> # The "build.packages.force" file contains BuildRequires packages
> # to be installed using their latest version.
> # Force CI to get the latest version of these packages:
> dependencies="$(sed -e '/^[ \t]*$/d' -e '/^#/d' 
> automation/build.packages.force)"
> yum-deprecated clean metadata || yum clean metadata
> yum-deprecated -y install ${dependencies} || yum -y install ${dependencies}
> {code}
> Used in projects: ovirt-engine-dashboard, ovirt-engine-nodejs-modules, 
> ovirt-web-ui
> Is it possible for CI to support this out of the box, using {{.force}} file 
> convention? (basically a suffix to standard {{.packages}} files)
> I've looked at OVIRT-921 and IIUC the yum cache is cleaned every 2 days, so 
> an alternative to above proposal would be to have this interval configurable 
> per-project.
> Not sure what's the best approach here, please advise.



--
This message was sent by Atlassian JIRA
(v1000.967.1#100042)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-1385) Support installing latest version of specific pkgs

[Vojtech Szocs (oVirt JIRA)]

Vojtech Szocs created OVIRT-1385:


 Summary: Support installing latest version of specific pkgs
 Key: OVIRT-1385
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1385
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Vojtech Szocs
Assignee: infra


​There are multiple oVirt projects [1] which contain a
`build.packages.force` (or similar) file, along with the following code in
their build script:

  # The "build.packages.force" file contains BuildRequires packages
  # to be installed using their latest version.
  # Force CI to get the latest version of these packages:
  dependencies="$(sed -e '/^[ \t]*$/d' -e '/^#/d'
automation/build.packages.force)"
  yum-deprecated clean metadata || yum clean metadata
  yum-deprecated -y install ${dependencies} || yum -y install
${dependencies}

[1] ovirt-engine-dashboard, ovirt-engine-nodejs-modules, ovirt-web-ui

Is it possible for CI to support this out of the box, using .force file
convention? (basically a suffix to standard .packages files)

I've looked at OVIRT-921 and IIUC the yum cache is cleaned every 2 days, so
an alternative to above proposal would be to have this configurable
per-project.

Not sure what's the best approach here, please advise.



--
This message was sent by Atlassian JIRA
(v1000.967.1#100042)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-1057) Please create new Gerrit repos

[Vojtech Szocs (oVirt JIRA)]

Vojtech Szocs created OVIRT-1057:


 Summary: Please create new Gerrit repos
 Key: OVIRT-1057
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1057
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Vojtech Szocs
Assignee: infra


Hi,

please create the following Gerrit repos:

* ovirt-engine-nodejs
* ovirt-engine-yarn
* ovirt-engine-nodejs-modules

so that we can move the corresponding projects out of releng-tools and have
them utilize the standard CI infra.

Thanks,
Vojtech



--
This message was sent by Atlassian JIRA
(v1000.695.1#100025)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: upgrade job failures

[Vojtech Szocs]

Hi,

the patch that triggered the failed build is for ovirt-engine-4.1 branch
and `yum -y install ovirt-engine` fails on dep. resolution because

  ovirt-engine-dashboard-1.2.0-0.1.20170105gitcb8e435.el7.centos.noarch

Dashboard 1.y == Engine 4.y by convention. I guess the CI job has wrong
repo? The Dashboard RPM should instead be something like

  ovirt-engine-dashboard-1.1.x

Vojtech


- Original Message -
> From: "Greg Sheremeta" 
> To: "Daniel Belenky" 
> Cc: "infra" 
> Sent: Tuesday, January 10, 2017 4:41:10 PM
> Subject: Re: upgrade job failures
> 
> Seems to be still not working.
> 
> Greg Sheremeta, MBA
> Red Hat, Inc.
> gsher...@redhat.com
> 
> On Jan 10, 2017 10:31 AM, "Daniel Belenky" < dbele...@redhat.com > wrote:
> 
> 
> 
> Hi Greg,
> 
> The error you see was caused by wrong RPMs in the snapshot repo. We are
> currently working on new upgrade jobs that will replace the old ones.
> I've changed the configuration in Jenkins to take RPMs from latest.tested
> repo, and re-triggered the build.
> I assume that this should resolve the issue Jenkins console
> 
> 
> On Tue, Jan 10, 2017 at 4:13 PM, Greg Sheremeta < gsher...@redhat.com >
> wrote:
> 
> 
> 
> Hi,
> 
> What do I need to do to fix this?
> 
> " Error: Package:
> ovirt-engine-dashboard-1.2.0-0.1.20170105gitcb8e435.el7.centos.noarch
> (upgrade_to_0)
> Requires: ovirt-engine-webadmin-portal >= 4.2
> "
> 
> http://jenkins.ovirt.org/job/ovirt-engine_4.1_upgrade-from-3.6_el7_merged/129/console
> 
> 
> 
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
> 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
> 
> 
> 
> --
> Daniel Belenky
> RHV DevOps
> Red Hat Israel
> 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-973) nightly ovirt-engine build is missing Chrome permutation

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25095#comment-25095
 ] 

Vojtech Szocs commented on OVIRT-973:
-

bq. How much time it will add if we'll add chrome to the permutations?
At least +50% GWT build time, I'd say.

bq. I wouldn't want to pay a constant time penalty just because a single manual 
test needed it.
Agreed. GWT Chrome build should be opt-in, only when needed.

bq. You can easily send a patch to build-artifacts with the permutations you 
want and then use the 'build-on-demand' job using 'ci please build' to build 
rpms using the new PARAMS.
Good point, but can we have a "long standing" (forever open) patch for this 
purpose?

Just to clarify, what I meant in my previous comment was this:
1, user gets a nightly Engine build (FF-only)
2, user decides he/she needs Chrome support for that particular build
3, user re-triggers the particular build and passes some param (defined in 
Jenkins job config and somehow passed to build script) to trigger Chrome GWT 
permutation

> nightly ovirt-engine build is missing Chrome permutation
> 
>
> Key: OVIRT-973
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-973
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: Jenkins
>Reporter: Greg Sheremeta
>Assignee: infra
>
> mburman [reports|https://bugzilla.redhat.com/show_bug.cgi?id=1400010] that 
> the nightly ovirt-engine build is missing the Chrome permutation.
> From the 
> [build|http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/2068/consoleFull]:
> {noformat}
> 21:13:24 [INFO]Compiling 1 permutation
> 21:13:24 [INFO]   Compiling permutation 0...
> 21:16:54 [INFO]Compile of permutations succeeded
> {noformat}
> That should compile 2 if we want Firefox and Chrome, or 3 if we also want IE.
> mburman reports this started on November 30. I'm not sure what changed.
> Adding build flags will fix:
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"



--
This message was sent by Atlassian JIRA
(v1000.621.5#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-973) nightly ovirt-engine build is missing Chrome permutation

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25068#comment-25068
 ] 

Vojtech Szocs commented on OVIRT-973:
-

Alternatively, provide a way to retrigger the nightly build with some parameter 
enabling the Chrome GWT permutation.

> nightly ovirt-engine build is missing Chrome permutation
> 
>
> Key: OVIRT-973
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-973
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: Jenkins
>Reporter: Greg Sheremeta
>Assignee: infra
>
> mburman [reports|https://bugzilla.redhat.com/show_bug.cgi?id=1400010] that 
> the nightly ovirt-engine build is missing the Chrome permutation.
> From the 
> [build|http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/2068/consoleFull]:
> {noformat}
> 21:13:24 [INFO]Compiling 1 permutation
> 21:13:24 [INFO]   Compiling permutation 0...
> 21:16:54 [INFO]Compile of permutations succeeded
> {noformat}
> That should compile 2 if we want Firefox and Chrome, or 3 if we also want IE.
> mburman reports this started on November 30. I'm not sure what changed.
> Adding build flags will fix:
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"



--
This message was sent by Atlassian JIRA
(v1000.621.5#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-973) nightly ovirt-engine build is missing Chrome permutation

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25067#comment-25067
 ] 

Vojtech Szocs edited comment on OVIRT-973 at 1/2/17 4:04 PM:
-

{quote}Adding build flags will fix:
DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"{quote}
This works only when running {{make}} directly, e.g. on local dev. env.

To properly support Firefox + Chrome (English only) build, we should modify the 
{{rpmbuild}} command in {{build-artifacts.sh}} script:
{quote}ovirt_build_ut 0
ovirt_build_all_user_agents 0
ovirt_build_locales 0
ovirt_build_extra_flags -D gwt.userAgent=gecko1_8,safari{quote}


was (Author: vojtech):
{quote}Adding build flags will fix:
DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"{quote}
This works only when running {{make}} directly, e.g. on local dev. env.

To properly support Firefox + Chrome (English only) build, we should modify the 
{{rpmbuild}} command in {{build-artifacts.sh}} script:
{quote}ovirt_build_ut 0
ovirt_build_all_user_agents 0
ovirt_build_locales 0
ovirt_build_extra_flags -D gwt.userAgent=gecko1_8*,safari*{quote}

> nightly ovirt-engine build is missing Chrome permutation
> 
>
> Key: OVIRT-973
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-973
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: Jenkins
>Reporter: Greg Sheremeta
>Assignee: infra
>
> mburman [reports|https://bugzilla.redhat.com/show_bug.cgi?id=1400010] that 
> the nightly ovirt-engine build is missing the Chrome permutation.
> From the 
> [build|http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/2068/consoleFull]:
> {noformat}
> 21:13:24 [INFO]Compiling 1 permutation
> 21:13:24 [INFO]   Compiling permutation 0...
> 21:16:54 [INFO]Compile of permutations succeeded
> {noformat}
> That should compile 2 if we want Firefox and Chrome, or 3 if we also want IE.
> mburman reports this started on November 30. I'm not sure what changed.
> Adding build flags will fix:
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"



--
This message was sent by Atlassian JIRA
(v1000.621.5#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-973) nightly ovirt-engine build is missing Chrome permutation

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25067#comment-25067
 ] 

Vojtech Szocs edited comment on OVIRT-973 at 1/2/17 4:03 PM:
-

{quote}Adding build flags will fix:
DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"{quote}
This works only when running {{make}} directly, e.g. on local dev. env.

To properly support Firefox + Chrome (English only) build, we should modify the 
{{rpmbuild}} command in {{build-artifacts.sh}} script:
{quote}ovirt_build_ut 0
ovirt_build_all_user_agents 0
ovirt_build_locales 0
ovirt_build_extra_flags -D gwt.userAgent=gecko1_8*,safari*{quote}


was (Author: vojtech):
{quote}Adding build flags will fix:
DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"{quote}
This works only when running {{make}} directly, e.g. on local dev. env.

To properly support Firefox + Chrome (English only) build, we should modify the 
{{rpmbuild}} command in {{build-artifacts.sh}} script:
{quote}ovirt_build_ut 0
ovirt_build_all_user_agents 0
ovirt_build_locales 0
ovirt_build_extra_flags -D gwt.userAgent=gecko1_8,safari{quote}

> nightly ovirt-engine build is missing Chrome permutation
> 
>
> Key: OVIRT-973
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-973
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: Jenkins
>Reporter: Greg Sheremeta
>Assignee: infra
>
> mburman [reports|https://bugzilla.redhat.com/show_bug.cgi?id=1400010] that 
> the nightly ovirt-engine build is missing the Chrome permutation.
> From the 
> [build|http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/2068/consoleFull]:
> {noformat}
> 21:13:24 [INFO]Compiling 1 permutation
> 21:13:24 [INFO]   Compiling permutation 0...
> 21:16:54 [INFO]Compile of permutations succeeded
> {noformat}
> That should compile 2 if we want Firefox and Chrome, or 3 if we also want IE.
> mburman reports this started on November 30. I'm not sure what changed.
> Adding build flags will fix:
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"



--
This message was sent by Atlassian JIRA
(v1000.621.5#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-973) nightly ovirt-engine build is missing Chrome permutation

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25067#comment-25067
 ] 

Vojtech Szocs commented on OVIRT-973:
-

{quote}Adding build flags will fix:
DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"{quote}
This works only when running {{make}} directly, e.g. on local dev. env.

To properly support Firefox + Chrome (English only) build, we should modify the 
{{rpmbuild}} command in {{build-artifacts.sh}} script:
{quote}ovirt_build_ut 0
ovirt_build_all_user_agents 0
ovirt_build_locales 0
ovirt_build_extra_flags -D gwt.userAgent=gecko1_8,safari{quote}

> nightly ovirt-engine build is missing Chrome permutation
> 
>
> Key: OVIRT-973
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-973
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: Jenkins
>Reporter: Greg Sheremeta
>Assignee: infra
>
> mburman [reports|https://bugzilla.redhat.com/show_bug.cgi?id=1400010] that 
> the nightly ovirt-engine build is missing the Chrome permutation.
> From the 
> [build|http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/2068/consoleFull]:
> {noformat}
> 21:13:24 [INFO]Compiling 1 permutation
> 21:13:24 [INFO]   Compiling permutation 0...
> 21:16:54 [INFO]Compile of permutations succeeded
> {noformat}
> That should compile 2 if we want Firefox and Chrome, or 3 if we also want IE.
> mburman reports this started on November 30. I'm not sure what changed.
> Adding build flags will fix:
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"



--
This message was sent by Atlassian JIRA
(v1000.621.5#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-973) nightly ovirt-engine build is missing Chrome permutation

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25066#comment-25066
 ] 

Vojtech Szocs commented on OVIRT-973:
-

bq. mburman reports this started on November 30. I'm not sure what changed.
This is caused by [build-artifacts.sh 
patch|https://gerrit.ovirt.org/#/c/67269/], merged into master on Nov 29, which 
enabled the "minimal" GWT build (*Firefox only*, English only).

See the related [oVirt devel 
thread|http://lists.ovirt.org/pipermail/devel/2016-September/028295.html].

I think it's more sensible (even though a bit more expensive CI-wise) to 
support Firefox *and* Chrome when doing Engine nightly builds.

> nightly ovirt-engine build is missing Chrome permutation
> 
>
> Key: OVIRT-973
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-973
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: Jenkins
>Reporter: Greg Sheremeta
>Assignee: infra
>
> mburman [reports|https://bugzilla.redhat.com/show_bug.cgi?id=1400010] that 
> the nightly ovirt-engine build is missing the Chrome permutation.
> From the 
> [build|http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/2068/consoleFull]:
> {noformat}
> 21:13:24 [INFO]Compiling 1 permutation
> 21:13:24 [INFO]   Compiling permutation 0...
> 21:16:54 [INFO]Compile of permutations succeeded
> {noformat}
> That should compile 2 if we want Firefox and Chrome, or 3 if we also want IE.
> mburman reports this started on November 30. I'm not sure what changed.
> Adding build flags will fix:
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari,gecko1_8"



--
This message was sent by Atlassian JIRA
(v1000.621.5#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Ability to run [job-name] when a tag is pushed to Gerrit

[Vojtech Szocs]

- Original Message -
> From: "Barak Korren" <bkor...@redhat.com>
> To: "Vojtech Szocs" <vsz...@redhat.com>
> Cc: "Eyal Edri" <ee...@redhat.com>, "infra" <infra@ovirt.org>
> Sent: Thursday, December 15, 2016 5:45:54 PM
> Subject: Re: Ability to run [job-name] when a tag is pushed to Gerrit
> 
> On 14 December 2016 at 19:18, Vojtech Szocs <vsz...@redhat.com> wrote:
> >
> > If I'm reading [a] correctly, Jenkins Gerrit trigger (Jenkins plugin)
> > doesn't explicitly support "tag pushed" event, which is strange (?),
> > there is only "Ref Updated" which should include tag pushes.
> 
> Its not the Gerrit trigger that is at fault here, its just the way the
> event that Gerrit sends looks like. Which is to mean, Gerrit doesn't
> have a specific event for tags.

Right, Jenkins Gerrit trigger just listens to events published through
Gerrit's event stream.

> 
> > So if it's not very feasible to implement e.g. "on-tag-push" trigger,
> > I'm OK with [2] - posting Gerrit comment on (already merged & tagged)
> > patch to re-trigger the build-artifacts job.
> 
> Well, it may be feasible, but we don`t have any pre-existing
> experience doing that, so it'll take some trial and error to get done
> right, and perhaps some limitations may need to be in place (For
> example, on the format that tag string can have, so we can
> differentiate if from branches).

Ideally, one could specify tag name prefix in Jenkins job YAML :-)

Also, found this: http://stackoverflow.com/a/21605984

I'm also OK with what Eyal proposed: manually triggering the build
job [build-artifacts] by posting a comment on Gerrit web.

> 
> 
> --
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Ability to run [job-name] when a tag is pushed to Gerrit

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" <ee...@redhat.com>
> To: "Barak Korren" <bkor...@redhat.com>
> Cc: "Vojtech Szocs" <vsz...@redhat.com>, "infra" <infra@ovirt.org>
> Sent: Monday, December 12, 2016 7:16:44 PM
> Subject: Re: Ability to run [job-name] when a tag is pushed to Gerrit
> 
> I've started [1], didn't got time to finish it though,
> But the idea is to allow anyone who wants to build artifacts from a patch
> to do so by add comment "ci please build".

As Barak pointed below, to address my original request, we could have
some (e.g. "on-tag-push") job trigger that could be used in job conf.

If I'm reading [a] correctly, Jenkins Gerrit trigger (Jenkins plugin)
doesn't explicitly support "tag pushed" event, which is strange (?),
there is only "Ref Updated" which should include tag pushes.

[a] 
https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger#GerritTrigger-TriggerConfiguration

So if it's not very feasible to implement e.g. "on-tag-push" trigger,
I'm OK with [2] - posting Gerrit comment on (already merged & tagged)
patch to re-trigger the build-artifacts job.

> There is already an open Jira on it [2], though maybe its not exactly the
> same use case.
> 
> I was suggestion what you are saying as preparation for automating official
> builds, but we didn't got around to do it yet,
> and currently the focus and priority is on oVirt Gating, but if its
> something simple like [1] we can probably work with developers to add it if
> it has lot of value.
> Lets star with [1] and see if it answer some of the existing needs.

Agreed, +1 on OVIRT-920.

> 
> [1] https://gerrit.ovirt.org/#/c/68017/
> [2] https://ovirt-jira.atlassian.net/browse/OVIRT-920
> 
> On Mon, Dec 12, 2016 at 7:10 PM, Barak Korren <bkor...@redhat.com> wrote:
> 
> > On 12 December 2016 at 18:48, Vojtech Szocs <vsz...@redhat.com> wrote:
> > >
> > > this was discussed loong time ago.. how much effort would it take
> > > for oVirt CI infra to support running e.g. [build-artifacts] when
> > > a git tag is pushed to Gerrit repo?
> > >
> >
> > Its just a YAML patch to copy the existing build_artifacts job, give
> > it a new name and change the trigger configuration.
> >
> > But the trigger may be a little tricky, since the Jenkins Gerrit
> > trigger does not have a specific event for tags, instead it has a
> > "Reference updated" event. So we may need to play a little with
> > filtering to ensure this gets called only for tag updates and not for
> > branch updates...
> >
> > I guess you will need our (infra) help, do we have a Jira ticket to track
> > this?
> >
> > --
> > Barak Korren
> > bkor...@redhat.com
> > RHCE, RHCi, RHV-DevOps Team
> > https://ifireball.wordpress.com/
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.phx.ovirt.org/mailman/listinfo/infra
> >
> >
> >
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.phx.ovirt.org/mailman/listinfo/infra

Ability to run [job-name] when a tag is pushed to Gerrit

[Vojtech Szocs]

Hi,

this was discussed loong time ago.. how much effort would it take
for oVirt CI infra to support running e.g. [build-artifacts] when
a git tag is pushed to Gerrit repo?

Imagine the following situation:

1, new tag is pushed -or- existing tag gets updated (force push)

2, CI infra detects the new/updated tag and runs [job-name-here]
   on the relevant (tagged) commit

I'm asking this because in oVirt Dashboard, we're making releases
from tagged commits, so we basically:

- merge patch that prepares the (stable) branch for release
- tag the release-prep patch & push tag to Gerrit
- re-trigger [build-artifacts] for the release-prep patch

Thanks,
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.phx.ovirt.org/mailman/listinfo/infra

Re: export ovirt-engine-dashboard gerrit repo to github?

[Vojtech Szocs]

+1

Dashboard uses modern JS technologies and it would be
a nice showcase for anyone interested in UI plugins.

Vojtech


- Original Message -
> From: "Scott Dickerson" <sdick...@redhat.com>
> To: infra@ovirt.org
> Cc: "Vojtech Szocs" <vsz...@redhat.com>
> Sent: Thursday, October 6, 2016 5:53:17 PM
> Subject: export ovirt-engine-dashboard gerrit repo to github?
> 
> Hi,
> 
> What do we need to do in order to get the ovirt-engine-dashboard gerrit
> repo [1] mirrored/exported out to oVirt's github [2] in the same way
> ovirt-engine does?
> 
> [1] - https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=summary
> [2] - https://github.com/oVirt
> 
> Thanks,
> Scott
> 
> --
> Scott Dickerson
> Senior Software Engineer
> RHEV-M Engineering - UX Team
> Red Hat, Inc
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Vojtech Szocs]

Hi,

to me, it seems that with current CI flow, we can do following:

- in build-artifacts.sh, build UI for English (only) & all supported
  browsers (IE10+, Firefox, Chrome), by using `ovirt_build_locales 0`
  as the default fallback

  Note: this will cut down the # of permutations from 3x9 to just 3
  (currently we have 3 supported browser types, 9 supported locales).

- ensure that release builds still target all supported UI locales,
  by using `ovirt_build_locales 1` (override the default fallback)

- it would be nice if the Jenkins job for build-artifacts.sh would
  set some `RELEASE=1` flag (or similar) when doing a release build
  (is this possible with current standard CI?)

Eyal/others, does above make sense?

Also, as Nir mentioned, if `ovirt-engine` repo was configured with
Submit Type == Fast Forward Only, we could drop RPM / GWT build in
check-merged.sh (which was Eyal's original suggestion).

Regards,
Vojtech


- Original Message -
> From: "Nir Soffer" 
> To: "Eyal Edri" 
> Cc: "Juan Hernandez" , "devel" , 
> "Martin Perina" , "Tal
> Nisan" , "infra" 
> Sent: Tuesday, September 20, 2016 5:38:08 PM
> Subject: Re: Dropping rpm build from ovirt-engine check-merged.sh
> 
> On Tue, Sep 20, 2016 at 11:27 AM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> 
> 
> On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola < sbona...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> 
> 
> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola < sbona...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> Hi,
> 
> Following [1] I'd like to propose to remove rpm building from the
> 'check-merged.sh' script from ovirt-engine (master for now).
> 
> The job [2] takes on avg 15 min while actually the rpms are built already in
> check-patch
> (with gwt draft mode if needed) and runs exactly the same build rpm command
> as check-patch [3].
> 
> So there isn't real value in running exactly the same rpm build post merge,
> and we already build full permutation mode in 'build-artifacts.sh'.
> 
> Any reason to keep it?
> We can cut down valuable time in CI if we drop it and vacant more time for
> more meaningful tests.
> 
> 
> This depends on the flow: if we make check_merge gating to the merge and to
> the build we should keep the rpm build becuase at merge a rebase is done
> automatically.
> 
> What do you mean by 'gating to the merge'? I'm not sure I understand what it
> means.
> Isn't check-patch.sh does the gating? check-merge runs post merge so its
> already too late to gate the code ...
> And I think check-merge and check-patch currently runs the same rpmbuild
> command, so I don't see how check-merged has any value over check-patch.
> 
> when merge command is issued a rebase is done as well. We still need a
> check-merged job because the code checked by check-patch is not the same
> anymore when check-merged runs.
> 
> OK, now I understand, so indeed check-merge can potentially run on different
> code than check-patch and possibly fail due to it.
> 
> If we require only fast-forward merges, there is no way to merge patch
> before a rebase. Once you rebase a patch, check-patch runs...
> 
> So check-merge may be unneeded in this case.
> 
> 
> 
> 
> 
> 
> In original desing of stdci, check-merged was supposed to become a gating
> test for build-artifacts.
> 
> We have it in our backlog, i.e installing Zuul and adding gating for the
> check-merged jobs, its mostly relevant for system jobs, but we can defiently
> do it first for simple 'check-merged.sh' jobs
> as part of standard CI.
> 
> Opened a ticket for it [1]
> 
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-734
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> If there's not gating process performed by check-merge then I agree in
> dropping rpm build.
> 
> 
> 
> 
> 
> 
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> [2]
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-merged-el7-x86_64/buildTimeTrend
> [3]
> rpmbuild \
> -D "_rpmdir $PWD/output" \
> -D "_topmdir $PWD/rpmbuild" \
> -D "release_suffix ${SUFFIX}" \
> -D "ovirt_build_ut $BUILD_UT" \
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> -D "ovirt_build_draft 1" \
> --rebuild output/*.src.rpm
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> 
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> 
> 
> --
> Sandro Bonazzola
> Better 

Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

[Vojtech Szocs]

- Original Message -
> From: "Sandro Bonazzola" 
> To: "Eyal Edri" 
> Cc: "Juan Hernandez" , "infra" , 
> "devel" 
> Sent: Monday, September 19, 2016 8:41:12 AM
> Subject: Re: [ovirt-devel] Dropping rpm build from ovirt-engine   
> check-merged.sh
> 
> 
> 
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> Hi,
> 
> Following [1] I'd like to propose to remove rpm building from the
> 'check-merged.sh' script from ovirt-engine (master for now).
> 
> The job [2] takes on avg 15 min while actually the rpms are built already in
> check-patch
> (with gwt draft mode if needed) and runs exactly the same build rpm command
> as check-patch [3].
> 
> So there isn't real value in running exactly the same rpm build post merge,
> and we already build full permutation mode in 'build-artifacts.sh'.
> 
> Any reason to keep it?
> We can cut down valuable time in CI if we drop it and vacant more time for
> more meaningful tests.
> 
> 
> This depends on the flow: if we make check_merge gating to the merge and to
> the build we should keep the rpm build becuase at merge a rebase is done
> automatically.
> If there's not gating process performed by check-merge then I agree in
> dropping rpm build.

First of all, for oVirt Engine snapshot (non-release) builds, we should
avoid doing a full GWT compilation [all browsers x all locales]. That's
simply because the full GWT compilation is too costly for CI to run on
a regular basis.

Doing [Firefox + Chrome x English = 2 permutations] && [draft GWT build
option enabled] for snapshot builds should be enough.

The *only* downside of not doing a full GWT build is that problems with
localization resources [e.g. non-English .properties files] will not be
reported by the GWT compiler. But we have Java unit tests to cover this,
so it should be OK. (And if not, we must improve those tests.)

In general, we should do a full GWT compilation only for release builds.
Eyal mentioned at [1] that his team is working on

  'build official manual' option to standard CI

so that would be a great place to document & perform the full GWT build.

As for build jobs: if `check-merged` is indeed acting as gate for merge
[fail of `check-merged` => patch not merged, `build-artifacts` does not
execute], then it actually makes sense to:

- keep `check-merged` doing a (draft) GWT build + Engine RPM build
- maybe skip GWT build in `check-patch` [right now, there's detection
  logic => if frontend files were changed, do GWT build]

Otherwise, if `check-merged` doesn't act as gate for merge, we can just
skip GWT build / Engine RPM build for that script.

> 
> 
> 
> 
> 
> 
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> [2]
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-merged-el7-x86_64/buildTimeTrend
> [3]
> rpmbuild \
> -D "_rpmdir $PWD/output" \
> -D "_topmdir $PWD/rpmbuild" \
> -D "release_suffix ${SUFFIX}" \
> -D "ovirt_build_ut $BUILD_UT" \
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> -D "ovirt_build_draft 1" \
> --rebuild output/*.src.rpm
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> 
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=20827#comment-20827
 ] 

Vojtech Szocs commented on OVIRT-416:
-

> So the question is, can we reduce this to 1-2 permutations? if this is just 
> going to nightly / hourly repo then we don't need all these permutations and 
> we'll enjoy a much faster verification on the experimental flow which 
> collects artifacts from build-artifacts jobs.

+1

Full GWT build (all browsers & languages) is not needed for oVirt nightly 
(snapshot) builds. It's only needed for oVirt official (release) builds.

> We are now adding the 'build official manual' option to standard CI, so we 
> can keep the 27 permutations there for official builds. 

Sounds good to me.

> [standard-ci] build-artifacts should reuse the artifacts built on 
> check-merged if any
> -
>
> Key: OVIRT-416
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-416
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: David Caro Estevez
>Assignee: infra
>
> Right now most projects just rebuild twice the artifacts, what for some means 
> a big waste of resources, if we could just reuse what was built previously 
> there would be no rebuilding.
> Something to take into account is that the distributions that check-merged 
> and build-artifacts run for might not match, so you can be running 
> check-merged only on fc23 but building artifacts for fc23, fc22 an el7 (as an 
> example), maybe we should not allow different distros on each stage?|



--
This message was sent by Atlassian JIRA
(v1000.319.1#100012)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-668) ovirt-engine-nodejs-modules errors

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=19215#comment-19215
 ] 

Vojtech Szocs commented on OVIRT-668:
-

RPM build of {{ovirt-engine-nodejs-modules}} is now fixed, relevant patches are 
[here|https://gerrit.ovirt.org/#/c/61790/] and 
[here|https://gerrit.ovirt.org/#/c/61828/].

The rpmbuild limitation (due to 100k+ files contained) was worked around by 
putting all files in a tarball and extracting it upon RPM install.

We can close this ticket :)

> ovirt-engine-nodejs-modules errors
> --
>
> Key: OVIRT-668
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-668
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: sbonazzo
>Assignee: infra
>
> *Hi, looks like something happened during a build:
> **http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_4.0_create-rpms-el7-x86_64_created/8/console
> <http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_4.0_create-rpms-el7-x86_64_created/8/console>*
> *00:08:50.299* + exit 0*00:18:36.484* Provides:
> ovirt-engine-nodejs-modules = 0.0.10-1.el7
> ovirt-engine-nodejs-modules(x86-64) = 0.0.10-1.el7*00:18:36.484*
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1*00:18:36.485* Requires:
> /bin/bash /bin/sh /usr/bin/env ld-linux-x86-64.so.2()(64bit)
> ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libc.so.6()(64bit)
> libc.so.6(GLIBC_2.10)(64bit) libc.so.6(GLIBC_2.2.5)(64bit)
> libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit)
> libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.9)(64bit)
> libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit)
> libfontconfig.so.1()(64bit) libfreetype.so.6()(64bit)
> libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit)
> libgcc_s.so.1(GCC_3.4)(64bit) libm.so.6()(64bit)
> libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit)
> libpthread.so.0(GLIBC_2.2.5)(64bit)
> libpthread.so.0(GLIBC_2.3.2)(64bit)
> libpthread.so.0(GLIBC_2.3.3)(64bit) librt.so.1()(64bit)
> librt.so.1(GLIBC_2.2.5)(64bit) libstdc++.so.6()(64bit)
> libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit)
> libstdc++.so.6(GLIBCXX_3.4)(64bit)
> libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
> libstdc++.so.6(GLIBCXX_3.4.9)(64bit) libz.so.1()(64bit)
> libz.so.1(ZLIB_1.2.0)(64bit)*00:18:36.515* Checking for unpackaged
> file(s): /usr/lib/rpm/check-files
> /builddir/rpmbuild/BUILDROOT/ovirt-engine-nodejs-modules-0.0.10-1.el7.x86_64*00:18:40.184*
> Wrote: 
> /tmp/ovirt-engine-nodejs-modules/ovirt-engine-nodejs-modules-0.0.10-1.el7.src.rpm*00:18:40.185*
> error: Unable to create immutable header region.
> Note it got stuck for 10 minutes and then failed with an error that seems
> infra releated.
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com



--
This message was sent by Atlassian JIRA
(v1000.217.1#18)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-669) Please add Gerrit hooks for project ovirt-engine-dashboard

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" <ee...@redhat.com>
> To: "Vojtech Szocs (oVirt JIRA)" <j...@ovirt-jira.atlassian.net>
> Cc: "infra" <infra@ovirt.org>
> Sent: Tuesday, August 2, 2016 3:27:39 PM
> Subject: Re: [JIRA] (OVIRT-669) Please add Gerrit hooks for project   
> ovirt-engine-dashboard
> 
> All requested hooks were deployed:
> 
> /home/gerrit2/review_site/git/ovirt-engine-dashboard.git/hooks
> 
> lrwxrwxrwx. 1 gerrit2 gerrit2 14 Aug 2 09:26 change-abandoned.update_tracker
> -> update_tracker
> lrwxrwxrwx. 1 gerrit2 gerrit2 14 Aug 2 09:25 change-merged.update_tracker ->
> update_tracker
> lrwxrwxrwx. 1 gerrit2 gerrit2 82 Aug 2 09:26
> comment-added.propagate_review_values ->
> /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values
> lrwxrwxrwx. 1 gerrit2 gerrit2 14 Aug 2 09:25 patchset-created.update_tracker
> -> update_tracker
> lrwxrwxrwx. 1 gerrit2 gerrit2 59 Aug 2 09:25 update_tracker ->
> /home/gerrit2/review_site/hooks/custom_hooks/update_tracker
> 
> Please check and let us know if all works well.
> Also, if you want more hooks like change status or verify bug-url its also
> possible to add.

Thanks, Eyal!

For now, I'd keep a smaller set of hooks and add more later if needed.

> 
> 
> 
> On Mon, Aug 1, 2016 at 10:27 PM, Vojtech Szocs (oVirt JIRA) <
> j...@ovirt-jira.atlassian.net > wrote:
> 
> 
> Vojtech Szocs created OVIRT-669:
> ---
> 
> Summary: Please add Gerrit hooks for project ovirt-engine-dashboard
> Key: OVIRT-669
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-669
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Vojtech Szocs
> Assignee: infra
> 
> 
> For project ovirt-engine-dashboard, please add following Gerrit hooks:
> 
> - patchset-created.update_tracker
> - change-merged.update_tracker
> - change-abandoned.update_tracker
> - comment-added.propagate_review_values
> 
> http://infra-docs.readthedocs.io/en/latest/CI/Gerrit_Hooks.html
> 
> Thanks!
> Vojtech
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v1000.184.1#18)
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
> 
> 
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-669) Please add Gerrit hooks for project ovirt-engine-dashboard

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=19102#comment-19102
 ] 

Vojtech Szocs commented on OVIRT-669:
-

Thanks!

> Please add Gerrit hooks for project ovirt-engine-dashboard
> --
>
> Key: OVIRT-669
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-669
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>    Reporter: Vojtech Szocs
>Assignee: infra
>
> For project ovirt-engine-dashboard, please add following Gerrit hooks:
> - patchset-created.update_tracker
> - change-merged.update_tracker
> - change-abandoned.update_tracker
> - comment-added.propagate_review_values
> http://infra-docs.readthedocs.io/en/latest/CI/Gerrit_Hooks.html
> Thanks!
> Vojtech



--
This message was sent by Atlassian JIRA
(v1000.203.1#18)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Errors / warnings in ovirt-engine-nodejs-modules build log

[Vojtech Szocs]

- Original Message -
> From: "Juan Hernández" <jhern...@redhat.com>
> To: "Eyal Edri" <ee...@redhat.com>, "Vojtech Szocs" <vsz...@redhat.com>, 
> "Anton Marchukov" <amarc...@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Monday, August 1, 2016 9:30:23 PM
> Subject: Re: Errors / warnings in ovirt-engine-nodejs-modules build log
> 
> On 08/01/2016 09:01 PM, Eyal Edri wrote:
> > Anton, can you sit with Vojtech tomorrow and see if you can help?
> > 
> > Vojtech
> > Maybe we're hitting: http://rpm.org/ticket/862
> > https://bugzilla.redhat.com/show_bug.cgi?id=913099
> > 
> > Anyway, what I meant was to try and run it on el7 slaves, not el7 mock,
> > to see if its a regression on mock running on fc24.
> > trying it here to see if it
> > works:
> > http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-el7-x86_64_created/22/console
> > 
> 
> As this seems to be a RPM limitation, and one that isn't going to be
> fixed soon, I'd suggest to change the Node.js modules RPM so that it
> packages a single .tar file containing all the modules. It can then,
> during installation (in the %post) section extract the content to
> /var/lib/ovirt-engine-nodejs-modules, so users only have to change the
> directory they use. Actually, as Vojtech introduced a "setup-env.sh"
> script that does all the preparations, only this script needs to be
> changed. This patch reflects my suggestion:
> 
>   Package tarball containing Node.js modules
>   https://gerrit.ovirt.org/61790

+1 this is great!

Proposed solution doesn't require any change in Dashboard code.

Seems like it was only a matter of time till we hit that ~100k
files limit when creating ovirt-engine-nodejs-modules RPM.

Juan++

> 
> > On Mon, Aug 1, 2016 at 9:42 PM, Vojtech Szocs <vsz...@redhat.com
> > <mailto:vsz...@redhat.com>> wrote:
> > 
> > 
> > 
> > - Original Message -
> > > From: "Eyal Edri" <ee...@redhat.com <mailto:ee...@redhat.com>>
> > > To: "Vojtech Szocs" <vsz...@redhat.com <mailto:vsz...@redhat.com>>
> > > Cc: "infra" <infra@ovirt.org <mailto:infra@ovirt.org>>
> > > Sent: Monday, August 1, 2016 8:25:50 PM
> > > Subject: Re: Errors / warnings in ovirt-engine-nodejs-modules build
> > > log
> > >
> > > Does it work on el7?
> > 
> > It fails on el7 as well:
> > 
> > 
> > http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-el7-x86_64_created/21/console
> > 
> >   error: Unable to create immutable header region.
> > 
> > >
> > > On Mon, Aug 1, 2016 at 8:21 PM, Vojtech Szocs <vsz...@redhat.com
> > <mailto:vsz...@redhat.com>> wrote:
> > >
> > > > Forwarding to infra, TL;DR we seem to have an issue with rpmbuild
> > > > (see below) and I'm not sure how to fix that, is there anyone who
> > > > faced such issue in past?
> > > >
> > > > Vojtech
> > > >
> > > >
> > > > - Forwarded Message -
> > > > From: "Vojtech Szocs" <vsz...@redhat.com
> > > > <mailto:vsz...@redhat.com>>
> > > > To: "Sandro Bonazzola" <sbona...@redhat.com
> > <mailto:sbona...@redhat.com>>
> > > > Cc: "Oved Ourfali" <oourf...@redhat.com
> > <mailto:oourf...@redhat.com>>, "Alexander Wels" <
> > > > aw...@redhat.com <mailto:aw...@redhat.com>>, "Greg Sheremeta"
> > <gsher...@redhat.com <mailto:gsher...@redhat.com>>, "Juan
> > > > Hernández" <jhern...@redhat.com <mailto:jhern...@redhat.com>>,
> > "Ryan Barry" <rba...@redhat.com <mailto:rba...@redhat.com>>
> > > > Sent: Monday, August 1, 2016 6:49:08 PM
> > > > Subject: Errors / warnings in ovirt-engine-nodejs-modules build log
> > > >
> > > > Hi Sandro,
> > > >
> > > > I've looked into the build log [1].
> > > >
> > > > Adding Juan & Ryan as well. Your feedback is highly appreciated.
> > > >
> > > > npm-specific issues (don't block the build):
> > > >
> > > >   npm WARN package.json dependencies@ No rep

[JIRA] (OVIRT-669) Please add Gerrit hooks for project ovirt-engine-dashboard

[Vojtech Szocs (oVirt JIRA)]

Vojtech Szocs created OVIRT-669:
---

 Summary: Please add Gerrit hooks for project ovirt-engine-dashboard
 Key: OVIRT-669
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-669
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Vojtech Szocs
Assignee: infra


For project ovirt-engine-dashboard, please add following Gerrit hooks:

- patchset-created.update_tracker
- change-merged.update_tracker
- change-abandoned.update_tracker
- comment-added.propagate_review_values

http://infra-docs.readthedocs.io/en/latest/CI/Gerrit_Hooks.html

Thanks!
Vojtech



--
This message was sent by Atlassian JIRA
(v1000.184.1#18)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Errors / warnings in ovirt-engine-nodejs-modules build log

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" <ee...@redhat.com>
> To: "Vojtech Szocs" <vsz...@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Monday, August 1, 2016 8:25:50 PM
> Subject: Re: Errors / warnings in ovirt-engine-nodejs-modules build log
> 
> Does it work on el7?

It fails on el7 as well:

http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-el7-x86_64_created/21/console

  error: Unable to create immutable header region.

> 
> On Mon, Aug 1, 2016 at 8:21 PM, Vojtech Szocs <vsz...@redhat.com> wrote:
> 
> > Forwarding to infra, TL;DR we seem to have an issue with rpmbuild
> > (see below) and I'm not sure how to fix that, is there anyone who
> > faced such issue in past?
> >
> > Vojtech
> >
> >
> > - Forwarded Message -
> > From: "Vojtech Szocs" <vsz...@redhat.com>
> > To: "Sandro Bonazzola" <sbona...@redhat.com>
> > Cc: "Oved Ourfali" <oourf...@redhat.com>, "Alexander Wels" <
> > aw...@redhat.com>, "Greg Sheremeta" <gsher...@redhat.com>, "Juan
> > Hernández" <jhern...@redhat.com>, "Ryan Barry" <rba...@redhat.com>
> > Sent: Monday, August 1, 2016 6:49:08 PM
> > Subject: Errors / warnings in ovirt-engine-nodejs-modules build log
> >
> > Hi Sandro,
> >
> > I've looked into the build log [1].
> >
> > Adding Juan & Ryan as well. Your feedback is highly appreciated.
> >
> > npm-specific issues (don't block the build):
> >
> >   npm WARN package.json dependencies@ No repository field.
> >   npm WARN package.json dependencies@ No license field.
> >   - these warnings are harmless
> >   - TODO update modules' package.json
> >
> >   npm WARN deprecated ...
> >   - some (possibly transitive) dependency in package.json relies
> > on a deprecated npm package
> >   - TODO find out which dependencies are causing this
> >
> >   npm ERR! registry error parsing json
> >   - this might indicate corrupt npm cache
> >   - should be fixed by `npm cache clean`
> >   - TODO update modules' build.sh
> >
> >   npm WARN optional dep failed, continuing ...
> >   - these warnings are harmless
> >   - some (possibly transitive) dependency in package.json relies
> > on an optional npm package that is platform-specific but it
> > is NOT available for current platform
> >   - e.g. "fsevents" is MacOSX only
> >   - this should be fixed by `npm install --no-optional`
> >   - TODO update modules' build.sh
> >
> >   sh: bower: command not found
> >   npm WARN optional dep failed, continuing bootstrap-treeview@1.2.0
> >   - bootstrap-treeview does `bower install` in its `install` script
> >   - this is BAD practice (bootstrap-treeview's fault)
> >   - TODO latest commit on May 9, 2015 -- do we need this at all (?)
> >
> > CI-specific issues (which block the build):
> >
> >   Wrote:
> > /tmp/ovirt-engine-nodejs-modules/ovirt-engine-nodejs-modules-0.0.10-1.fc24.src.rpm
> >   error: Unable to create immutable header region.
> >   - at this point, spec's %install phase has finished executing
> > and RPM was created
> >   - it is rpmbuild related, see
> > https://bugzilla.redhat.com/show_bug.cgi?id=913099#c2
> >
> > For ^^ error, seems like too many files in RPM package will cause
> > "artificial cap on header size" to be exceeded and rpmbuild fails.
> >
> > Juan, what do you think? I don't have any idea how to solve this.
> >
> > I don't understand the actual issue as we're creating single .tar
> > file from `node_modules` directory during the RPM build..
> >
> > [1]
> > http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-fc24-x86_64_created/4/console
> >
> > Thanks,
> > Vojtech
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> >
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Fwd: Errors / warnings in ovirt-engine-nodejs-modules build log

[Vojtech Szocs]

Forwarding to infra, TL;DR we seem to have an issue with rpmbuild
(see below) and I'm not sure how to fix that, is there anyone who
faced such issue in past?

Vojtech


- Forwarded Message -
From: "Vojtech Szocs" <vsz...@redhat.com>
To: "Sandro Bonazzola" <sbona...@redhat.com>
Cc: "Oved Ourfali" <oourf...@redhat.com>, "Alexander Wels" <aw...@redhat.com>, 
"Greg Sheremeta" <gsher...@redhat.com>, "Juan Hernández" <jhern...@redhat.com>, 
"Ryan Barry" <rba...@redhat.com>
Sent: Monday, August 1, 2016 6:49:08 PM
Subject: Errors / warnings in ovirt-engine-nodejs-modules build log

Hi Sandro,

I've looked into the build log [1].

Adding Juan & Ryan as well. Your feedback is highly appreciated.

npm-specific issues (don't block the build):

  npm WARN package.json dependencies@ No repository field.
  npm WARN package.json dependencies@ No license field.
  - these warnings are harmless
  - TODO update modules' package.json

  npm WARN deprecated ...
  - some (possibly transitive) dependency in package.json relies
on a deprecated npm package
  - TODO find out which dependencies are causing this

  npm ERR! registry error parsing json
  - this might indicate corrupt npm cache
  - should be fixed by `npm cache clean`
  - TODO update modules' build.sh

  npm WARN optional dep failed, continuing ...
  - these warnings are harmless
  - some (possibly transitive) dependency in package.json relies
on an optional npm package that is platform-specific but it
is NOT available for current platform
  - e.g. "fsevents" is MacOSX only
  - this should be fixed by `npm install --no-optional`
  - TODO update modules' build.sh

  sh: bower: command not found
  npm WARN optional dep failed, continuing bootstrap-treeview@1.2.0
  - bootstrap-treeview does `bower install` in its `install` script
  - this is BAD practice (bootstrap-treeview's fault)
  - TODO latest commit on May 9, 2015 -- do we need this at all (?)

CI-specific issues (which block the build):

  Wrote: 
/tmp/ovirt-engine-nodejs-modules/ovirt-engine-nodejs-modules-0.0.10-1.fc24.src.rpm
  error: Unable to create immutable header region.
  - at this point, spec's %install phase has finished executing
and RPM was created
  - it is rpmbuild related, see
https://bugzilla.redhat.com/show_bug.cgi?id=913099#c2

For ^^ error, seems like too many files in RPM package will cause
"artificial cap on header size" to be exceeded and rpmbuild fails.

Juan, what do you think? I don't have any idea how to solve this.

I don't understand the actual issue as we're creating single .tar
file from `node_modules` directory during the RPM build..

[1] 
http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-fc24-x86_64_created/4/console

Thanks,
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-668) ovirt-engine-nodejs-modules errors

[Vojtech Szocs (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=19071#comment-19071
 ] 

Vojtech Szocs commented on OVIRT-668:
-

That `Unable to create immutable header region` seems rpmbuild related.

I did some research on errors / warnings in that build log, will post my 
findings on infra list.

> ovirt-engine-nodejs-modules errors
> --
>
> Key: OVIRT-668
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-668
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: sbonazzo
>Assignee: infra
>
> *Hi, looks like something happened during a build:
> **http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_4.0_create-rpms-el7-x86_64_created/8/console
> <http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_4.0_create-rpms-el7-x86_64_created/8/console>*
> *00:08:50.299* + exit 0*00:18:36.484* Provides:
> ovirt-engine-nodejs-modules = 0.0.10-1.el7
> ovirt-engine-nodejs-modules(x86-64) = 0.0.10-1.el7*00:18:36.484*
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1*00:18:36.485* Requires:
> /bin/bash /bin/sh /usr/bin/env ld-linux-x86-64.so.2()(64bit)
> ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libc.so.6()(64bit)
> libc.so.6(GLIBC_2.10)(64bit) libc.so.6(GLIBC_2.2.5)(64bit)
> libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit)
> libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.9)(64bit)
> libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit)
> libfontconfig.so.1()(64bit) libfreetype.so.6()(64bit)
> libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit)
> libgcc_s.so.1(GCC_3.4)(64bit) libm.so.6()(64bit)
> libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit)
> libpthread.so.0(GLIBC_2.2.5)(64bit)
> libpthread.so.0(GLIBC_2.3.2)(64bit)
> libpthread.so.0(GLIBC_2.3.3)(64bit) librt.so.1()(64bit)
> librt.so.1(GLIBC_2.2.5)(64bit) libstdc++.so.6()(64bit)
> libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit)
> libstdc++.so.6(GLIBCXX_3.4)(64bit)
> libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
> libstdc++.so.6(GLIBCXX_3.4.9)(64bit) libz.so.1()(64bit)
> libz.so.1(ZLIB_1.2.0)(64bit)*00:18:36.515* Checking for unpackaged
> file(s): /usr/lib/rpm/check-files
> /builddir/rpmbuild/BUILDROOT/ovirt-engine-nodejs-modules-0.0.10-1.el7.x86_64*00:18:40.184*
> Wrote: 
> /tmp/ovirt-engine-nodejs-modules/ovirt-engine-nodejs-modules-0.0.10-1.el7.src.rpm*00:18:40.185*
> error: Unable to create immutable header region.
> Note it got stuck for 10 minutes and then failed with an error that seems
> infra releated.
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com



--
This message was sent by Atlassian JIRA
(v1000.184.1#18)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Building for fc23 fails on yum package install

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" <ee...@redhat.com>
> To: "Vojtech Szocs" <vsz...@redhat.com>, "Evgheni Dereveanchin" 
> <edere...@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Wednesday, July 20, 2016 8:09:07 PM
> Subject: Re: Building for fc23 fails on yum package install
> 
> I see its working now, maybe its the proxy issue again,
> Evgheni - can you check if the failure is related to the proxy?

It's solved, sorry, this was a problem on our end (Dashboard project).

We fixed it by updating *.repos: https://gerrit.ovirt.org/#/c/61149/

Thanks!

Vojtech

> 
> On Wed, Jul 20, 2016 at 7:37 PM, Vojtech Szocs <vsz...@redhat.com> wrote:
> 
> > Hi,
> >
> > we're trying to build Dashboard 1.0.0-1 and for fc23 the build fails:
> >
> > 16:26:03 INFO: installing package(s): ovirt-engine-nodejs
> > ovirt-engine-nodejs-modules
> > 16:26:03 ERROR: Command failed. See logs for output.
> > 16:26:03  # /usr/bin/yum-deprecated --installroot
> > /var/lib/mock/fedora-23-x86_64-84590ba0ae0d50bf8fb4605dac9e1a22-7835/root/
> > --releasever 23 install ovirt-engine-nodejs ovirt-engine-nodejs-modules
> > --setopt=tsflags=nocontexts
> > 16:26:03 Install packages took 2 seconds
> >
> >
> > http://jenkins.ovirt.org/job/ovirt-engine-dashboard_4.0_check-patch-fc23-x86_64/10/console
> >
> > Is this an infra issue? I'll try to retrigger the build in the meantime.
> >
> > Thanks,
> > Vojtech
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> >
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Building for fc23 fails on yum package install

[Vojtech Szocs]

Hi,

we're trying to build Dashboard 1.0.0-1 and for fc23 the build fails:

16:26:03 INFO: installing package(s): ovirt-engine-nodejs 
ovirt-engine-nodejs-modules
16:26:03 ERROR: Command failed. See logs for output.
16:26:03  # /usr/bin/yum-deprecated --installroot 
/var/lib/mock/fedora-23-x86_64-84590ba0ae0d50bf8fb4605dac9e1a22-7835/root/ 
--releasever 23 install ovirt-engine-nodejs ovirt-engine-nodejs-modules 
--setopt=tsflags=nocontexts
16:26:03 Install packages took 2 seconds

http://jenkins.ovirt.org/job/ovirt-engine-dashboard_4.0_check-patch-fc23-x86_64/10/console

Is this an infra issue? I'll try to retrigger the build in the meantime.

Thanks,
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [Jenkins] Passing parameters to build-artifacts.sh

[Vojtech Szocs]

Hello folks,

this was discussed some time ago, but we're gonna make oVirt Dashboard
build-artifacts.sh tag-sensitive (if the commit is tagged, it indicates
release build, so we'll drop the {date}git{commit} part of RPM release).

The relevant Dashboard patch is here: https://gerrit.ovirt.org/#/c/60988/

Question: is it possible to execute build-artifacts.sh after a tag gets
pushed into Gerrit repo? (or at least make it opt-in via the Jenkins job
config somehow?)

Or should we just use Jenkins / Gerrit manual trigger to re-build from
given commit once it's tagged in Gerrit repo?

Thanks,
Vojtech


- Original Message -
> From: "Vojtech Szocs" <vsz...@redhat.com>
> To: "David Caro" <dc...@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Wednesday, June 22, 2016 7:04:19 PM
> Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh
> 
> 
> 
> - Original Message -
> > From: "David Caro" <dc...@redhat.com>
> > To: "Nir Soffer" <nsof...@redhat.com>
> > Cc: "infra" <infra@ovirt.org>
> > Sent: Wednesday, June 22, 2016 6:31:44 PM
> > Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh
> > 
> > On 06/22 19:21, Nir Soffer wrote:
> > > On Wed, Jun 22, 2016 at 6:47 PM, Barak Korren <bkor...@redhat.com> wrote:
> > > > This could be done, but not trival to do, and also requires you to
> > > > know,
> > > > before merging, that this is the patch you are gonna release.
> > > >
> > > > A differnt but somewhat common practice is to use git tagging and 'git
> > > > describe' to set the package version.
> > > > We can make build_artifacts trigger when a tag is pushed, AFAIK Lago
> > > > already
> > > > does that...
> > > >
> > > > בתאריך 22 ביוני 2016 18:39,‏ "Vojtech Szocs" <vsz...@redhat.com> כתב:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'm just curious whether it's possible to do the following:
> > > >>
> > > >> Let's say we have a project (ovirt-engine-dashboard) built by Jenkins,
> > > >> which means there's a Jenkins job that runs build-artifacts.sh script
> > > >> whenever a patch gets merged via gerrit.
> > > >>
> > > >> Can we somehow pass custom parameters to build-artifacts.sh for such
> > > >> (Jenkins CI) builds?
> > > >>
> > > >> For example, putting something like this into commit message:
> > > >>
> > > >>   My-Param 123
> > > >>
> > > >> would reflect into `My-Param` env. variable when running the script?
> > > >>
> > > >> Motivation: for release builds (which shouldn't contain the "snapshot"
> > > >> part [*] in RPM release string), pass parameter to build-artifacts.sh
> > > >> that ensures the "snapshot" part is empty. This way, we don't need to
> > > >> patch the project prior to release (remove "snapshot" in spec) & then
> > > >> patch it again after the release (re-add "snapshot" in spec).
> > > >>
> > > >> [*] {date}git{commit}
> > > 
> > > How about adding a flag to the project yaml?
> > > 
> > > For example:
> > > 
> > > version:
> > >   - master:
> > >   branch: master
> > >   - 0.16:
> > >   branch: ioprocess-0.16
> > >   release: true
> > > 
> > > Then run build-artifacts with RELEASE=1 environment variable, so we can
> > > tell that this is a release build, and create release friendly rpms?
> > 
> > That's not better than adding a commit to the project for each release imo.
> > 
> > I'd go for the tag thingie actually, just detecting that you are in a tag
> > to
> > control if the extra 'snapshot' should be added or not.
> 
> Yes, this sounds like the most correct approach. We'll need to tag anyway :)
> 
> As mentioned above, it would be really nice if build-artifacts was invoked
> also when pushing new tag to remote.
> 
> > 
> > > 
> > > Nir
> > > ___
> > > Infra mailing list
> > > Infra@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> > --
> > David Caro
> > 
> > Red Hat S.L.
> > Continuous Integration Engineer - EMEA ENG Virtualization R
> > 
> > Tel.: +420 532 294 605
> > Email: dc...@redhat.com
> > IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> > Web: www.redhat.com
> > RHT Global #: 82-62605
> > 
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [Jenkins] Passing parameters to build-artifacts.sh

[Vojtech Szocs]

- Original Message -
> From: "David Caro" <dc...@redhat.com>
> To: "Nir Soffer" <nsof...@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Wednesday, June 22, 2016 6:31:44 PM
> Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh
> 
> On 06/22 19:21, Nir Soffer wrote:
> > On Wed, Jun 22, 2016 at 6:47 PM, Barak Korren <bkor...@redhat.com> wrote:
> > > This could be done, but not trival to do, and also requires you to know,
> > > before merging, that this is the patch you are gonna release.
> > >
> > > A differnt but somewhat common practice is to use git tagging and 'git
> > > describe' to set the package version.
> > > We can make build_artifacts trigger when a tag is pushed, AFAIK Lago
> > > already
> > > does that...
> > >
> > > בתאריך 22 ביוני 2016 18:39,‏ "Vojtech Szocs" <vsz...@redhat.com> כתב:
> > >
> > >> Hi,
> > >>
> > >> I'm just curious whether it's possible to do the following:
> > >>
> > >> Let's say we have a project (ovirt-engine-dashboard) built by Jenkins,
> > >> which means there's a Jenkins job that runs build-artifacts.sh script
> > >> whenever a patch gets merged via gerrit.
> > >>
> > >> Can we somehow pass custom parameters to build-artifacts.sh for such
> > >> (Jenkins CI) builds?
> > >>
> > >> For example, putting something like this into commit message:
> > >>
> > >>   My-Param 123
> > >>
> > >> would reflect into `My-Param` env. variable when running the script?
> > >>
> > >> Motivation: for release builds (which shouldn't contain the "snapshot"
> > >> part [*] in RPM release string), pass parameter to build-artifacts.sh
> > >> that ensures the "snapshot" part is empty. This way, we don't need to
> > >> patch the project prior to release (remove "snapshot" in spec) & then
> > >> patch it again after the release (re-add "snapshot" in spec).
> > >>
> > >> [*] {date}git{commit}
> > 
> > How about adding a flag to the project yaml?
> > 
> > For example:
> > 
> > version:
> >   - master:
> >   branch: master
> >   - 0.16:
> >   branch: ioprocess-0.16
> >   release: true
> > 
> > Then run build-artifacts with RELEASE=1 environment variable, so we can
> > tell that this is a release build, and create release friendly rpms?
> 
> That's not better than adding a commit to the project for each release imo.
> 
> I'd go for the tag thingie actually, just detecting that you are in a tag to
> control if the extra 'snapshot' should be added or not.

Yes, this sounds like the most correct approach. We'll need to tag anyway :)

As mentioned above, it would be really nice if build-artifacts was invoked
also when pushing new tag to remote.

> 
> > 
> > Nir
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> 
> --
> David Caro
> 
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R
> 
> Tel.: +420 532 294 605
> Email: dc...@redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
> 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [Jenkins] Passing parameters to build-artifacts.sh

[Vojtech Szocs]

Thanks guys for your replies!

Sandro's advice sounds quite simple and straight-forward, I think
we can use it for now:

  $ foo=`git show -s --format=%B | grep My-Param` # My-Param: 123
  $ foo=${foo##My-Param:} # 123

Some more comments inline below.

Vojtech


- Original Message -
> From: "Barak Korren" <bkor...@redhat.com>
> To: "Vojtech Szocs" <vsz...@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Wednesday, June 22, 2016 5:47:46 PM
> Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh
> 
> This could be done, but not trival to do, and also requires you to know,
> before merging, that this is the patch you are gonna release.

Yes - when we're about to make release build, we submit a patch that
ensures correct RPM version, I just wanted to avoid having to remove
& re-add the "snapshot" part in RPM release string for each release.

> 
> A differnt but somewhat common practice is to use git tagging and 'git
> describe' to set the package version.

Right, with tags one could use `git describe --tags --long`.

> We can make build_artifacts trigger when a tag is pushed, AFAIK Lago
> already does that...

That would be nice to have :)

> בתאריך 22 ביוני 2016 18:39,‏ "Vojtech Szocs" <vsz...@redhat.com> כתב:
> 
> > Hi,
> >
> > I'm just curious whether it's possible to do the following:
> >
> > Let's say we have a project (ovirt-engine-dashboard) built by Jenkins,
> > which means there's a Jenkins job that runs build-artifacts.sh script
> > whenever a patch gets merged via gerrit.
> >
> > Can we somehow pass custom parameters to build-artifacts.sh for such
> > (Jenkins CI) builds?
> >
> > For example, putting something like this into commit message:
> >
> >   My-Param 123
> >
> > would reflect into `My-Param` env. variable when running the script?
> >
> > Motivation: for release builds (which shouldn't contain the "snapshot"
> > part [*] in RPM release string), pass parameter to build-artifacts.sh
> > that ensures the "snapshot" part is empty. This way, we don't need to
> > patch the project prior to release (remove "snapshot" in spec) & then
> > patch it again after the release (re-add "snapshot" in spec).
> >
> > [*] {date}git{commit}
> >
> > Thanks,
> > Vojtech
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[Jenkins] Passing parameters to build-artifacts.sh

[Vojtech Szocs]

Hi,

I'm just curious whether it's possible to do the following:

Let's say we have a project (ovirt-engine-dashboard) built by Jenkins,
which means there's a Jenkins job that runs build-artifacts.sh script
whenever a patch gets merged via gerrit.

Can we somehow pass custom parameters to build-artifacts.sh for such
(Jenkins CI) builds?

For example, putting something like this into commit message:

  My-Param 123

would reflect into `My-Param` env. variable when running the script?

Motivation: for release builds (which shouldn't contain the "snapshot"
part [*] in RPM release string), pass parameter to build-artifacts.sh
that ensures the "snapshot" part is empty. This way, we don't need to
patch the project prior to release (remove "snapshot" in spec) & then
patch it again after the release (re-add "snapshot" in spec).

[*] {date}git{commit}

Thanks,
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[ovirt-engine-dashboard] Request stable branch creation

[Vojtech Szocs]

Hi,

please create a stable branch, based on master, for ovirt-engine-dashboard:

  ovirt-engine-dashboard-1.0

Once done, I'll update Jenkins nightly publisher configs according to [1].

[1] https://gerrit.ovirt.org/#/c/59150/

As for stable branch maintainers, I'm proposing Alex (awels) with me (vszocs) 
as backup.

Thanks,
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Cloning project with git:// fails

[Vojtech Szocs]

- Original Message -
> From: "Juan Hernández" <jhern...@redhat.com>
> To: "Sandro Bonazzola" <sbona...@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Tuesday, April 26, 2016 12:05:36 PM
> Subject: Re: Cloning project with git:// fails
> 
> On 04/26/2016 12:01 PM, Sandro Bonazzola wrote:
> > 
> > 
> > On Mon, Apr 25, 2016 at 3:04 PM, Juan Hernández <jhern...@redhat.com
> > <mailto:jhern...@redhat.com>> wrote:
> > 
> > Please see the git/gerrit failure that Vojtech is reporting.
> > 
> > 
> > 
> > Looking at jenkins, the job is not failing anymore.
> > Can you check?
> > About the git:// issue, leaving it to infra :-)
> > 
> 
> Thanks Sandro, this was solved by Nadav Goldin yesterday:
> 
>   https://ovirt-jira.atlassian.net/browse/OVIRT-500

Thanks Nadav & others for fixing this!

> 
> >  
> > 
> > 
> >  Forwarded Message 
> > Subject: Cloning project with git:// fails
> > Date: Mon, 25 Apr 2016 08:53:45 -0400 (EDT)
> > From: Vojtech Szocs <vsz...@redhat.com <mailto:vsz...@redhat.com>>
> > To: Sandro Bonazzola <sbona...@redhat.com <mailto:sbona...@redhat.com>>
> > CC: Juan Hernández <jhern...@redhat.com
> > <mailto:jhern...@redhat.com>>, Alexander Wels
> > <aw...@redhat.com <mailto:aw...@redhat.com>>, Oved Ourfali
> > <oourf...@redhat.com <mailto:oourf...@redhat.com>>
> > 
> > Hi Sandro,
> > 
> > after setting up automation and packaging directories
> > for 'ovirt-engine-dashboard' project [1], Jenkins CI
> > always gives -1 with following error:
> > 
> >   $ git clone git://gerrit.ovirt.org/ovirt-engine-dashboard.git
> > <http://gerrit.ovirt.org/ovirt-engine-dashboard.git>
> >   Cloning into 'ovirt-engine-dashboard'...
> >   fatal: Could not read from remote repository.
> > 
> > Please see my comment at [2] - cloning with https://
> > and ssh:// works, but somehow git:// fails.
> > 
> > I'm out of ideas as to why..
> > 
> > [1] https://gerrit.ovirt.org/#/c/56435/
> > [2] https://gerrit.ovirt.org/#/c/56480/
> > 
> > The only real difference between:
> > 
> >   https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-dashboard
> > 
> > and:
> > 
> >   https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-api-explorer
> >   (for which cloning with git:// works as expected)
> > 
> > seems to be "Enable signed push" option but I don't
> > think that's related.
> > 
> > Thanks,
> > Vojtech
> > 
> > 
> > ___
> > Infra mailing list
> > Infra@ovirt.org <mailto:Infra@ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> > 
> > 
> > 
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com <http://redhat.com>
> 
> 
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Gerrit project request: ovirt-engine-dashboard

[Vojtech Szocs]

Hi,

I'd like to request creation of Gerrit project titled
"ovirt-engine-dashboard" along with code transfer from

  https://github.com/vojtechszocs/ovirt-dashboard-ui-plugin

Project maintainers:
- Vojtech Szocs (vszocs)
- Alexander Wels (awels)
- Oved Ourfali (oourfali)

Many thanks,
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [TICKET] build failed, Could not find resource 'checkstyle.xml'

[Vojtech Szocs]

- Original Message -
 From: Greg Sheremeta gsher...@redhat.com
 To: infra infra@ovirt.org
 Cc: Vojtech Szocs vsz...@redhat.com
 Sent: Tuesday, 26 May, 2015 6:59:03 PM
 Subject: [TICKET] build failed, Could not find resource 'checkstyle.xml'
 
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (checkstyle) on
 project manager-modules: Failed during checkstyle execution: Unable to find
 configuration file at location checkstyle.xml: Could not find resource
 'checkstyle.xml'. - [Help 1]
 
 
 I don't think Vojtech deleted that file :)

Nope :) I didn't touch it. For me, local build with unit tests worked fine.

 
 http://jenkins.ovirt.org/job/ovirt-engine_master_find-bugs_gerrit/35834/console
 https://gerrit.ovirt.org/#/c/41405/
 
 
 Greg Sheremeta
 Red Hat, Inc.
 Sr. Software Engineer, RHEV
 Cell: 919-807-1086
 gsher...@redhat.com
 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

New git repo request: ovirt-engine-sdk-js

[Vojtech Szocs]

Hi,

I'd like to request creation of git repo:

  ovirt-engine-sdk-js

to contain oVirtJS project [1] representing
JavaScript SDK for working with oVirt Engine.

[1] https://gerrit.ovirt.org/#/c/33720/

Thanks,
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: duplicate Vojtech in gerrit

[Vojtech Szocs]

Oh no! My cloning machine has been detected :D

The account I'm using:

Email Address   vsz...@redhat.com
Registered  Nov 7, 2011 12:28 PM
Account ID  152

The account I've mistakenly created and should be removed:

Email Address   vsz...@redhat.com
Registered  Apr 6, 2015 11:10 AM
Account ID  1000764

Regards,
Vojtech


- Original Message -
 From: Greg Sheremeta gsher...@redhat.com
 To: infra infra@ovirt.org
 Cc: Vojtech Szocs vsz...@redhat.com
 Sent: Tuesday, April 21, 2015 7:00:24 PM
 Subject: duplicate Vojtech in gerrit
 
 There are two vszocs in gerrit and it won't let me add either of him.
 
 Thanks,
 Greg
 
 Greg Sheremeta
 Red Hat, Inc.
 Sr. Software Engineer, RHEV
 Cell: 919-807-1086
 gsher...@redhat.com
 
 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: proposing Greg Sheremeta as an ovirt-engine UI maintainer

[Vojtech Szocs]

- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: Lior Vernia lver...@redhat.com, Alona Kaplan alkap...@redhat.com, 
 Daniel Erez de...@redhat.com,
 Gilad Chaplik gchap...@redhat.com, Tomas Jelinek tjeli...@redhat.com, 
 Vojtech Szocs vsz...@redhat.com,
 Alexander Wels aw...@redhat.com, Kanagaraj kmayi...@redhat.com, Tal 
 Nisan tni...@redhat.com
 Cc: de...@ovirt.org, infra@ovirt.org
 Sent: Wednesday, March 25, 2015 1:59:17 PM
 Subject: proposing Greg Sheremeta as an ovirt-engine UI maintainer
 
 Hello UI Maintainers,
 
 I would like to propose Greg Sheremeta as an ovirt-engine
 UI maintainer.

+1

 
 Greg started being actively involved in ovirt on July 2013,
 contributing over 150 patches (to 'master' alone), including
 improvements to the branding mechanism (e.g. support cascading
 resources), grid-column width persistence, phase 1 of the
 PatternFly styling adoption, dialog-id (tag) based mapping
 infrastructure, multiple automated-UI-tests (Selenium) related
 enhancements and the recent overhaul of the tool-tips throughout
 the code.
 
 Your response would be highly appreciated.
 
 Many thanks in advance.
 
 
 Regards,
 Einav
 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: proposing Alexander Wels as an ovirt-engine UI maintainer

[Vojtech Szocs]

- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: Tal Nisan tni...@redhat.com, Gilad Chaplik gchap...@redhat.com, 
 Vojtech Szocs vsz...@redhat.com,
 Kanagaraj kmayi...@redhat.com, Daniel Erez de...@redhat.com, Tomas 
 Jelinek tjeli...@redhat.com, Lior
 Vernia lver...@redhat.com
 Cc: infra@ovirt.org, engine-devel engine-de...@ovirt.org, Alexander 
 Wels aw...@redhat.com
 Sent: Tuesday, January 21, 2014 4:39:09 PM
 Subject: proposing Alexander Wels as an ovirt-engine UI maintainer
 
 Hello UI Maintainers,
 
 I would like to propose Alexander Wels as an ovirt-engine UI maintainer.

+1

 
 Alexander started his ovirt involvement more than a year ago,
 contributing over 100 patches (to 'master' alone), including the
 branding mechanism, Frontend refactoring (cleanup, unit-tests, requests
 retry mechanism, requests-aggregation mechanism), cross-GUI refresh
 synchronization and low-resolutions support.
 
 Your response would be appreciated.
 
 Thanks in advance.
 
 
 Regards,
 Einav
 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1164 - Failure!

[Vojtech Szocs]

Hi,

looking at 
http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1164/console

Java compilation failed for test classes of gwt-common project:

error: package org.junit does not exist

Above looks like Maven repo/env. issue, i.e. JUnit JAR(s) missing in local 
Maven repo?

BTW, my patch http://gerrit.ovirt.org/36710 did not touch gwt-common project 
sources.

Vojtech


- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: vsz...@redhat.com, ee...@redhat.com
 Cc: oba...@redhat.com, dcaro...@redhat.com, infra@ovirt.org
 Sent: Friday, January 9, 2015 4:03:14 PM
 Subject: Re: [oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1164 
 -   Failure!
 
 @Vojtech - is this failure seem related to your patch as implied below?
 
 - Original Message -
  From: Jenkins ci oVirt Server jenk...@ovirt.org
  To: vsz...@redhat.com, ee...@redhat.com, oba...@redhat.com,
  dcaro...@redhat.com, infra@ovirt.org
  Sent: Friday, January 9, 2015 7:34:03 AM
  Subject: [oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1164 -
  Failure!
  
  Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/
  Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1164/
  Build Number: 1164
  Build Status:  Failure
  Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/36710
  
  -
  Changes Since Last Success:
  -
  Changes for Build #1164
  [Vojtech Szocs] webadmin: Fix UI plugin REST API / Engine session refresh
  issue
  
  
  
  
  -
  Failed Tests:
  -
  No tests ran.
  
  
  ___
  Infra mailing list
  Infra@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/infra
  
 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Tools for developing and building oVirt.js project

[Vojtech Szocs]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: Vojtech Szocs vsz...@redhat.com
 Cc: Tomas Jelinek tjeli...@redhat.com, Mooli Tayer mta...@redhat.com, 
 de...@ovirt.org, infra
 infra@ovirt.org
 Sent: Friday, August 29, 2014 8:05:58 AM
 Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js project
 
 Il 28/08/2014 21:00, Vojtech Szocs ha scritto:
  
  
  - Original Message -
  From: Sandro Bonazzola sbona...@redhat.com
  To: Tomas Jelinek tjeli...@redhat.com, Mooli Tayer
  mta...@redhat.com
  Cc: de...@ovirt.org
  Sent: Tuesday, August 26, 2014 12:03:14 PM
  Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js
  project
 
  Il 26/08/2014 09:38, Tomas Jelinek ha scritto:
 
 
  - Original Message -
  From: Mooli Tayer mta...@redhat.com
  To: Greg Sheremeta gsher...@redhat.com
  Cc: de...@ovirt.org
  Sent: Tuesday, August 26, 2014 9:17:20 AM
  Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js
  project
 
  Are we talking about using node as a development/test/packaging(minify
  etc
  )
  tool or having a runtime backend (site) on top of node?
 
  It is only devel environment (e.g. build dependency), not runtime.
 
 
  If it's build dependency it's not just devel environment.
  
  Right, I messed up my comment above, sorry.
  
  Node.js can be (and typically is) used as both devel  build dependency
  for JavaScript projects.
  
  We must ensure that all required build dependencies are available and
  properly packaged for all supported distributions.
  
  Yes, fully agreed.
  
  Fedora already has some packages we could use, for example:
  http://koji.fedoraproject.org/koji/packageinfo?packageID=15154
  http://koji.fedoraproject.org/koji/packageinfo?packageID=15356
  
  However, there's one complication (as Greg mentioned before): npm (Node
  package manager) resolves Node-specific packages (esentially JavaScript
  artifacts) via HTTP access, so we'd need some infra to serve these, and
  for each such JS module:
  - either use existing package for that JS module, if one exists
  - or maintain package for that JS module on our own [*]
  
  [*] I understand that this is not what we want to do in general
 
 I would add
 - Ask supported distributions to provide needed rpms

Well, that ^^ would be ideal.

 
  
  In other words, there would have to be some infra to support builds for
  JavaScript/Node.js projects, similar to existing infra to support builds
  for Java/Maven projects:
  - package for Node.js + npm
  - package for each JS module (likely problematic)
  - tool (existing Artifactory that serves Maven artifacts?) to serve
JS modules via HTTP for npm to consume (maybe problematic)
  
 
 Adding infra for above
 
 
  In any case, we can proceed with developing oVirt.js without requiring
  Node.js as a build dependency. I see two possible solutions here:
  
  1, avoid using build tools like Traceur (ES6 - ES5 transpiler)
 and UglifyJS (code compressor/obfuscator), just concatenate
 JS source files into resulting JS target file (either via
 command in Makefile or via some Maven plugin)
  
 PROS: no special build requirements
 CONS: can't use tools like Traceur
  
  2, use build tools like Traceur and UglifyJS, commit resulting
 JS target file into source tree, maybe with git commit hook
 for this
  
 PROS: can use tools like Traceur
 CONS: storing target JS file in source tree
  
  3, (?)
 
 Use something simpler to package for compressing / minimizing like
 http://yui.github.io/yuicompressor/ or any other tool like that at build time
 (nothing against Node.js at development time).

YUI Compressor is written in Java, we could use it within our Java-based
Engine build. It seems that YUI Compressor uses Rhino (JS engine written
in Java) with some custom Rhino extensions/tweaks.

I didn't find Fedora package for YUI Compressor, but I found this:

  http://davidb.github.io/yuicompressor-maven-plugin/

And luckily, this Maven plugin is also in JBoss Maven repo:

  
https://repository.jboss.org/nexus/service/local/repositories/central/content/net/alchim31/maven/yuicompressor-maven-plugin/1.4.0/yuicompressor-maven-plugin-1.4.0.pom

OK, now some bad news. According to this:

  http://www.yuiblog.com/blog/2012/10/16/state-of-yui-compressor/

development on YUI Compressor continues through JavaScript (surprise!)
project yUglify (it's based on UglifyJS which I proposed way above):

  https://github.com/yui/yuglify

And, not surprisingly, yUglify is Node.js module. Here we go :)

As everyone can see, all popular tools for JavaScript development
are pretty much centered around Node.js, that is not coincidence.
Avoiding Node.js for JavaScript development complicates the whole
development and build process (from developer's perspective).

OK, now what we can do. I suggest to use wro4j (Java-based):

  https://code.google.com/p/wro4j/

wro4j uses Rhino to execute most of its processors

Re: [ovirt-devel] Tools for developing and building oVirt.js project

[Vojtech Szocs]

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Sandro Bonazzola sbona...@redhat.com
 Cc: infra infra@ovirt.org, de...@ovirt.org
 Sent: Friday, August 29, 2014 4:43:44 PM
 Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js project
 
 
 
 - Original Message -
  From: Sandro Bonazzola sbona...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com
  Cc: Tomas Jelinek tjeli...@redhat.com, Mooli Tayer
  mta...@redhat.com, de...@ovirt.org, infra
  infra@ovirt.org
  Sent: Friday, August 29, 2014 8:05:58 AM
  Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js
  project
  
  Il 28/08/2014 21:00, Vojtech Szocs ha scritto:
   
   
   - Original Message -
   From: Sandro Bonazzola sbona...@redhat.com
   To: Tomas Jelinek tjeli...@redhat.com, Mooli Tayer
   mta...@redhat.com
   Cc: de...@ovirt.org
   Sent: Tuesday, August 26, 2014 12:03:14 PM
   Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js
   project
  
   Il 26/08/2014 09:38, Tomas Jelinek ha scritto:
  
  
   - Original Message -
   From: Mooli Tayer mta...@redhat.com
   To: Greg Sheremeta gsher...@redhat.com
   Cc: de...@ovirt.org
   Sent: Tuesday, August 26, 2014 9:17:20 AM
   Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js
   project
  
   Are we talking about using node as a development/test/packaging(minify
   etc
   )
   tool or having a runtime backend (site) on top of node?
  
   It is only devel environment (e.g. build dependency), not runtime.
  
  
   If it's build dependency it's not just devel environment.
   
   Right, I messed up my comment above, sorry.
   
   Node.js can be (and typically is) used as both devel  build dependency
   for JavaScript projects.
   
   We must ensure that all required build dependencies are available and
   properly packaged for all supported distributions.
   
   Yes, fully agreed.
   
   Fedora already has some packages we could use, for example:
   http://koji.fedoraproject.org/koji/packageinfo?packageID=15154
   http://koji.fedoraproject.org/koji/packageinfo?packageID=15356
   
   However, there's one complication (as Greg mentioned before): npm (Node
   package manager) resolves Node-specific packages (esentially JavaScript
   artifacts) via HTTP access, so we'd need some infra to serve these, and
   for each such JS module:
   - either use existing package for that JS module, if one exists
   - or maintain package for that JS module on our own [*]
   
   [*] I understand that this is not what we want to do in general
  
  I would add
  - Ask supported distributions to provide needed rpms
 
 Well, that ^^ would be ideal.
 
  
   
   In other words, there would have to be some infra to support builds for
   JavaScript/Node.js projects, similar to existing infra to support builds
   for Java/Maven projects:
   - package for Node.js + npm
   - package for each JS module (likely problematic)
   - tool (existing Artifactory that serves Maven artifacts?) to serve
 JS modules via HTTP for npm to consume (maybe problematic)
   
  
  Adding infra for above
  
  
   In any case, we can proceed with developing oVirt.js without requiring
   Node.js as a build dependency. I see two possible solutions here:
   
   1, avoid using build tools like Traceur (ES6 - ES5 transpiler)
  and UglifyJS (code compressor/obfuscator), just concatenate
  JS source files into resulting JS target file (either via
  command in Makefile or via some Maven plugin)
   
  PROS: no special build requirements
  CONS: can't use tools like Traceur
   
   2, use build tools like Traceur and UglifyJS, commit resulting
  JS target file into source tree, maybe with git commit hook
  for this
   
  PROS: can use tools like Traceur
  CONS: storing target JS file in source tree
   
   3, (?)
  
  Use something simpler to package for compressing / minimizing like
  http://yui.github.io/yuicompressor/ or any other tool like that at build
  time
  (nothing against Node.js at development time).
 
 YUI Compressor is written in Java, we could use it within our Java-based
 Engine build. It seems that YUI Compressor uses Rhino (JS engine written
 in Java) with some custom Rhino extensions/tweaks.
 
 I didn't find Fedora package for YUI Compressor, but I found this:
 
   http://davidb.github.io/yuicompressor-maven-plugin/
 
 And luckily, this Maven plugin is also in JBoss Maven repo:
 
   
 https://repository.jboss.org/nexus/service/local/repositories/central/content/net/alchim31/maven/yuicompressor-maven-plugin/1.4.0/yuicompressor-maven-plugin-1.4.0.pom
 
 OK, now some bad news. According to this:
 
   http://www.yuiblog.com/blog/2012/10/16/state-of-yui-compressor/
 
 development on YUI Compressor continues through JavaScript (surprise!)
 project yUglify (it's based on UglifyJS which I proposed way above):
 
   https://github.com/yui/yuglify
 
 And, not surprisingly, yUglify is Node.js module. Here we go

Source code syntax highlight support in ovirt.org MediaWiki

[Vojtech Szocs]

Hi guys,

it would be great if MediaWiki that powers ovirt.org supported source code 
syntax highlighting. This would improve readability of wiki pages that include 
source code snippets in various languages or formats.

I've created a Trac ticket for this: https://fedorahosted.org/ovirt/ticket/32

Thanks!
Vojtech
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Source code syntax highlight support in ovirt.org MediaWiki

[Vojtech Szocs]

Hi Dave,

 Do you know if the GeSHi extension is well audited and popular?

To me, SyntaxHighlight_GeSHi extension [1] seems to be quite popular (lots of 
hits on Google and Stackoverflow), has stable release status and supports 
MediaWiki 1.11.+ (ovirt.org currently runs 1.19.2). It also seems to be alive 
with recent updates [2]. Turns out that Generic Syntax Highlighter (GeSHi) [3] 
is one of most widely used highlighters out there.

Another alternative is GoogleCodePrettify extension [4], newer than 
SyntaxHighlight_GeSHi but with less features, plus it doesn't seem to be too 
alive - latest update June 2012 [5]. Other similar extensions I found are 
either beta or have limited MediaWiki version support (but maybe I have missed 
something).

So I'd personally vote for SyntaxHighlight_GeSHi, but any similar extension 
would do as well.

Thanks,
Vojtech

[1] http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi
[2] 
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SyntaxHighlight_GeSHi.git
[3] http://qbnz.com/highlighter/
[4] http://www.mediawiki.org/wiki/Extension:GoogleCodePrettify
[5] https://github.com/Undev/MediaWiki-GoogleCodePrettify/commits/


- Original Message -
From: Dave Neary dne...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: infra infra@ovirt.org
Sent: Friday, January 18, 2013 3:52:40 PM
Subject: Re: Source code syntax highlight support in ovirt.org MediaWiki

Thanks Vojtech! I will look at this as soon as I get a chance 
(definitely sometime in 2013!)

Do you know if the GeSHi extension is well audited and popular?

Thanks!
Dave.

On 01/18/2013 03:39 PM, Vojtech Szocs wrote:
 Hi guys,

 it would be great if MediaWiki that powers ovirt.org supported source code 
 syntax highlighting. This would improve readability of wiki pages that 
 include source code snippets in various languages or formats.

 I've created a Trac ticket for this: https://fedorahosted.org/ovirt/ticket/32

 Thanks!
 Vojtech


-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra