Create Git revision job

Deprecated, and marked as such in the palette. It belongs to the older job model, the one where a job was assembled from Git revisions named one by one rather than from changesets. Nothing in the current product builds jobs that way. Keep it out of new rules.

It is documented here because old rules still carry it, and because the way it fails is not obvious from looking at it in the rule designer.

No configuration

The op has no form. Open it in the rule designer and there is nothing to fill in. The op-level settings still apply: Name, Enabled, Run Forward, Run Rollback, Error Handling and Return Key behave as they do on any op.

That is the trap. The op needs an environment and a list of revisions before it can do anything, and there is no field for either. Dragged out of the palette and left as it comes, it stops the rule with a missing-environment error the first time it is reached. The rules that use it successfully had those values written onto the op by hand, through the metadata editor on the op rather than through a form.

Values the op reads

Value	What it does
bl	the environment the job runs in. Required; without it the op stops immediately
revision	one revision name, or a list of them. Required. Each one is resolved and added to the job
job_type	the kind of job. Defaults to a static job when not given
username	who the job belongs to. When blank, the account the Clarive server process runs under is used, which is normally not a real Clarive user
runner	the chain the job runs. Defaults to the simple job chain
comments	free text carried onto the new job

Revisions are handled one at a time, and each name is logged as being added to the job before the system tries to find it. That log line is not a confirmation. A name that cannot be found is logged in exactly the same way, and only then does the op stop with an error naming that revision. So when a run fails, the last revision in the log is the one that did not resolve, not the last one that worked. A list with one bad entry creates no job at all, even though the entries ahead of it resolved.

What happens on success

A job is created in the requested environment with the resolved revisions as its contents, and the log records the new job's name and type.

The rule does not wait for that job. It is left for the job scheduler to pick up and run on its own, so nothing about its outcome comes back into the rule that created it. The op also does not hand back the new job's identifier, so a Return Key on it gives you nothing to chain on. To act on the job you have to find it by name afterwards.

Run Rollback is on for every new op, so this one creates a second job during a rollback pass unless you untick it. That is almost never wanted.

What to use instead

Jobs today are built from changesets and started from the release and deployment flows described in deployment, which pick up repository content without naming revisions. The ops under job run inside a job that already exists rather than creating one.

Combining with other ops

The op belongs with the rest of the older revision model, in particular Checkout a git revision and Fill job elements, which are the ops that consume the revision list this one puts on a job.

If you are maintaining a rule that still contains it, put LOG in front of it to record the values the op is about to use, since the op itself logs nothing until it starts resolving revisions. TRY with CATCH around it keeps a missing revision from stopping the whole rule while you work out what changed.

Example

There is nothing to fill in on the form. An old rule carries values like these on the op itself:

bl         PROD
revision   release-${version}@myapp:bar
job_type   static
comments   created from rule ${rule_name}