|
cgit cannot know whether the ref being viewed actually has a pipeline, so
the "ci" tab is offered for every ref and only reveals a missing one once
followed. Probing the ci system from cgit is not an option: the tab is
part of the page header, so it would mean a blocking request for every
page of every repository, cgit links no http client, and job pages are
usually not readable anonymously.
Add a ci filter instead, which receives the ref, whether it is a branch or
a tag, and the expanded url, and answers with its exit status. This keeps
credentials, timeouts and caching in a script, where they belong;
filters/ci-jenkins.sh demonstrates all three against Jenkins' REST API.
The verdict is memoized, so the filter runs once per request rather than
once for the tab and again for the redirect, and it governs the page as
well as the tab, so a hidden tab cannot be reached by typing the url.
Signed-off-by: Saya Andy <saya.andy@posteo.com>
|
|
Add a "ci" page which redirects to an external ci system for the ref
being viewed, along with a tab for it in the repository header.
The target is a url template, configurable globally or per repository,
with separate settings for branches and tags because pipelines for the
two commonly live at different locations: on a Jenkins multibranch
pipeline a branch is at job/<name>/job/<ref> while a tag is at
job/<name>/view/tags/job/<ref>. $ref, $repo and $slug are substituted,
$slug being the repository url with any ".git" suffix removed and slashes
replaced by dashes, which is the shape job names usually take.
An explicit repo.ci-url drops the branch and tag urls the repository
would otherwise inherit from the global settings, as it could never take
effect otherwise.
The expansion is written to the Location header verbatim rather than
through cgit_redirect(), which percent-encodes '?', '=' and '%' and would
corrupt any url carrying a query string. An expansion containing CR or LF
is refused so that it cannot smuggle in further headers.
Signed-off-by: Saya Andy <saya.andy@posteo.com>
|