view release on metacpan or  search on metacpan

doc/incoming.html  view on Meta::CPAN

Once the job has been validated it is copied to the directory
where <em>accepted</em> jobs are stored. Throughout the copying
process the new <code>PkgForge::Job</code> object for the recently
validated job is kept in memory. Once the copying is complete this
object is used to, once more, check the SHA1 sums of the copied source
files to ensure that no tampering or corruption has occurred. This
object is also used to write-out a new job metadata file into the
accepted job directory.
</p>

<p>
The intention is that, for security, only the user which the incoming
queue processor runs as is permitted to write into the accepted job
directory. If a standard, local unix filesystem is being and anything
else is run as the same user then this probably does not give much
extra confidence. However, if something like AFS is being used then
there can be a high-level of trust in the data integrity of the
accepted job directory if the write/insert access is highly
restricted.
</p>

<p>
If, for any reason, the transfer fails, then the processing of this
job will be considered to have failed. It will then be marked in the
registry database as being in the <em>failed</em> state and it will be
moved immediately to the Clean-Up stage.
</p>

<h3><a name="stage5">Stage 5: Registration</a></h3>

<p>
Once a job has been validated and accepted then <em>tasks</em> can be
registered for each platform. Terminology is used here to avoid
confusion, a <em>task</em> is purely a <em>job</em> which has been
registered for a specific platform/architecture. It should be noted
that a job can be considered completely valid but not result in the
registration of any tasks. In that case nothing will actually be done
with the submitted job and its source packages.
</p>

<p>
As part of the processing instructions specified by the user, each
submitted job has a list of applicable platforms and a list of
applicable architectures. Typically, these might actually be just the
special &quot;<em>all</em>&quot; string in both cases, as expected,
this signifies that tasks should be registered for all platforms
and/or architectures. There is plenty of scope for a user to be able
to specify and restrict the sets of platforms and architectures for
which tasks should be registered, this is fully described in
the <a href="/doc/job.html">job documentation</a>. The sets of target
platforms and architectures are computed by examining the list of
available, active, platforms in the registry database and applying the
filters specified by the user for the new job.
</p>

<p>
Note that having a task registered for an active platform does not
guarantee that a build daemon is currently available for that
platform. It is perfectly acceptable to queue tasks for a platform
which currently has no build daemons registered. It may also, of
course, be the case that a build daemon is busy or currently
unavailable due to maintenance. It is also worth noting that a
platform may have multiple build daemons. It is not possible to
guarantee which build daemon will accept a particular task, as they
should all have identical build environments this should not cause
problems. Full details of the task scheduling is available in
the <a href="/doc/server/builder.html">build daemon</a>
documentation.
</p>

<p>
Once tasks have been successfully registered the new job will be
marked in the registry database as being in the <em>registered</em>
state.  If, for any reason, the task registration fails, then the
processing of this job will be considered to have failed. It will then
be marked in the registry database as being in the <em>failed</em>
state and it will be moved immediately to the Clean-Up stage.
</p>

<h3><a name="stage6">Stage 6: Clean-Up</a></h3>

<p>
The final stage, no matter which final state a submitted job has
achieved, is the clean-up of the incoming queue directory. The
directory for the submitted job and all of the contents will be
removed.
</p>


</body>
</html>