git tag -f stable-lisa (1)
We touched on the concept of a stable point in time in our Git docs. Now, we’ll show how we use git tagging to mark and move a workspace’s stable point in time.
We consider a workspace stable when the whole workspace is in a valid state. For example, when all code compiles, all tests pass, and the check command executes without error.
The test command leverages the concept of stability to support running tests incrementally. It can reduce a test run to only those tests affected by changes since the last known stable point in time. As you can imagine, skipping unnecessary tests can significantly reduce test run times!
To mark a stable point in time, we use a git tag.
Let’s continue with our tutorial. We last left off by adding and committing your workspace files to git.
Mark your example
workspace as stable by tagging it with git:
git tag -f stable-lisa (1)
1 | -f tells git to move the tag if it already exists |
Run git log --pretty=format'%h %d%n %s'
, you’ll see something like:
e7ebe68 (HEAD -> main, tag: stable-lisa) (1)
Created the user and cli bricks.
c91fdad
Workspace created.
1 | Notice the stable-lisa tag you added is on the second commit. |
We used git log --pretty=format'%h %d%n %s for compact documentation-friendly output.
Feel free to use git log --pretty=oneline or even git log .
|
Rerun the poly info
command, and you’ll see something like this:
Notice that:
The stable since
line shows:
A short-SHA e7ebe68
that matches the second commit.
The stable-lisa
tag.
All the *
(asterisk) markers you saw in the previous info output are gone because no brick (component or base) or project has changed since our new stable point in time.
Run poly diff
; you’ll see no output because nothing has changed.
Our example uses the git tag stable-lisa
, but poly
recognizes any tag that starts with stable-
as a stable point in time.
We chose stable-lisa
because Lisa is our name (let’s pretend, at least!).
This convention allows every developer to have their own unique stable point in time.
Your continuous integration (CI) build should use its own unique git tag pattern to mark successful builds (and, therefore, stable workspaces).
A convention like stable-
plus branch name or stable-
plus build number can work nicely.
We recommend that you start with stable-
tags created by your CI server and add developer-specific stable-
tags when needed.
We think that git tags that start with stable-
is a magnificent naming convention, but if you really prefer something different, you can override this default in your workspace.edn
file:
:tag-patterns {:stable "stable-*" (1)
:release "v[0-9]*"}
1 | Override the default stable-* regular expression to your own convention, if you wish |
You’ve seen the info
command output when all bricks and projects have changed since the stable point in time; all bricks and projects showed a trailing *
(asterisk).
What happens if only some bricks have changed?
Let’s find out.
Add a comment to the user.core
namespace by editing ./components/user/src/se/example/user/core.clj
:
(ns se.example.user.core)
; hi! (1)
(defn hello [name]
(str "Hello " name "!"))
1 | Add a comment line |
Run poly info
again:
As expected, the user
component now shows a trailing *
.
Notice that both command-line
and development
projects show a trailing +
.
The +
indicates the projects have no changes, but at least one of their bricks has changed.
When you release, we recommend your CI server git tag the release. But here, we’ll have you experiment from your command line shell.
Run git log --pretty=format'%h %d%n %s
to look at your current commit history and tags:
e7ebe68 (HEAD -> master, tag: stable-lisa)
Created the user and cli bricks.
c91fdad
Workspace created.
Tag the first commit as v1.1.0
and the second as v1.2.0
:
git tag v1.1.0 c91fdad (1)
git tag v1.2.0
1 | replace c91fdad with your corresponding SHA for your first commit |
Rerun git log --pretty=format'%h %d%n %s
to verify your new tags:
e7ebe68 (HEAD -> master, tag: v1.2.0, tag: stable-lisa)
Created the user and cli bricks.
c91fdad (tag: v1.1.0)
Workspace created.
Now run poly info
against your latest release:
poly info since:release
If you execute poly info
against the previous release:
poly info since:previous-release
The poly
tool has picked up the second latest release tag.
The poly
tool matches release tags as defined by your workspace.edn
:
:tag-patterns {:stable "stable-*"
:release "v[0-9]*"} (1)
1 | Default regular expression for git :release tags is v[0-9]* . |
You can use the since
argument on your CI server to run only the necessary tests since the previous release.
Unaffected code does not need to be retested.
poly test since:previous-release
You’ll use:
|
If the since argument is not specified, since:stable is used by default.Other variants, like since:e7ebe68v , since:head , and since:head~1 are also valid.
|
See Continuous Integration for tagging and release strategies.
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close