1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
// file : bdep/ci.cli
// copyright : Copyright (c) 2014-2019 Code Synthesis Ltd
// license : MIT; see accompanying LICENSE file
include <bdep/project.cli>;
"\section=1"
"\name=bdep-ci"
"\summary=submit project test request to CI server"
namespace bdep
{
{
"<options>
<prj-spec> <prj-dir>
<pkg-spec> <pkg-dir>
<cfg-spec> <cfg-name> <cfg-dir>",
"\h|SYNOPSIS|
\c{\b{bdep ci} [<options>] [<cfg-spec>] [<pkg-spec>]}
\c{<pkg-spec> = (\b{--directory}|\b{-d} <pkg-dir>)... | <prj-spec>\n
<prj-spec> = \b{--directory}|\b{-d} <prj-dir>\n
<cfg-spec> = \b{@}<cfg-name> | \b{--config}|\b{-c} <cfg-dir>}
\h|DESCRIPTION|
The \cb{ci} command submits the project packages test request to a CI
server.
If no project or package directory is specified, then the current working
directory is assumed. If no configuration is specified, then the default
configuration is used. If the specified directory is a project directory,
then all the packages initialized in the configuration are submitted. See
\l{bdep-projects-configs(1)} for details on specifying projects and
configurations.
A CI request consists of the specified packages and their versions as
well as the project's remote version control repository URL corresponding
to the current (local) state of the project. The CI server should be able
to fetch these package versions from this repository as well as any
dependencies from this repository or its prerequisite/complement
repositories, according to each package's \cb{repositories.manifest}.
If the CI server is not explicitly specified with the \cb{--server}
option, the request is submitted to \cb{ci.cppget.org} by default.
Unless the remote repository URL is specified with the \cb{--repository}
option, it will be automatically derived from the version control's
\"remote\" URL. In case of \cb{git(1)}, it will be based on the
\cb{remote.origin.url} configuration value unless overridden with
\cb{remote.origin.build2Url}. The repository URL is then adjusted to
corresponding to the current (local) state of the project. In case of
\cb{git(1)}, the current branch and commit id are added as the repository
URL fragment (see \l{bpkg-repository-types(1)} for details).
While the exact interpretation of the CI request depends on the specific
service, normally, the CI server will respond with a reference that can
be used to query the results. See \l{brep#ci Package CI} for details on
the CI request handling.
"
}
class cmd_ci_options: project_options
{
"\h|CI OPTIONS|"
bool --yes|-y
{
"Don't prompt for confirmation before submitting."
}
url --server
{
"<url>",
"CI server to submit the request to."
}
url --repository
{
"<url>",
"Remote repository URL for the project."
}
string --simulate
{
"<outcome>",
"Simulate the specified outcome of the CI process without actually
performing any externally visible actions (such as testing the packages
or publishing the result). The commonly used outcome value is
\cb{success}. For other recognized outcomes refer to the CI service
documentation."
}
};
}
|
