From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
To: "Aníbal Limón" <anibal.limon@linux.intel.com>,
openembedded-core@lists.openembedded.org
Cc: paul.eggleton@linux.intel.com
Subject: Re: [PATCH v2 2/2] oeqa/selftest: new tests for devtool upgrage feature
Date: Wed, 26 Aug 2015 11:29:37 -0500 [thread overview]
Message-ID: <55DDE971.3040803@linux.intel.com> (raw)
In-Reply-To: <55DDE63D.4020204@linux.intel.com>
On 08/26/2015 11:15 AM, Aníbal Limón wrote:
> Comments below.
>
> On 26/08/15 02:43, leonardo.sandoval.gonzalez@linux.intel.com wrote:
>> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
>>
>> Basic tests for the devtool's upgrade feature, including:
>> * Parameter check
>> * Upgrading a real recipe (e2fsprogrs) without patching and
>> checing its output
>> * Devtool status after upgrade
>>
>> Signed-off-by: Leonardo Sandoval
>> <leonardo.sandoval.gonzalez@linux.intel.com>
>> ---
>> meta/lib/oeqa/selftest/devtool.py | 36
>> ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>>
>> diff --git a/meta/lib/oeqa/selftest/devtool.py
>> b/meta/lib/oeqa/selftest/devtool.py
>> index b59db15..f72e010 100644
>> --- a/meta/lib/oeqa/selftest/devtool.py
>> +++ b/meta/lib/oeqa/selftest/devtool.py
>> @@ -857,3 +857,39 @@ class DevtoolTests(DevtoolBase):
>> result = runCmd('devtool undeploy-target -c %s root@%s'
>> % (testrecipe, qemu.ip))
>> result = runCmd('ssh %s root@%s %s' % (sshargs, qemu.ip,
>> testcommand), ignore_status=True)
>> self.assertNotEqual(result, 0, 'undeploy-target did not
>> remove command as it should have')
>> +
>> + def test_devtool_upgrade(self):
>> + # Check preconditions
>> + workspacedir = os.path.join(self.builddir, 'workspace')
>> + self.assertTrue(not os.path.exists(workspacedir), 'This test
>> cannot be run with a workspace directory under the build directory')
>> + # Check parameters
>> + result = runCmd('devtool upgrade -h')
>> + for param in 'recipename srctree --version -V --branch -b
>> --keep-temp --no-patch'.split():
>> + self.assertIn(param, result.output)
>> + # For the moment, we are using a real recipe.
>> + recipe='e2fsprogs'
>> + version='1.42.13'
>
> Isn't a guarantee that this version will be newer ever (i.e. if someone
> upgrade e2fsprogs to 1.42.13) what happen in this case?
Good question. In fact, the code will fail just in case current and
upgrade version are the same. The tool can also do downgrades, so at the
end it does not matter what the version is. I will correct this point
and send a v3.
As mentioned by Paul in a previous message, we need 'upgradable' recipes
which whenever the test is done, it can be upgrade. The only point here
is that we need a tarball somewhere, so the URL is always live. Not sure
if poky repository is a good place for the latter, any suggestion?
>> + tempdir = tempfile.mkdtemp(prefix='devtoolqa')
>> + # Check that recipe is not already under devtool control
>> + result = runCmd('devtool status')
>> + self.assertNotIn(recipe, result.output)
>> + # Check upgrade. Code does not check if new PV is older or
>> newer that current PV, so, it may be that
>> + # we are downgrading instead of upgrading.
>> + result = runCmd('devtool upgrade %s %s -V %s --no-patch' %
>> (recipe, tempdir, version))
>> + # Check if srctree at least is populated
>> + self.assertTrue(len(os.listdir(tempdir)) > 0, 'scrtree (%s)
>> should be populated with new (%s) source code' % (tempdir, version))
>> + # Check new recipe folder is present
>> +
>> self.assertTrue(os.path.exists(os.path.join(workspacedir,'recipes',recipe)),
>> 'Recipe folder should exist')
>> + # Check new recipe file is present
>> +
>> self.assertTrue(os.path.exists(os.path.join(workspacedir,'recipes',recipe,"%s_%s.bb"
>> % (recipe,version))), 'Recipe folder should exist')
>> + # Check devtool status and make sure recipe is present
>> + result = runCmd('devtool status')
>> + self.assertIn(recipe, result.output)
>> + self.assertIn(tempdir, result.output)
>> + # Check devtool reset recipe
>> + result = runCmd('devtool reset %s -n' % recipe)
>> + result = runCmd('devtool status')
>> + self.assertNotIn(recipe, result.output)
>> + self.track_for_cleanup(tempdir)
>> + self.track_for_cleanup(workspacedir)
>> + self.add_command_to_tearDown('bitbake-layers remove-layer
>> */workspace')
>
next prev parent reply other threads:[~2015-08-26 16:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 7:43 [PATCH v2 0/1] devtool: upgrade feature leonardo.sandoval.gonzalez
2015-08-26 7:43 ` [PATCH v2 1/2] " leonardo.sandoval.gonzalez
2015-08-26 16:09 ` Aníbal Limón
2015-08-26 16:23 ` Leonardo Sandoval
2015-08-27 0:04 ` Paul Eggleton
2015-08-27 13:24 ` Leonardo Sandoval
2015-08-27 13:29 ` Otavio Salvador
2015-08-27 20:08 ` Leonardo Sandoval
2015-08-26 7:43 ` [PATCH v2 2/2] oeqa/selftest: new tests for devtool upgrage feature leonardo.sandoval.gonzalez
2015-08-26 16:15 ` Aníbal Limón
2015-08-26 16:29 ` Leonardo Sandoval [this message]
2015-08-26 16:47 ` Paul Eggleton
2015-08-26 16:51 ` Leonardo Sandoval
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55DDE971.3040803@linux.intel.com \
--to=leonardo.sandoval.gonzalez@linux.intel.com \
--cc=anibal.limon@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox