error-message
success-message
saving-message
warning-message
JavaScript must be enabled.
There was an error retrieving this content.
The content could not be found.
JavaScript must be enabled.
There was an error retrieving this content.
The content could not be found.
This panel views the builds of the artifact.
Many objects can elect to have a "build" phase. This is a transforative action that takes the content of the object and produces a useful result that is considered the actual representation of the object.
For software, this is the actual build or compilation step. Source code is the data comprising the object in the archive. The build step turns the text source code into a machine usable binary that would actually be used to invoke the software. That build step can be described in the object and then deployed to produce such a binary. The log and resulting files can be explored here.
Any completed build of an object will show up here. Such a build was a deployment of the object in some form. That is, much like running an object, it had to have a proper environment created for it consisting of the object (source code, etc) and dependencies (the compiler it needs, etc). Builds might use historic components also themselves archived in the system. To ensure these are more properly repeatable, each build records exactly the software and data used in that environment.
When you select a build, it will present you with a description of that environment in what is called a task. The manifest itself is the metadata for the task which lists the dependencies. Interacting with that list allows you to view the dependencies from the point of view of the version used in the build.
Other metadata is listed as well. The identifier for the build is simply the identifier of the task (which is itself an object in the archive.) The hash of all the resulting files and logs to uniquely and verifiably identify the build anywhere. The time elapsed to produce the build at the time it was built, which is itself listed as the date.
You can see all historic builds in the queue side-panel. Each will be listed by their date of deployment.
You can invoke a new build by going to the "New" tab or by selecting "Queue" in the queue side-panel. This gives you a listing very similar to that in the "Run" panel, which lists the possible environment needed to perform the build and allow you to override which artifacts and software are used to do so.
This is the file listing that shows the files within directories of this current object.
When you are editing your own objects, you can perform some actions to update the files. We will discuss these actions now.
You can upload files by either dragging them into the file listing from your local machine or by using the buttons near the listing.
You can create a new file by using one of the buttons near the listing. This will allow you to give the file a name which you can then click on to open the blank file to edit it further.
You can add a new directory to organize your files by using another button near the listing. Once you press the button, you can name the directory and then click on it to traverse to this empty directory.
Note that you cannot have a directory or file with the same name in the same directory. This includes not being able to have a directory and file with the same name.
Clicking on a file in the listing will open the file. If you are editing the object, then it may open an editor for that file. Otherwise you will receive a read-only view of the file. The viewer or editor will depend on your associations for the type of file. Most text files, for instance, will open in a text editor.
The actions button to the right of each file in the listing will select further actions to be done on each file. These actions will be discussed now.
The remove action will delete the file from the current view of the object when you have such permissions.
The download action will download a copy of the file to your local machine.
The set as main action will set the given file as the main file for
the object. For many objects, this has special significance. It will
essentially set the file
field of the object to the path to this file.
You can refer to it in a run or build command to make the object more
flexible and extensible instead of hard-coding such paths. Other
objects might expect a file
to be chosen when they take an object as
input in a workflow. In these cases, the main file highlights which
file is most important. Occam especially handles HTML documents and
widgets by loading the main file as the entry point to the interactive
program or document.
QmeHavPcV29KZea4djnbahRmzphUt5Y4U4E7Rt5B6VKXbM
6039b151556a1f0d28eee8bbe0d39a5cb4f6d739ed7fb8ba2828239a3d7169ae
4 secs
Thu, 29 Jul 2021 21:16:09 +0000
singularity
Task to build ogg on singularity
Linux
build1.0
linux4.9.33
glibc2.25
g++10.3.0
stdc++10.3.0
gmp6.1.2
mpfr3.1.5
mpc1.0.3
gzip1.8
texinfo4.9-bootstrap.s2
perl5.26.2
ncurses6.0
readline7.0
db5.3.28
gdbm1.13
Encode2.89-bootstrap.s2
tar1.29
diffutils3.5
file5.31
zlib1.2.11
bash4.4
coreutils8.27
make4.2.1
sed4.4
binutils2.29
flex2.6.4
m41.4.18
grep3.0
gawk4.1.4
shadow4.5
findutils4.6.0
which2.21
pkg-config0.29.2
g++10.3.0
ogg
Ogg container format library.
JavaScript must be enabled.
There was an error retrieving this content.
The content could not be found.
JavaScript must be enabled.
There was an error retrieving this content.
The content could not be found.
Generating tasks and queuing jobs...
JavaScript must be enabled.
There was an error retrieving this content.
The content could not be found.
JavaScript must be enabled.
There was an error retrieving this content.
The content could not be found.
Confirm message?