On 02/22/2016 08:26 AM, Aníbal Limón wrote:


On 02/22/2016 10:18 AM, Randy Witt wrote:
On 02/22/2016 07:03 AM, Aníbal Limón wrote:
From: Aníbal Limón <limon.ani...@gmail.com>

The SDKUpdateTest class test devtool sdk-update mechanism inside
eSDK.

The SDKUpdateTest class search for new sdk if not found uses
the main one then it publish the eSDK into known folder
inside work and it starts a web server for serve the eSDK.

Finally it executes sdk-update over http, the local test is
commented due to bug [1].

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=9043

[YOCTO #9089]

Signed-off-by: Aníbal Limón <limon.ani...@gmail.com>
---
   meta/lib/oeqa/sdkext/sdk_update.py | 39
++++++++++++++++++++++++++++++++++++++
   1 file changed, 39 insertions(+)
   create mode 100644 meta/lib/oeqa/sdkext/sdk_update.py

diff --git a/meta/lib/oeqa/sdkext/sdk_update.py
b/meta/lib/oeqa/sdkext/sdk_update.py
new file mode 100644
index 0000000..16f5b10
--- /dev/null
+++ b/meta/lib/oeqa/sdkext/sdk_update.py
@@ -0,0 +1,39 @@
+import os
+import shutil
+import subprocess
+
+from oeqa.oetest import oeSDKExtTest
+from oeqa.utils.httpserver import HTTPService
+
+class SdkUpdateTest(oeSDKExtTest):
+
+    @classmethod
+    def setUpClass(self):
+        self.publish_dir = os.path.join(self.tc.sdktestdir,
'esdk_publish')
+        if os.path.exists(self.publish_dir):
+            shutil.rmtree(self.publish_dir)
+        os.mkdir(self.publish_dir)
+
+        tcname_new = self.tc.d.expand(
+            "${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}-new.sh")
+        if not os.path.exists(tcname_new):
+            tcname_new = self.tc.tcname
+
+        cmd = 'oe-publish-sdk %s %s' % (tcname_new, self.publish_dir)
+        subprocess.check_output(cmd, shell=True)
+
+        self.http_service = HTTPService(self.publish_dir)
+        self.http_service.start()

I think Paul and I briefly mentioned it, but SimpleHTTPServer fails as
an sstate mirror if enough fetchers run. We think it was because of a
limit on the number of simultaneous connections. So I would expect this
to fail for instance if all packages were updated.

I tested running an update and didn't fail this implementation of
oeqa.utils open another process with multiprocessing for serve http only.

My suspicion is because nothing actually updated. And even if something updated, unless you hit the max connection limit when pulling from sstate_mirror it would be fine.


But really we shouldn't care too much about the sstate updating part,
and more about the layer updating etc. Ideally this test would check to
make sure the local sdk now matches the remote.

I could add a test for the output that i saw displays "Already updated"
or what you mean about match?

devtool sdk-update will check the remote conf/sdk-conf-manifest to see if any configuration changed. So for instance the creator of the sdk could add new configuration variables, or even items to bblayers.conf.

If the sdk-conf-manifest is changed, the updater should pull down the new layer by pulling(cloning if that fails) layers/.git on the remote and moving the layers to the appropriate local location. It should also update the local configuration to match what is on the remote.

So if you get "Already up-to-date" nothing changed and nothing was updated. To test the updating, we need to make sure the configuration actually changes, and potentially even add another layer, then update, and then make sure the local sdk matches what we think it should based on the remote sdk we published.



+        self.http_url = "http://127.0.0.1:%d"; % self.http_service.port
+
+    def test_sdk_update_http(self):
+        output = self._run("devtool sdk-update \"%s\"" % self.http_url)
+
+#    def test_sdk_update_local(self):
+#        output = self._run("devtool sdk-update \"%s\"" %
self.publish_dir)
+
+    @classmethod
+    def tearDownClass(self):
+        self.http_service.stop()
+        shutil.rmtree(self.publish_dir)




--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to