4 Please try and stick to the GNU coding standards. A lot of hard work
5 went into making Check compatible with the standards, and would be
6 nice if that work didn't erode. I decided on the standards because
7 they work well for a lot of programs much bigger than Check. Ok,
8 since you're wondering, the advantages of sticking to the standards
11 1) consistent style within the project
13 2) being familiar with the standards lets you work on lots of
14 different GNU standards-compliant projects pretty easily
16 3) it reduces the number of decisions that must be made
21 To create a release one will need to be a member of the libcheck organization
22 on GitHub. If you are not a member, a current member can add you
24 https://github.com/orgs/libcheck/people
25 and submitting an invite.
27 1) To create a release, start in a configured in-place
28 checkout of the Check project:
30 $ git clone https://github.com/libcheck/check.git
33 2) Determine the version of Check to release, and update
34 the configure.ac script:
36 AC_INIT([Check], [0.10.1], [check-devel at lists dot sourceforge dot net])
38 CHECK_MINOR_VERSION=10
41 (Remember to update both the AC_INIT line and each of the CHECK_*_VERSION fields).
43 3) Update the header in the NEWS file to mention the release:
45 Sun Aug 2, 2015: Released Check 0.10.1
46 2015-08-02 19:21:14 +0000
47 based on hash f399542eeceb97703bca496b68bb39044e8baa01
49 4) Update index.html mentioning the release. Look for the following:
50 <!-- Update this section during a release -->
52 5) Attempt to build the release locally
58 If this passes, a tarball with the current release number will be in the current
59 directory. Make not of this, as it will be uploaded to GitHub later.
61 6) Commit the changes to configure.ac, NEWS, and index.html to the Check project's
62 master branch, with the commit message:
65 7) Log On to GitHub and navigate to:
67 https://github.com/libcheck/check/releases
69 Click "Draft a New Release".
71 Enter the release version to the Tag Version box, and enter the
72 git hash into the Target selector.
74 Fill in the Release Title field.
76 Describe the release with something similar to the following:
78 <some sentence about the release, e.g. "This is a bug fix release.">
79 Please test it out and report any problems you might have.
82 <paste contents of NEWS here for the release>
85 Attach the tarball for the release, then publish the release.
87 8) Use the following template to announce the release via email:
89 Subject: check-X.Y.Z released
92 <some sentence about the release, e.g. "This is a bug fix release.">
93 Please test it out and report any problems you might have.
95 https://github.com/libcheck/check/releases
100 <paste contents of NEWS for the release here>
103 9) Update the development header in the NEWS file and commit the result.
105 10) Push updated website (see section below)
107 Congratulations, you are done!
113 The Check website is automatically hosted from the contents of
114 the gh-pages branch in the Check git repository. To update
115 the website, merge the contents of the master branch into
118 To update the generated documentation for the website:
121 github https://github.com/libcheck/check.git (fetch)
122 github https://github.com/libcheck/check.git (push)
124 $ git checkout github/gh-pages -b gh-pages
125 Branch gh-pages set up to track remote branch gh-pages from github.
126 Switched to a new branch 'gh-pages'
127 $ git merge github/master
128 First, rewinding head to replay your work on top of it...
129 Fast-forwarded gh-pages to github/master.
134 $ make doc/check_html
137 $ git commit -m “Update documentation”
138 $ git push github gh-pages:gh-pages
141 Automatic building of pull requests
144 The GitHub project is configured to build pull requests either when
145 asked or automatically. This is done using the GitHub Pull Request
146 Builder Plugin. Documentation here:
148 https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
150 When a new pull request is opened in the project and the author of the pull request
151 isn't white-listed, builder will ask "Can one of the admins verify this patch?".
153 An admin can add one of the following comments to the pull request:
154 "ok to test" to accept this pull request for testing
155 "test this please" for a one time test run
156 "add to whitelist" to add the author to the whitelist
158 If the build fails for other various reasons you can rebuild.
160 "retest this please" to start a new build
162 When a build is triggered a job on the Jenkins instance will start:
164 https://check.ci.cloudbees.com/job/github-merge-builder/
166 When complete, a comment will be added to the pull request, informing
169 An admin can be added to the Jenkins instance by adding a username
170 to the "Admin list" setting under the "GitHub Pull Request Builder"
173 https://check.ci.cloudbees.com/configure
175 This works because there is a user in the libcheck organization,
176 "check-builder", which the Jenkins instance uses to install a
177 git hook and push comments to pull requests.
183 The gcov tool can be used to determine the unit test coverage in Check
184 itself. This is currently supported on GNU/Linux only. To enable the
185 necessary build time flags, add the following argument to the
190 Once the unit tests have been run with
194 assuming the terminal is in the top src directory, the following will
195 generate summary information using gcov:
197 $ cp src/*.c src/.libs/
199 $ for file in `ls *.c`; do
200 gcov -f $file > $file.gcov.summary.txt
201 mv $file.gcov $file.gcov.txt
204 The *.gcov.txt files will contain the source code annotated with
205 the number of times each line was executed. The .*gcov.summary.txt
206 files will contain a line execution summary per function.
208 To determine the line execution summary for all of Check, either
209 the gcovr tool can be used, or the following quick-and-dirty script:
211 $ for file in ls *.summary.txt; do cat $file; done \
212 | grep "Lines executed" | cut -d ":" -f 2 | tr -d "%" \
213 | awk '{checked+=$1*$3/100; total+=$3} END {print checked/total*100}'