Many different components require the target download path and it is
needed early. Previously code existed to attempt to autodetect its
location and so defining the path was enforced later in the build
process. This created problems with ordering functions based on this
requirement but since the target path is now certain to be defined at
startup (due to previous changes) we can better align the location and
initialization of the data to the Config class.
As part of this change also avoid requiring the temporary working
directory to be setup as part of the Build class. This is done as a
cleanup due to the only real user of this location being the Content
class.
This also drops the stand-alone pkg_integrety main function that was
initially used as a one off test to avoid needing to run autospec to
validate the integrity of a package. This feature was seldom used and
doesn't function well without handling configuration so it was
dropped.
The build module had a number of globals that were referenced by many
other modules and has ordering dependencies with the config and
tarball module for some values. This made deciding on where certain
values get initialized difficult but before the initialization can be
addressed a refactor is helpful.
This change moves the global state (and functions that needed to act
on that global state) into a Build class. The goal of this work is
to better track what can be updated by a particular function, load
data in a sensible order and have it owned by a sensible component.
Some of this data is likely to be removed from the build class in the
future as initialization of download and base paths should take place
in other modules most likely.
The tarball module had a number of globals that were referenced by
many other modules and has ordering dependencies with the config
module for some values. This made deciding on where certain values get
initialized difficult but before the initialization can be addressed a
refactor is helpful.
This change moves the global state (and functions that needed to
act on that global state) into a Content class. The goal of this work
is to better track what can be updated by a particular function, load
data in a sensible order and have it owned by a sensible component.
I expect that future work will see the tarball, buildpattern and some
portions of the config moved around to better match what component
should own what data (and to better deliniate between the data that
has a similar use but comes from different sources).
The config module had a large amount of globals that were being
touched across many modules that would import. This made changes to
config very fragile as figuring out what would be modified in any
given call chain was difficult to diagnose.
It also made testing fragile as one would need to reset a given
module's config import to the best of their knowledge before rerunning
another test.
To get away from that (and to try and reduce the number of globally
modified variablies in autospec as a whole), refactor the config
module to provide its state as part config class. The long running
goal of changes like this is to better track what content can be
updated by a particular function (if a function would have access
to the config instance is now the hint rather than the config module
getting imported).
When the user chooses to import a public key during the autospec run
display information on that key in the commit message.
Signed-off-by: Matthew Johnson <matthew.johnson@intel.com>
with the imlpementation of the write_out functionality,
some unittests need to be changed to use that fuction.
Signed-off-by: Gabi Beyer <gabrielle.n.beyer@intel.com>
Autospec previously used an unsecure public temporary directory as its
working directory. This patch creates a secure temporary directory only
accessible by the creating user ID.
