diff options
author | Florian Dold <florian.dold@gmail.com> | 2019-08-29 11:56:46 +0200 |
---|---|---|
committer | Florian Dold <florian.dold@gmail.com> | 2019-08-29 11:56:46 +0200 |
commit | 8244dc8bc4244ca3b9dcce2ef77cee3837c0a401 (patch) | |
tree | b9ad38b30fb414614fc7b7caabb8cdacc616a2cc | |
parent | 7b4d36717eb5ff48fa8ba18f854359b02d61dcd7 (diff) | |
download | deployment-8244dc8bc4244ca3b9dcce2ef77cee3837c0a401.tar.gz deployment-8244dc8bc4244ca3b9dcce2ef77cee3837c0a401.tar.bz2 deployment-8244dc8bc4244ca3b9dcce2ef77cee3837c0a401.zip |
doc no longer belongs here
-rw-r--r-- | doc/Makefile | 13 | ||||
-rw-r--r-- | doc/brown-paper.css | 63 | ||||
-rw-r--r-- | doc/docstyle.css | 85 | ||||
-rw-r--r-- | doc/onboarding.texi | 415 | ||||
-rw-r--r-- | doc/version.texi | 4 | ||||
-rwxr-xr-x | taler-docbuild/update_doc_bank.sh | 3 |
6 files changed, 0 insertions, 583 deletions
diff --git a/doc/Makefile b/doc/Makefile deleted file mode 100644 index 0c9f835..0000000 --- a/doc/Makefile +++ /dev/null @@ -1,13 +0,0 @@ -all: onboarding.pdf onboarding.html - -onboarding.pdf: onboarding.texi - texi2pdf onboarding.texi - -onboarding.html: onboarding.texi - texi2any --html --no-split --css-ref=docstyle.css --css-ref=brown-paper.css onboarding.texi - -clean: - rm -f onboarding.html onboarding.pdf - -info_TEXINFOS = onboarding.texi -manual_TEXINFOS = version.texi diff --git a/doc/brown-paper.css b/doc/brown-paper.css deleted file mode 100644 index 65e2e79..0000000 --- a/doc/brown-paper.css +++ /dev/null @@ -1,63 +0,0 @@ -/* - -Brown Paper style from goldblog.com.ua (c) Zaripov Yura <yur4ik7@ukr.net> - -*/ - -.hljs { - display: block; - overflow-x: auto; - padding: 0.5em; -} - -.hljs-keyword, -.hljs-selector-tag, -.hljs-literal { - color:#005599; - font-weight:bold; -} - -.hljs, -.hljs-subst { - color: #363c69; -} - -.hljs-string, -.hljs-title, -.hljs-section, -.hljs-type, -.hljs-attribute, -.hljs-symbol, -.hljs-bullet, -.hljs-built_in, -.hljs-addition, -.hljs-variable, -.hljs-template-tag, -.hljs-template-variable, -.hljs-link, -.hljs-name { - color: #2c009f; -} - -.hljs-comment, -.hljs-quote, -.hljs-meta, -.hljs-deletion { - color: #802022; -} - -.hljs-keyword, -.hljs-selector-tag, -.hljs-literal, -.hljs-doctag, -.hljs-title, -.hljs-section, -.hljs-type, -.hljs-name, -.hljs-strong { - font-weight: bold; -} - -.hljs-emphasis { - font-style: italic; -} diff --git a/doc/docstyle.css b/doc/docstyle.css deleted file mode 100644 index 1a3a88b..0000000 --- a/doc/docstyle.css +++ /dev/null @@ -1,85 +0,0 @@ -html, body { - font-size: 1em; - text-align: left; - text-decoration: none; -} -html { background-color: #e7e7e7; } - -body { - max-width: 74.92em; - margin: 0 auto; - padding: .5em 1em 1em 1em; - background-color: white; - border: .1em solid #c0c0c0; -} - -h1, h2, h3, h4 { color: #333; } -h5, h6, dt { color: #222; } - - -a h3 { - color: #005090; -} - -a[href] { color: #005090; } -a[href]:visited { color: #100070; } -a[href]:active, a[href]:hover { - color: #100070; - text-decoration: none; -} - -.linkrow { - margin: 3em 0; -} - -.linkrow { - text-align: center; -} - -div.example { padding: .8em 1.2em .4em; } -pre.example { padding: .8em 1.2em; } -div.example, pre.example { - margin: 1em 0 1em 3% ; - -webkit-border-radius: .3em; - -moz-border-radius: .3em; - border-radius: .3em; - border: 1px solid #d4cbb6; - background-color: #f2efe4; -} -div.example > pre.example { - padding: 0 0 .4em; - margin: 0; - border: none; -} - -pre.smallexample { - margin: 1em 0 1em 3% ; - -webkit-border-radius: .3em; - -moz-border-radius: .3em; - border-radius: .3em; - border: 1px solid #d4cbb6; - background-color: #f2efe4; -} - - -/* This makes the very long tables of contents in Gnulib and other - manuals easier to read. */ -.contents ul, .shortcontents ul { font-weight: bold; } -.contents ul ul, .shortcontents ul ul { font-weight: normal; } -.contents ul { list-style: none; } - -/* For colored navigation bars (Emacs manual): make the bar extend - across the whole width of the page and give it a decent height. */ -.header, .node { margin: 0 -1em; padding: 0 1em; } -.header p, .node p { line-height: 2em; } - -/* For navigation links */ -.node a, .header a { display: inline-block; line-height: 2em; } -.node a:hover, .header a:hover { background: #f2efe4; } - -table.cartouche { - border-collapse: collapse; - border-color: darkred; - border-style: solid; - border-width: 3px; -} diff --git a/doc/onboarding.texi b/doc/onboarding.texi deleted file mode 100644 index 367ff1e..0000000 --- a/doc/onboarding.texi +++ /dev/null @@ -1,415 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename onboarding.info -@include version.texi -@settitle Notes for taler.net admins and developers @value{VERSION} - -@c Define a new index for options. -@defcodeindex op -@c Combine everything into one index (arbitrarily chosen to be the -@c concept index). -@syncodeindex op cp -@c %**end of header - -@copying -Howtos for taler.net admins and developers (version @value{VERSION}, @value{UPDATED}), -Copyright @copyright{} 2017 INRIA - -@quotation -Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.3 or -any later version published by the Free Software Foundation; with no -Invariant Sections, with no Front-Cover Texts, and with no Back-Cover -Texts. A copy of the license is included in the section entitled -``GNU Free Documentation License''. -@end quotation -@end copying -@c If your manual is published on paper by the FSF, it should include -@c The standard FSF Front-Cover and Back-Cover Texts, as given in -@c maintain.texi. -@c -@c Titlepage -@c -@titlepage -@title Notes for taler.net admins and developers -@subtitle Version @value{VERSION} -@subtitle @value{UPDATED} -@author Marcello Stanisci (@email{marcello@@taler.net}) -@page -@vskip 0pt plus 1filll -@insertcopying -@end titlepage - -@c @summarycontents -@contents - -@ifnottex -@node Top -@top Notes for taler.net admins and developers -@insertcopying -@end ifnottex - -@menu -* Taler installation:: How to install all Taler components -* Testing components:: How to make and run tests -* Releases:: Releases patterns -* Code:: Where to find Taler code -* Bugtracking:: How to track Taler bugs -* Continuous integration:: How CI is currently performed -* Code coverage:: Where to find coverage reports -@end menu - -@node Taler installation -@chapter Taler installation - -@section Users serving Taler. - -On Gv.Taler.Net, there are four users that are set up to serve Taler -on the internet: - -@itemize -@item @code{taler-test}: serves @code{*.test.taler.net} and gets automatically built by Buildbot. -@item @code{taler-internal}: serves @code{*.int.taler.net}, and does @emph{NOT} get automatically built. -@end itemize - -The following two users are @emph{NEVER} automatically built, and -they both serve @code{*.demo.taler.net}. At any given time, only -one is active and serves the HTTP requests from the outside; the other -one can so be compiled without any downtime. If the compilation succeeds, -the inactive user can be switched to become active (see next section), -and viceversa. - -@itemize -@item @code{demo-blue} -@item @code{demo-green} -@end itemize - -@section Compile and switch color. - -If the setup is already bootstrapped, then it should only be needed -to login as 'demo-X' (with X being the inactive color); and then: -@example -$ source activate -$ taler-deployment-build -@end example - -and then switch the color by logging in as the @emph{demo} user, -and switch the color with the following command: - -@example -$ taler-deployment-switch-demo-X -@end example - -@section Full bootstrap. - -In order to bootstrap a Taler installation under a empty home -directory, do: - -@example -$ cd $HOME -$ git clone git://git.taler.net/deployment -@end example - -Then run the bootstrap script that will download all the repositories. - -@example -$ ./deployment/bootstrap-taler <env> - -# <env> will make all the services serve *.<env>.taler.net -# -# Currently at Gv.Taler.Net, only 'demo' / 'test' / 'int' have -# DNS and certs configured. -@end example - -If successful, then activate the new environment with: - -@example -source activate -@end example - -Compile and install all the components. -@example -$ taler-deployment-build -@end example - -Create the global configuration file. -@example -$ taler-deployment-config-generate -@end example - -Create (only) the folders where all the data needed by -Taler will be copied into (keys / JSONs with wire details / ..) -@example -$ taler-deployment-hier -@end example - -Create all the keys. -@example -$ taler-deployment-keyup -@end example - -Sign the @code{/wire} response for the exchange. -@example -$ taler-deployment-sign -@end example - -@cartouche -@quotation Note -If the DB schema of merchant/exchange/auditor changed, at this -point it MIGHT be necessary to reset all the tables. To this -regard, consider running one of the following commands: - -@example -# To reset the merchant DB. -$ taler-merchant-dbinit -r - -# To reset the exchange DB. -$ taler-exchange-dbinit -r - -# To reset the exchange DB. -$ taler-auditor-dbinit -r -@end example - -@end quotation -@end cartouche - -If all the steps succeeded, then it should be possible -to launch all the services. Give: - -@example -$ taler-deployment-start - -# or restart, if you want to kill old processes and -# start new ones. -$ taler-deployment-restart -@end example - -Verify that all services are up and running: -@example -$ taler-deployment-arm -I -$ tail logs/<component>-<date>.log -@end example - -@section How to upgrade the code. - -Some repositories, especially the ones from the released components, -have a @emph{stable} branch, that keeps older and more stable code. -Therefore, upon each release we must rebase those stable branches -on the master. - -The following commands do that: - -@example -$ cd $REPO - -$ git pull origin master stable -$ git checkout stable - -# option a: resolve conflicts resulting from hotfixes -$ git rebase master -$ ... - -# option b: force stable to master -$ git update-ref refs/heads/stable master - -$ git push # possibly with --force - -# continue development -$ git checkout master -@end example - -@node Testing components -@chapter Testing components - -@c CMDs -@c Traits -@c Twister setup - -This chapter is a VERY ABSTRACT description of how testing -is implemented in Taler, and in NO WAY wants to substitute -the reading of the actual source code by the user. - -In Taler, a test case is a array of @code{struct TALER_TESTING_Command}, -informally referred to as @code{CMD}, that is iteratively executed by -the testing interpreter. This latter is transparently initiated -by the testing library. - -However, the developer does not have to defined CMDs manually, -but rather call the proper constructor provided by the library. -For example, if a CMD is supposed to test feature @code{x}, -then the library would provide the @code{TALER_TESTING_cmd_x ()} -constructor for it. Obviously, each constructor has its own -particular arguments that make sense to test @code{x}, and all -constructor are thoroughly commented within the source code. - -Internally, each CMD has two methods: @code{run ()} and @code{cleanup ()}. -The former contains the main logic to test feature @code{x}, -whereas the latter cleans the memory up after execution. - -In a test life, each CMD needs some internal state, made by -values it keeps in memory. Often, the test has to @emph{share} -those values with other CMDs: for example, CMD1 may create some -key material and CMD2 needs this key material to encrypt data. - -The offering of internal values from CMD1 to CMD2 is made -by @emph{traits}. A trait is a @code{struct TALER_TESTING_Trait}, -and each CMD contains a array of traits, that it offers -via the public trait interface to other commands. The -definition and filling of such array happens transparently -to the test developer. - -For example, the following example shows how CMD2 takes -an amount object offered by CMD1 via the trait interface. - -Note: the main interpreter and the most part of CMDs and traits -are hosted inside the exchange codebase, but nothing prevents -the developer from implementing new CMDs and traits within -other codebases. - -@example -/* Withouth loss of generality, let's consider the - * following logic to exist inside the run() method of CMD1 */ -.. - -struct TALER_Amount *a; -/** - * the second argument (0) points to the first amount object offered, - * in case multiple are available. - */ -if (GNUNET_OK != TALER_TESTING_get_trait_amount_obj (cmd2, 0, &a)) - return GNUNET_SYSERR; -... - -use(a); /* 'a' points straight into the internal state of CMD2 */ -@end example - -In the Taler realm, there is also the possibility to alter the -behaviour of supposedly well-behaved components. This is needed -when, for example, we want the exchange to return some corrupted -signature in order to check if the merchant backend detects it. - -This alteration is accomplished by another service called @emph{twister}. -The twister acts as a proxy between service A and B, and can be -programmed to tamper with the data exchanged by A and B. - -Please refer to the Twister codebase (under the @code{test} directory) -in order to see how to configure it. - -@node Releases -@chapter Releases - -@section Release Process and Checklists - -This document describes the process for releasing a new version of the various -Taler components to the official GNU mirrors. - -The following components are published on the GNU mirrors - -@itemize -@item taler-exchange (exchange.git) -@item taler-merchant (merchant.git) -@item talerdonations (donations.git) -@item talerblog (blog.git) -@item taler-bank (bank.git) -@item taler-wallet-webex (wallet-webex.git) -@end itemize - -@section Tagging - -Tag releases with an @b{annotated} commit, like - -@example -git tag -a v0.1.0 -m "Official release v0.1.0" -git push origin v0.1.0 -@end example - -@section Database for tests - -For tests in the exchange and merchant to run, make sure that -a database @emph{talercheck} is accessible by @emph{$USER}. Otherwise tests -involving the database logic are skipped. - -@section Exchange, merchant - -Set the version in @code{configure.ac}. The commit being tagged -should be the change of the version. - -For the exchange test cases to pass, @code{make install} must be run first. -Without it, test cases will fail because plugins can't be located. - -@example -./bootstrap -./configure # add required options for your system -make dist -tar -xf taler-$COMPONENT-$VERSION.tar.gz -cd taler-$COMPONENT-$VERSION -make install check -@end example - -@section Wallet WebExtension - -The version of the wallet is in @emph{manifest.json}. The @code{version_name} should be -adjusted, and @emph{version} should be increased independently on every upload to -the WebStore. - -@example -./configure -make dist -@end example - -@c FIXME: selenium test cases - -@section Upload to GNU mirrors - -See @emph{https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads} - -Directive file: - -@example -version: 1.2 -directory: taler -filename: taler-exchange-0.1.0.tar.gz -@end example - -Upload the files in @b{binary mode} to the ftp servers. - -@node Code -@chapter Code -Taler code is versioned via Git. For those users without write access, -all the codebases are found at the following URL: - -@example -git://git.taler.net/<repository> -@end example - -A complete list of all the existing repositories is currently found at -@code{https://git.taler.net/}. Note: @code{<repository>} must NOT have -the @code{.git} extension. - -@node Bugtracking -@chapter Bugtracking -Bug tracking is done with Mantis (https://www.mantisbt.org/). All the -bugs are then showed and managed at @code{https://bugs.gnunet.org/}, under -the "Taler" project. A registration on the Web site is needed in order to -use the bug tracker. - -@node Continuous integration -@chapter Continuous integration -CI is done with Buildbot (https://buildbot.net/), and builds are triggered -by the means of Git hooks. The results are published at @code{https://buildbot.wild.gv.taler.net/}. - -In order to avoid downtimes, CI uses a "blue/green" deployment technique. -In detail, there are two users building code on the system, the "green" and -the "blue" user; and at any given time, one is running Taler services and -the other one is either building the code or waiting for that. - -There is also the possibility to trigger builds manually, but this is only -reserved to "admin" users. - -@node Code coverage -@chapter Code coverage -Code coverage is done with the Gcov / Lcov (http://ltp.sourceforge.net/coverage/lcov.php) -combo, and it is run *nightly* (once a day) by a Buildbot worker. The -coverage results are then published at @code{https://lcov.taler.net/}. - -@bye diff --git a/doc/version.texi b/doc/version.texi deleted file mode 100644 index 1bd19c2..0000000 --- a/doc/version.texi +++ /dev/null @@ -1,4 +0,0 @@ -@set UPDATED 31 May 2017 -@set UPDATED-MONTH May 2017 -@set EDITION 0.2.0 -@set VERSION 0.2.0 diff --git a/taler-docbuild/update_doc_bank.sh b/taler-docbuild/update_doc_bank.sh index 5698a13..030736b 100755 --- a/taler-docbuild/update_doc_bank.sh +++ b/taler-docbuild/update_doc_bank.sh @@ -12,9 +12,6 @@ fetch () { cd $HOME/bank fetch -./bootstrap -./configure --enable-only-doc -make pdf make html mkdir -p $HOME/build/bank/manual/pdf mkdir -p $HOME/build/bank/manual/html |