REGEX, REGEX_URI and GITTAGREGEX are replaced by UPSTREAM_CHECK_REGEX,
UPSTREAM_CHECK_URI and UPSTREAM_CHECK_GITTAGREGEX
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add logger.setLevel to enable set log level.
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Although it's unlikely to be an issue, technically we shouldn't be
insisting the sha1 field be unique globally, just within each
layerbranch, so adjust the constraints.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If automated emails are enabled, we need to ensure that the other email
fields are populated, so validate that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Most layers do not track maintenance on a per-recipe basis, and for
those layers we will hide some of the per-recipe maintainer features
and on the recipe detail show the layer maintainer(s) as the
maintainer(s) of the recipe.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we're in a repository containing multiple layers, we don't care about
commits that don't affect the layer we are processing, so skip those
commits rather than passing them to upgrade_history_internal.py which
will ignore them (which is significantly slower).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The processing code can't currently handle if a layerbranch is part of
more than one plan, so disallow that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The patterns() function is deprecated in Django 1.8 and gone in 1.10, so
we should switch over to the new list format.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
RecipeUpstreamHistory was not linked to the layer it was produced from,
which meant that it wasn't easy to query for a different maintenance
plan (i.e. a different layer) and thus the maintenance plan selection
on the recipe list didn't really work. Add a link field, populate it in
a migration and then make it required.
We had added a link earlier from RecipeMaintainerHistory to LayerBranch
but it was optional; for the same reasons we now populate it and make it
required.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
These two functions aren't being used anywhere. In the interest of
having as little code directly reading the database using SQL as
possible, drop them.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add an option to specify which maintenance plan to operate on (largely
for debugging purposes).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Ensure the Release and Milestone names are separated by a space when
listing Milesones
* Include the maintenance plan name in the name shown for each
Release/Milestone
* Allow filtering Releases/Milestones by maintenance plan
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
It's a pain to have to add all the releases when adding a new
maintenance plan. Since these are likely to be the same (or similar) for
every plan, then duplicate them across from the first plan when you save
a new one.
Also add "default" milestones on the assumption that other layers
probably won't want to use the 4-milestone split per release, but there
do have to be some milestone records, so just create one milestone for
each release.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
It's a bit of a pain to have to set the two python environment fields on
every record in order to have things set correctly, and it can easily
get forgotten, so try to set them automatically by default (assuming
reasonable naming).
Note that this does introduce an annoying behaviour whereby if you click
"Add another Maintenance plan layer branch" and then decide you don't
want it, the admin form will insist you fill in the fields unless you
clear out the python2/3 environment fields. I'm not sure how to fix
that, so I'm leaving it as-is for now.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
I missed changing this constraint when adding the plan field. We want to
be able to have the same named release on another plan.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Expose the newly added patch information in the RRS:
* Add a table to the recipe detail listing the patches for the recipe
* Add pending / total counts to the recipe list page
Implements [YOCTO #7909].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Consolidate the code for checking out a repository, using the newly
added utils.checkout_repo() function
* Check out a layer's dependencies, not just the layer itself
* Only check out if the desired revision isn't already checked out
(mostly useful for bitbake which we would otherwise be checking out
much more frequently than necessary since it may not have changed
even if we've moved to a new commit in the layer).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The Recipe Reporting System needs to be able to provide links to commits
in the web interface for the repository, but we can only do this if we
have a custom template URL just like we do for file/tree links, since
it's different for different git web interfaces. Add support in all the
various places for such a URL and make use of it in the RRS.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Provide a mechanism set the maintainer for things like gcc-cross-<arch>
to the same as gcc. (We do have entries in the .inc file for these,
however they aren't useful as they don't match the recipe name when we
parse it, and due to the fact that RecipeMaintainer objects link
directly to Recipe objects, we can't handle entries that don't map to a
real recipe).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We don't actually need to check out the repository until we actually
analyse a commit, so avoid doing so. Additionally, there's not much
point in checking out master at the end, let the next script invocation
do that if needed (if it needs to, it should since otherwise there's no
guarantee what state the repository is in).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add an option that deletes all maintainer history records for the
current layer branch so that they can then be reloaded from scratch.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We don't really need to clean up the repository, we'll take care of it
on subsequent runs.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If a recipe upgrade only consists of a .inc file changing, we were not
picking it up, since we were only looking specifically for recipes
(.bb). If a .inc file changes, assume all .bb files in the same
directory (if any) should be parsed to look for an upgrade.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
load_recipes() was leaving files around in /tmp; on my Fedora system
this eventually resulted in /tmp running out of space which we do not
want.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Sometimes it's useful to be able to re-try processing a particular
commit (generally in conjunction with --dry-run), so add an option to
enable that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We were parsing recipes that were in the repository but not inside the
actual layer we're dealing with (e.g. we have meta-selftest within the
OE-Core repository, containing a number of recipes that are only
intended for testing purposes and should not be looked at by this
script).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If an exception occurs during parsing, let's actually see what kind of
exception it was in the output.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
In OE-Core revision e0531174119bff21e9014b95ed1bbd0e1c01af26 we
accidentally committed a new e2fsprogs recipe with ..bb at the end of
its name instead of .bb. This was fixed immediately afterwards, but when
the RRS hits this commit, it doesn't fail immediately, but the bogus
version "1.43." gets into the database and all subsequent commits
touching the e2fsprogs recipe cause bb.utils.vercmp_part() to blow up
because one of the version parts in the "previous" version in the database
is apparently empty. To work around this and any similar issues, just
reject any change that results in such a broken version string (on the
assumption that it'll be corrected in a subsequent commit and thus we
will get to re-parse the recipe then and therefore not miss the
upgrade.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We check out different revisions while we do this processing, and so
does the layer index update script, so we shouldn't be allowing both to
run at once or nasty stuff will happen.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Since we're now executing a separate script per commit, we should try
not to do that unless the commit actually touches recipe files in order
to avoid wasting time.
(Whilst it's possible that a change to a bbclass might alter what's in
the recipe, we can ignore that since we are only concerned with actual
upgrades which would always require some sort of change to the recipe or
an include file, so we can safely skip commits that don't do that.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Instead of arbitrarily importing the last 8 days of upgrades, record the
date and commit when we do an import, and then use that information the
next time the script is run.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We should expect multiple matches for layerbranch + pn, so use filter()
instead of get() and take the first id that matches.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We're calling translate() on the string deep in the bowels of the
parsing code and that doesn't work well if the string is unicode, so
convert it to a plain string first. That won't work well if the filename
is unicode but the chances of that with a recipe is pretty small I would
think.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Use try...finally to ensure we shut down tinfoil, but since we are
potentially dealing with older bitbake releases when importing older
upgrades, only call shutdown() if it's actually there (and although it's
unlikely, guard against the broken shutdown() in fido as we do in the
main layer index update script).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If you want to go back and get history for the earlier releases (krogoth
and previous) then we need to be able to support both python 2 and 3,
which practically means we need the same split for this script as we
have for the main layer index update script.
The catch here is that since we are going back and following the history
of changes forward, we basically need to use the same version of bitbake
that was current at that time. This works except for around the
transition between python 2 to 3 where the metadata lagged behind a bit,
so we need to take that into account. In order to keep things generic we
have a date field on the maintenance plan layer branch that specifies
the date in the metadata where we should switch over to python 3, and
then link to PythonEnvironment records that should be used for python 2
and 3 respectively.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The old RRS branch had its own addition of dependency support, but in the
mean time we added that to the layer index in the master branch using a
different structure. Adapt the RRS recipe detail page to that structure.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If the RRS is enabled, then add a way to get from the layer detail page
to any maintenance plans in which the layer is included.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Fixtures aren't supported in current Django versions. Add some code to
the initial migration to add the data instead.
Also add releases/milestones up to and including 2.5.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We were passing in a parameter value but not using that in the query.
Add a WHERE clause to fix that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Table names should be lowercase. I'm unsure if the collation settings
have an effect on this, but with the mariadb database I set up here I
needed to make this change or else I got errors about missing tables.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we call objects.get() with no matching record then the result will be
an exception, not a null return, so handle that properly.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
