![]() Setting a type of 'readonly' gives the client its own personal 'db.have' database table. Over time these build clients can fragment the 'db.have' table which is used to track what files a client has synced. Type of client: writeable/readonly/partitioned/graphīy default all clients are 'writeable', certain clients are short lived and perform long sync and build cycles. Tag and commit messages which span multiple lines are no problem, though only the first 10000 lines of a tag's message will be exported. builds are only triggered when certain tag names or patterns are matched - in which case the exact tag name that triggered the build will be used, even if it's not the most recent tag for this commit.įor this reason, if you're not using a tag-specific refspec but you are using the "Create a tag for every build" behaviour, you should make sure that the build-tagging behaviour is configured to run after this "export git tag message" behaviour. If the revision has more than one tag associated with it, only the most recent tag will be taken into account, unless the refspec contains "refs/tags/" - i.e. If you ticked the Use most recent tag option, and the revision checked out has no git tag associated with it, the parent commits will be searched for a git tag, and the rules stated above will apply to the first parent commit with a git tag. If no tag message was specified, the commit message will be used. If a message was specified when creating the tag, then that message will be exported during the build as the GIT_TAG_MESSAGE environment variable. If the revision checked out has a git tag associated with it, the tag name will be exported during the build as GIT_TAG_NAME. does not match: origin/master or origin/develop.matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123.does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc.matches: origin or origin/master or origin/feature.Regular expression syntax in branches to build will only build those branches whose names match the regular expression. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo. In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard, and '**' is recognized as wildcard that includes the separator '/'. The syntax is of the form: REPOSITORYNAME/BRANCH. In this case the variables are evaluated and the result is used as described above.Į.g. ![]() It is also possible to use environment variables. This does not work since the tag will not be recognized as tag.Į.g. If ambiguous the first result is taken, which is not necessarily the expected one. refs/heads/master, refs/heads/feature1/master. release/), you'll need to specify the origin repository in the branch names to make sure changes are picked up. If you use a wildcard branch specifier, with a slash (e.g. When not presented with a full path the plugin will only use the part of the string right of the last slash. If your branch name has a / in it make sure to use the full reference above. This way the expected branch is unambiguous. The safest way is to use the refs/heads/ syntax. If left blank, all branches will be examined for changes and built. ![]() Specify the branches if you'd like to track a specific branch in a repository. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |