···
227
+
<title>Pull Request Template</title>
229
+
The pull request template helps determine what steps have been made for a
230
+
contribution so far, and will help guide maintainers on the status of a
231
+
change. The motivation section of the PR should include any extra details
232
+
the title does not address and link any existing issues related to the pull
235
+
<para>When a PR is created, it will be pre-populated with some checkboxes detailed below:
238
+
<title>Tested using sandboxing</title>
240
+
When sandbox builds are enabled, Nix will setup an isolated environment
241
+
for each build process. It is used to remove further hidden dependencies
242
+
set by the build environment to improve reproducibility. This includes
243
+
access to the network during the build outside of
244
+
<function>fetch*</function> functions and files outside the Nix store.
245
+
Depending on the operating system access to other resources are blocked
246
+
as well (ex. inter process communication is isolated on Linux); see <link
247
+
xlink:href="https://nixos.org/nix/manual/#description-45">build-use-sandbox</link>
248
+
in Nix manual for details.
251
+
Sandboxing is not enabled by default in Nix due to a small performance
252
+
hit on each build. In pull requests for <link
253
+
xlink:href="https://github.com/NixOS/nixpkgs/">nixpkgs</link> people
254
+
are asked to test builds with sandboxing enabled (see <literal>Tested
255
+
using sandboxing</literal> in the pull request template) because
257
+
xlink:href="https://nixos.org/hydra/">https://nixos.org/hydra/</link>
258
+
sandboxing is also used.
261
+
Depending if you use NixOS or other platforms you can use one of the
262
+
following methods to enable sandboxing <emphasis role="bold">before</emphasis> building the package:
266
+
<emphasis role="bold">Globally enable sandboxing on NixOS</emphasis>:
267
+
add the following to
268
+
<filename>configuration.nix</filename>
269
+
<screen>nix.useSandbox = true;</screen>
274
+
<emphasis role="bold">Globally enable sandboxing on non-NixOS platforms</emphasis>:
275
+
add the following to: <filename>/etc/nix/nix.conf</filename>
276
+
<screen>build-use-sandbox = true</screen>
284
+
<title>Built on platform(s)</title>
286
+
Many Nix packages are designed to run on multiple
287
+
platforms. As such, it's important to let the maintainer know which
288
+
platforms your changes have been tested on. It's not always practical to
289
+
test a change on all platforms, and is not required for a pull request to
290
+
be merged. Only check the systems you tested the build on in this
295
+
<title>Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)</title>
297
+
Packages with automated tests are much more likely to be merged in a
298
+
timely fashion because it doesn't require as much manual testing by the
299
+
maintainer to verify the functionality of the package. If there are
300
+
existing tests for the package, they should be run to verify your changes
301
+
do not break the tests. Tests only apply to packages with NixOS modules
302
+
defined and can only be run on Linux. For more details on writing and
303
+
running tests, see the <link
304
+
xlink:href="https://nixos.org/nixos/manual/index.html#sec-nixos-tests">section
305
+
in the NixOS manual</link>.
309
+
<title>Tested compilation of all pkgs that depend on this change using <command>nox-review</command></title>
311
+
If you are updating a package's version, you can use nox to make sure all
312
+
packages that depend on the updated package still compile correctly. This
313
+
can be done using the nox utility. The <command>nox-review</command>
314
+
utility can look for and build all dependencies either based on
315
+
uncommited changes with the <literal>wip</literal> option or specifying a
316
+
github pull request number.
319
+
review uncommitted changes:
320
+
<screen>nix-shell -p nox --run nox-review wip</screen>
323
+
review changes from pull request number 12345:
324
+
<screen>nix-shell -p nox --run nox-review pr 12345</screen>
328
+
<title>Tested execution of all binary files (usually in <filename>./result/bin/</filename>)</title>
330
+
It's important to test any executables generated by a build when you
331
+
change or create a package in nixpkgs. This can be done by looking in
332
+
<filename>./result/bin</filename> and running any files in there, or at a
333
+
minimum, the main executable for the package. For example, if you make a change
334
+
to <package>texlive</package>, you probably would only check the binaries
335
+
associated with the change you made rather than testing all of them.
339
+
<title>Meets nixpkgs contribution standards</title>
341
+
The last checkbox is fits <link
342
+
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md">CONTRIBUTING.md</link>.
343
+
The contributing document has detailed information on standards the Nix
344
+
community has for commit messages, reviews, licensing of contributions
345
+
you make to the project, etc... Everyone should read and understand the
346
+
standards the community has for contributing before submitting a pull
<title>Hotfixing pull requests</title>
pyrox.dev