The proposal job to update the plugin list has been failing for a long
time as it gets a 500 error from gitea on the openstack/openstack
repo. This is an odd "superrepo" with all projects as submodules;
thus openstack/openstack/devstack is actually a project, not the
directory with a plugin in it.
Skip this repo (gitea shouldn't return a 500, but that's another
thing...)
Regenerate the list manually for this run.
Change-Id: I6ed65bcb720d4cb10702cbf66106120e001ec35f
A 500 error from gitea can occasionally show up as a project dropping
their devstack plugin (I543faced83a685d48706d004ae49800abfb89dc5).
To avoid noise in the proposal jobs, implement a small retry loop for
500 errors.
Change-Id: Ide23e4de819a2c751d887eeaa7f0b9d0437f8e2c
This updates links going to git.openstack.org and review.openstack.org
to go to their respective opendev locations to avoid redirects.
Change-Id: I78e3bb5303718962f591117f9c0ee11f2314b128
Closes-Bug: #1833256
Update the server to opendev and update paths for gitea, along with
any other references.
Switch to a blacklist where we just remove stackforge; this leaves all
the new namespaces like x/ and starlingx/ being checked.
Use a common session for checking for the plugin file which makes it a
*lot* faster.
Remove unsed "plugins" array variable
Regenerate the file
Change-Id: Ie3e615ba352a389da22e129c5c67cf6abd8cfdc8
A couple of hundred of these were added with
Ia02f4e1819ac47b12b4ce4381e04253eb26e9f70 and you can see in some of
the proposals at I21fd2b3866efe66dd1f7173003c2521688aa7fd6 they're
starting to match. Just ignore packaging repos as they're not really
relevant for the purposes of plugin list.
Change-Id: Iaf9e0c0fb672a70c3aee1bbcf587bb0d387e5945
As can be seen in logs of the periodic generation job, our cgit does a
weird thing where sometimes it returns a 404 page with content, and
sometimes a zero response (see [1] for example, the last number is
response size). This appears to be an openstack CI issue; possibly
due to cgit caching or similar (see [2] for manual test). It will
have to be investigated with the host apache logs.
This is resulting in a lot of projects incorrectly being picked up as
having plugins (I7116571d2a2b1fc3a61e5f1ed46ac2cbc244775a). I'm not
sure if this problem is also releated to the original status-code
issues mentioned in the code, but testing shows that cgit is correctly
returning 404's for missing files (you can see in the logs [1]). Thus
switch the logic to examine the return code which avoids this issue.
[1] http://logs.openstack.org/periodic/propose-devstack-plugins-list/e55790c/console.html.gz#_2016-05-04_06_46_51_660
[2] http://paste.openstack.org/show/496434/
Change-Id: I6a06347d91d091441f6f7b70f99aba6d8e9add4b
We've had a couple of cases where plugin names are longer than our
table width.
Take the fixed-with table-header out of the header file, and generate
it dynamically based on first-column width. To simplify, take
advantage that RST allows a variable-length last column and so don't
specify it's width.
Add a link to the cgit URL for each project you can click on to browse
the source (link text remains the git:// URL).
Add some logging so you can see what the python generator is doing,
should you run it.
Change-Id: I5d5e692039bbb30b2508119412472dac1d105c08
The devstack plugins list can be generated through web requests in
environments (such as the proposal slave) that lack copies of all
the relevant git repositories.
One downside to this is that there is no way of getting the last
modification time of the plugin.
Change-Id: I2c5c9282a8ad80014cad171a4dfbdc8f26044cd1
