checkcommand executes without errors. This is then used by the test command to run the tests incrementally, by only executing the affected tests, which substantially speeds up the tests.
stable point in timeis to tag it with git (-f tells git to reuse the tag if already exists):
git log --pretty=onelineagain:
stable-lisa. Note that your hash tags will be different and when we refer to e.g.
c91fdadin the following examples, you should instead give your own corresponding hash code.
stable sincehash has been updated and is now tagged with
stable-lisa. All the
*signs are gone because no
projecthas yet changed since the second commit (which can be verified by running
stable-lisabut we could have named the tag with anything that starts with
stable-. We choose
stable-lisabecause Lisa is our name (let's pretend that at least!). The idea is that every developer could use their own unique tag name that doesn't conflict with other developers.
stable-plus branch name or build number, to mark successful builds. It may be enough to only use the stable points that the CI server creates. That is at least a good way to start out and only add custom tags per developer when needed.
workspace.ednand can be changed if we prefer something else:
stable-*) or if no match was found, the first commit in the repository.
deps.ednfile, it got a trailing
*to indicate that it was changed. But what happens if only some of its bricks have changed? Let's try that by adding a comment to the
+which indicates that the projects themselves are unchanged but that at least one of their bricks has changed.
v1.1.0and the second as
v1.2.0(make sure you replace
c91fdadwith your corresponding sha):
git log --pretty=onelinewe can verify that the tags are correctly set:
sinceparameter is used by the CI server to run all tests since the previous release, e.g.:
sinceis not given,
stablewill be used by default.
since:head~1are also valid.