| Age | Commit message (Collapse) | Author |
|---|
|
patches that are targeted to previous releases (other than
master) are not tracked in patchwork.
This change allows tracking older releases by adding morty,
pyro and rocko branches to patchwork's STATE_MAP, so
appropriate patch status can be assigned.
[YOCTO #10716]
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
|
|
Periodic master-next branch updates can modify state in
patchwork for patches that are already in Accepted state,
missleading users about the actual patch integration status.
This change validates the current state of the patch to
skip the change if it is Accepted.
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
|
|
post-receive hook may not found merged commits when called from
git repositories located in directories outside from current
location.
This change includes the git working directory as input parameter
and executing git commands at the directory where the git push was
originated. Also, output is logged to a file instead of display.
[YOCTO #10715]
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
|
|
This Git post-receive hook asynchronously updates Patchwork patches
to "Accepted " state after Git pushes to master branch
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
|
|
patches which descripes renamed files show different hashes with git
show and pwclient. Use git show -C (Detect copies as well as renames.)
Signed-off-by: Jan Remmet <j.remmet@phytec.de>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
Belen reported that the "quick start" for developers didn't work for
her. That was because the test instance was running on a different
machine than her main machine. We should totally allow that by not
binding the HTTP server to 127.0.0.1 only.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
Michael Ellerman noticed we weren't using shebangs in those scripts. I
shrugged it off too quickly in the review, because it worked after all.
Turned out to be a bashmism, along with the usage of 'source'.
With those fixed, we have a better chance to run on most shells (famous
last words). Tested it with bash and dash.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
Signed-off-by: Gabriel Ciubotaru <gabriel.ciubotaru@intel.com>
|
|
This change updates patchwor to the newer project struture: we've moved
the actual application out of the apps/ directory, and the
patchwork-specific templates to under the patchwork application.
This gives us the manage.py script in the top-level now.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
When merging upstream work related to other projects into your own
project repository, you probably don't want to check for (and try to
update) the status on every change-set in the merge. So add a list of
references (branches, tags, commits, etc.) whose commits should be
ignored in the patch update step.
This could be used, for example, to set:
EXCLUDE="refs/heads/upstream"
Then when you're ready to merge in new upstream code, you first update
the 'upstream' branch before pushing your own.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Previously, if STATE_MAP contained only refs/heads/master and a user
pushed to a branch such as refs/heads/stable, the hook emitted a
misleading error message:
E: no mapping for refname refs/heads/master
Fix this by correctly printing the reference being looked for, rather
than the reference most recently found in STATE_MAP. Also, reword the
message slightly to point the user to STATE_MAP and to use an actual
word "branch" instead of the non-word "refname".
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Older versions of patchwork shipped with a version of pwclient that
had the view command, but not info command. Now that info exists, it's
inefficient to use it to obtain the patchwork ID value, (since it
requires the server to send the entire patch content in response to an
XML RPC request).
So be kind to the server by using info instead, (which has a small,
fixed-length response).
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Previously, the post-receive hook would always examine one commit that
had been previously pushed, (when the purpose of the hook is only to
example newly-pushed commits). We fix this by simply dropping the '^'
in the commit-range specification.
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Otherwise the following error is shown:
Too many arguments specified
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Make patchwork-update-commits work from outside the Patchwork git
repository so it can be used for other projects.
Signed-off-by: Sascha Silbe <sascha-pgp@silbe.org>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Martin has allowed distribution under the GPL.
http://lists.ozlabs.org/pipermail/patchwork/2010-June/000263.html
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
This patch adds a post-receive hook to lib/git, which can be used to
update Patchwork following a push to the Git repository.
Surely, it can be improved. One thing to do would be to export the state
map to git-config somehow.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
Jose Lamego
Jan Remmet
Damien Lespiau
Gabriel Ciubotaru
Jeremy Kerr
Brian Norris
Carl Worth
Paul Menzel
Sascha Silbe
Martin Krafft