This project is read-only.

Introduction

RepoCop uses an XML configuration file. The structure is really simple. You define a set of instructions that are to be executed whenever someone performs a check-in to the repository. There are different instruction tags depending on the kind of task you want to execute. Usually a task should only be executed if some special conditions are met. These conditions can be defined within the instruction tag. Each command allows one condition but there exists also a composite condition which can be used to combine several conditions. By nesting conditions using this composite condition it's possible to define rather large, complicated checks. But normally only very simple conditions will be required.

Instructions

Following is a list of the available instruction tags including a short description what they do. Follow the links to get detailed information about each instruction.

Replacements

With almost every parameter of instructions you can use replacement tokens that provide access to context information. In particular RepoCop supports
  • #author# will be replaced with the author (the name of the user) of a commit
  • #logmessage# will be replaced with the compled, unmodified log message as provided by the user
  • #revision#" will be replaced with the revision of this commit. Only available with post-commit hooks because obviously, a pre-commit has not yes a final revision number.
  • #prevrevision#, #nextrevision#" Some tools require that you specify not only a single revision but instead a revision range (e.g. ReviewBoard). So to reference commit #15 you need to state something like 14:15. For this purpose you can use the tokens #prevrevision# and #nextrevision# which will be replaced by the current revision number minus one or plus one, respectivley.
  • #time# will be replaced by the timestamp of the commit (date and time)
  • #affectedfiles# will be replaced with all files affected by the commit, each file in a separate line (Environment.NewLine is used as separator)
  • #affectedpaths# will be replaced with all paths (thus, files and directories) affected by the commit, each path in a separate line (Environment.NewLine is used as separator)
You have the possibility to configure additional replacement tokens using the <ReplacementToken> tag.

Conditions

Conditions are applied on commands if they should not always be executed but rather if certain requirements are met. These requirements can be stated by applying conditions on instructions. Each condition is either true or false. The state of the condition is calculated using the current commit context (e.g. who is committing, what files wre changed, what hook is currently executed (pre-commit, post-commit, etc), etc.).

It's also possible to define negative conditions. For instance, the <AuthorCondition> tag let's you define one or several users. If one of these users is commiting, this condition is true, otherwise false. So let's say you want to exclude users. You could do this using a FailInstruction combined with AuthorCondition which defines the users who are not allowed to commit, like so
    <!-- Check for valid users -->
    <FailInstruction Message="You are not allowed to commit.">
      <AuthorCondition>Rooky1</AuthorCondition>
    </FailInstruction>

Now let's say you have a feature branch and only the members of the team currently working on this feature should be allowed to commit. It would be very inconvenient having to state all the excluded users, right? This is why each condition also offers the Negate-attribute which negates the outcome of the condition, like so
    <!-- Check for valid users -->
    <FailInstruction Message="Only members of the feature team are allowed to commit.">
      <Conditions Type="And">
        <AuthorCondition Negate="True">TeamMember1,TeamMember2</AuthorCondition>
        <ChangedPathCondition ChangedPathRegExPattern="/branches/superfeature.*" />
      </Conditions>
    </FailInstruction>

Following is a list of the available condition tags including a short description what they do. Follow the links to get detailed information about each condition.
  • <Conditions>Combines several conditions requiring either any of the nested conditions to apply (or logic) or all ot the nested conditions (and logic)
  • <HookTypeCondition> Checks the type of hook that is currently executed (e.g. before-commit, post-commit)
  • <AuthorCondition> Checks whether a commit is done by a specified author
  • <ChangedPathCondition> Checks whether the commit involved certain paths matching a specified regular expression
  • <LogMessageCondition> Checks whether the commit message matches a specified regular expression

Examples

There is an Examples page that show some useful examples on how to use the RepoCop configuration.

Last edited Jan 12, 2014 at 3:15 PM by markushastreiter, version 9

Comments

No comments yet.