manual: Auto reformat
This commit is contained in:
		
							parent
							
								
									3b27113a7c
								
							
						
					
					
						commit
						ceb27efde0
					
				@ -189,7 +189,8 @@ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
 | 
			
		||||
     </listitem>
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
       The <link xlink:href="https://github.com/Mic92/nix-review">nix-review</link>
 | 
			
		||||
       The
 | 
			
		||||
       <link xlink:href="https://github.com/Mic92/nix-review">nix-review</link>
 | 
			
		||||
       tool can be used to review a pull request content in a single command.
 | 
			
		||||
       <varname>PRNUMBER</varname> should be replaced by the number at the end
 | 
			
		||||
       of the pull request title. You can also provide the full github pull
 | 
			
		||||
 | 
			
		||||
@ -2633,21 +2633,20 @@ addEnvHooks "$hostOffset" myBashFunction
 | 
			
		||||
       happens. It prevents nix from cleaning up the build environment
 | 
			
		||||
       immediately and allows the user to attach to a build environment using
 | 
			
		||||
       the <command>cntr</command> command. Upon build error it will print
 | 
			
		||||
       instructions on how to use <command>cntr</command>, which can be used
 | 
			
		||||
       to enter the environment for debugging. Installing cntr and
 | 
			
		||||
       running the command will provide shell access to the build sandbox of
 | 
			
		||||
       failed build. At <filename>/var/lib/cntr</filename> the sandboxed
 | 
			
		||||
       filesystem is mounted. All commands and files of the system are still
 | 
			
		||||
       accessible within the shell. To execute commands from the sandbox use
 | 
			
		||||
       the cntr exec subcommand. Note that <command>cntr</command> also needs
 | 
			
		||||
       to be executed on the machine that is doing the build, which might not
 | 
			
		||||
       be the case when remote builders are enabled. <command>cntr</command> is
 | 
			
		||||
       only supported on Linux-based platforms. To use it first add
 | 
			
		||||
       <literal>cntr</literal> to your
 | 
			
		||||
       <literal>environment.systemPackages</literal> on NixOS or alternatively
 | 
			
		||||
       to the root user on non-NixOS systems. Then in the package that is
 | 
			
		||||
       supposed to be inspected, add <literal>breakpointHook</literal> to
 | 
			
		||||
       <literal>nativeBuildInputs</literal>.
 | 
			
		||||
       instructions on how to use <command>cntr</command>, which can be used to
 | 
			
		||||
       enter the environment for debugging. Installing cntr and running the
 | 
			
		||||
       command will provide shell access to the build sandbox of failed build.
 | 
			
		||||
       At <filename>/var/lib/cntr</filename> the sandboxed filesystem is
 | 
			
		||||
       mounted. All commands and files of the system are still accessible
 | 
			
		||||
       within the shell. To execute commands from the sandbox use the cntr exec
 | 
			
		||||
       subcommand. Note that <command>cntr</command> also needs to be executed
 | 
			
		||||
       on the machine that is doing the build, which might not be the case when
 | 
			
		||||
       remote builders are enabled. <command>cntr</command> is only supported
 | 
			
		||||
       on Linux-based platforms. To use it first add <literal>cntr</literal> to
 | 
			
		||||
       your <literal>environment.systemPackages</literal> on NixOS or
 | 
			
		||||
       alternatively to the root user on non-NixOS systems. Then in the package
 | 
			
		||||
       that is supposed to be inspected, add <literal>breakpointHook</literal>
 | 
			
		||||
       to <literal>nativeBuildInputs</literal>.
 | 
			
		||||
<programlisting>
 | 
			
		||||
         nativeBuildInputs = [ breakpointHook ];
 | 
			
		||||
       </programlisting>
 | 
			
		||||
 | 
			
		||||
@ -354,23 +354,22 @@ Additional information.
 | 
			
		||||
   <title>Tested compilation of all pkgs that depend on this change using <command>nix-review</command></title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    If you are updating a package's version, you can use nix-review to make sure all
 | 
			
		||||
    packages that depend on the updated package still compile correctly.
 | 
			
		||||
    The <command>nix-review</command> utility can look for and build all dependencies
 | 
			
		||||
    either based on uncommited changes with the <literal>wip</literal> option or
 | 
			
		||||
    specifying a github pull request number.
 | 
			
		||||
    If you are updating a package's version, you can use nix-review to make
 | 
			
		||||
    sure all packages that depend on the updated package still compile
 | 
			
		||||
    correctly. The <command>nix-review</command> utility can look for and build
 | 
			
		||||
    all dependencies either based on uncommited changes with the
 | 
			
		||||
    <literal>wip</literal> option or specifying a github pull request number.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
     review changes from pull request number 12345:
 | 
			
		||||
     <screen>nix-shell -p nix-review --run "nix-review pr 12345"</screen>
 | 
			
		||||
    review changes from pull request number 12345:
 | 
			
		||||
<screen>nix-shell -p nix-review --run "nix-review pr 12345"</screen>
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
     review uncommitted changes:
 | 
			
		||||
     <screen>nix-shell -p nix-review --run "nix-review wip"</screen>
 | 
			
		||||
    review uncommitted changes:
 | 
			
		||||
<screen>nix-shell -p nix-review --run "nix-review wip"</screen>
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
  </section>
 | 
			
		||||
 | 
			
		||||
  <section xml:id="submitting-changes-tested-execution">
 | 
			
		||||
 | 
			
		||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user