[PATCH] automation: add a build job with NR_CPUS == 1

[PATCH] automation: add a build job with NR_CPUS == 1

[Roger Pau Monne]

This requires adding some logic in the build script in order to be
able to pass specific Xen Kconfig options.

Setting any CONFIG_* environment variable when executing the build
script will set such variable in the empty .config file before
running the olddefconfig target. The .config file is also checked
afterwards to assert the option has not been lost as part of the
configuration process.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
---
Not sure whether there's some easiest way to force a config option to
a set value from the command line.
---
 automation/gitlab-ci/build.yaml | 12 ++++++++++++
 automation/scripts/build        | 16 ++++++++++++++++
 2 files changed, 28 insertions(+)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index d00b8a5123..06d943de83 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -308,6 +308,18 @@ debian-unstable-gcc-debug-randconfig:
     CONTAINER: debian:unstable
     RANDCONFIG: y
 
+debian-unstable-gcc-nrcpus1:
+  extends: .gcc-x86-64-build
+  variables:
+    CONTAINER: debian:unstable
+    CONFIG_NR_CPUS: 1
+
+debian-unstable-gcc-debug-nrcpus1:
+  extends: .gcc-x86-64-build-debug
+  variables:
+    CONTAINER: debian:unstable
+    CONFIG_NR_CPUS: 1
+
 debian-unstable-32-clang:
   extends: .clang-x86-32-build
   variables:
diff --git a/automation/scripts/build b/automation/scripts/build
index 87e44bb940..4c331b6b57 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -11,6 +11,22 @@ cc-ver()
 # random config or default config
 if [[ "${RANDCONFIG}" == "y" ]]; then
     make -j$(nproc) -C xen KCONFIG_ALLCONFIG=tools/kconfig/allrandom.config randconfig
+elif [[ "${!CONFIG_@}" != "" ]]; then
+    for config in "${!CONFIG_@}"; do
+        printf '%s=%s\n' "$config" "${!config}" >> xen/.config
+    done
+    make -j$(nproc) -C xen olddefconfig
+    for config in "${!CONFIG_@}"; do
+        if [[ "${!config}" != "n" ]]; then
+            option=$(printf '%s=%s' "$config" "${!config}")
+        else
+            option=$(printf '# %s is not set' "$config")
+        fi
+        if ! grep -q "^${option}$" xen/.config; then
+            echo "Failed to set ${config} in Kconfig"
+            exit 1;
+        fi
+    done
 else
     make -j$(nproc) -C xen defconfig
 fi
-- 
2.30.1

Re: [PATCH] automation: add a build job with NR_CPUS == 1

[Andrew Cooper]

On 03/03/2021 08:33, Roger Pau Monne wrote:
> This requires adding some logic in the build script in order to be
> able to pass specific Xen Kconfig options.
>
> Setting any CONFIG_* environment variable when executing the build
> script will set such variable in the empty .config file before
> running the olddefconfig target. The .config file is also checked
> afterwards to assert the option has not been lost as part of the
> configuration process.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Jan Beulich <jbeulich@suse.com>
> ---
> Not sure whether there's some easiest way to force a config option to
> a set value from the command line.

I'm -2 to this.  We've already use thousands of machine minutes per
push, and this corner case isn't worth adding another 30 minutes or so
per push.

What would be far more useful is for randconfig to be weighted to choose
1, something around BITS_PER_LONG, and something around max preferentially.

~Andrew

Re: [PATCH] automation: add a build job with NR_CPUS == 1

[Roger Pau Monné]

On Wed, Mar 03, 2021 at 11:46:44AM +0000, Andrew Cooper wrote:
> On 03/03/2021 08:33, Roger Pau Monne wrote:
> > This requires adding some logic in the build script in order to be
> > able to pass specific Xen Kconfig options.
> >
> > Setting any CONFIG_* environment variable when executing the build
> > script will set such variable in the empty .config file before
> > running the olddefconfig target. The .config file is also checked
> > afterwards to assert the option has not been lost as part of the
> > configuration process.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Cc: Jan Beulich <jbeulich@suse.com>
> > ---
> > Not sure whether there's some easiest way to force a config option to
> > a set value from the command line.
> 
> I'm -2 to this.  We've already use thousands of machine minutes per
> push, and this corner case isn't worth adding another 30 minutes or so
> per push.

In fact I think those builds could be hypervisor only, which will
limit them to a couple of minutes?

Would that be an acceptable compromise?

Not just to test NR_CPUS, but in general for testing specific Kconfg
options.

Likely randconfig should also be an hypervisor build only, there's no
reason to do a build test of the tools with a hypervisor randconfig.
Let me prepare a patch for that.

Thanks, Roger.

Re: [PATCH] automation: add a build job with NR_CPUS == 1

[Andrew Cooper]

On 03/03/2021 11:57, Roger Pau Monné wrote:
> On Wed, Mar 03, 2021 at 11:46:44AM +0000, Andrew Cooper wrote:
>> On 03/03/2021 08:33, Roger Pau Monne wrote:
>>> This requires adding some logic in the build script in order to be
>>> able to pass specific Xen Kconfig options.
>>>
>>> Setting any CONFIG_* environment variable when executing the build
>>> script will set such variable in the empty .config file before
>>> running the olddefconfig target. The .config file is also checked
>>> afterwards to assert the option has not been lost as part of the
>>> configuration process.
>>>
>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>> ---
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> Not sure whether there's some easiest way to force a config option to
>>> a set value from the command line.
>> I'm -2 to this.  We've already use thousands of machine minutes per
>> push, and this corner case isn't worth adding another 30 minutes or so
>> per push.
> In fact I think those builds could be hypervisor only, which will
> limit them to a couple of minutes?
>
> Would that be an acceptable compromise?
>
> Not just to test NR_CPUS, but in general for testing specific Kconfg
> options.
>
> Likely randconfig should also be an hypervisor build only, there's no
> reason to do a build test of the tools with a hypervisor randconfig.
> Let me prepare a patch for that.

This is already a plan for the CI working group (along with other
randconfig improvements) but it has yet to be implemented.

~Andrew