Fill job elements
Works out which files differ between the Git revisions recorded on the job and the environment being deployed to, and writes that list into the job log with a change letter against each path.
This is an older op that predates the changeset model. In a current pipeline the op that builds the job's file list is Load Job Items into Stash, which handles every repository type, resolves environment markers and leaves its result in the stash for the rest of the rule to use. Reach for that one first. This op is here for pipelines built around the older job contents mechanism.
Configuration¶
This op has no form. Its Config tab is an empty YAML editor, and nothing you type there is read.
What it looks at¶
The op reads the job's recorded contents and keeps only the entries that name a Git revision. Every entry is dumped into the job log at debug level on the way past, including the ones it then skips, so a job with a long contents list produces a long trail of debug entries and no info-level output at all when none of them is a Git revision. That case still reports success.
Those contents come from the job state as it was saved at the end of the previous job step, not from the live stash. Setting a value in the same step this op runs in does not reach it.
The repository has to be readable on the Clarive server itself, because the comparison is done against the repository on disk rather than through a checkout.
How the comparison runs¶
For each Git revision entry, the op resolves two commits: the one the revision points at, and the one the environment name points at. Then it picks a direction.
| Case | What is listed |
|---|---|
| promote, and the two commits differ | the files that changed between the environment and the revision |
| promote, and the two commits are identical | every file in the tree, each marked as modified |
| demote, or any rollback pass | the files between the environment and the commit before the revision |
Watch the second row. When there is nothing to deploy, the op does not report an empty list. It reports the whole repository as modified, which downstream looks like a full redeploy rather than a no-op.
One legacy special case survives: a revision named DESA is resolved against the repository's
master branch on both sides, whatever the job's environment is. Avoid that name.
What comes out¶
Each path is paired with the change letter the comparison produced, A for added, M for modified,
D for deleted. Rename and copy codes pass through as they come. The path itself is rewritten as
/<project>/<repository>/<path>, so it carries the project and repository folders and starts at a
leading slash.
The job log gets one entry per Git revision, reading *Git* Job Elements N where N is the number
of paths, with the full list attached as entry data. Open the entry from the monitor to read it. The
same list goes in a second time at debug level under Elements in tree, immediately before the
counted one.
Before any of that, the op writes every tag in the repository to the job log, one debug line per tag. On a repository with a long tag history that is the bulk of what this op puts in the log.
Those log entries are the lasting output. The element list the op builds goes into a copy of the job
state that is discarded when the step ends, so no later op and no later step can read it back. Treat
this op as reporting rather than as a loader. When you need the file list available to the rest of
the rule, use Load Job Items into Stash, which writes items and the name
lists into the stash.
Failure¶
A revision or an environment name that does not resolve in the repository stops the job, as does a repository path the server cannot read.
Git revisions are handled one at a time and each one logs its list as it finishes. A failure on the third revision leaves the first two already logged, so the job log can show a partial picture next to an error.
Combining with other ops¶
Footprint elements was built to consume what this one produces. The list does not survive the end of the step, so that op does not pick it up on its own. Read its page before you build a rule around the pair.
For anything else, the modern equivalents are Load Job Items into Stash to build the file list and Checkout Job Items to put those files on disk. To report on a file list you already have, LOG Message with a FOREACH file/item around it gives you the same job log output and lets you choose the wording.
Example¶
A reporting step in a job built on the older contents model.
JOB STEP: PRE
Fill job elements
Footprint elements