go.mod: Fix import path

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Add go module

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

repo: Add missing spaces in the configure cmdline for "xentools"

The operator + will just concatenate two strings. As the result, the
configure cmdline for "xentools" will look like:

./configure --disable-stubdom --disable-qemu-traditional--with-system-qemu=/bin/false --with-system-seabios=/bin/false--disable-ovmf

This can be avoided by explicitely adding the spaces.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>

Allow config-specified build sequences

At the moment, the sequence of steps used to to a build test of XSA
recipes is hardcoded to `./configure` followed by `make -j 8`.
Sometimes you may want to run other sequences of commands; for
instance to decrease build times or required dependencies.

Add the concept of a "build sequence" to the config file.  This is a
series of commands which will be run.

Add BuildSequences and DefaultBuildSequence to the config file.

Refactor test() to be able to handle either "-buildsequence" or "-bs"
arguments mixed in with the version numbers.  If this isn't set, use
the value from the config file (which may be empty).

If the final value is non-empty, use the sequence of commands defined
in the config file (returning an error if it's not present); if it's
empty, use the existing built-in sequences.

Modify `xsatool repo init` to contain a standard set of pre-defined
build sequences.

Document all this in README.md.

While here do a number of other minor clean-ups instigated by `go fmt`
and delete-trailing-whitespace.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

README: fix some typos and formatting

Signed-off-by: Wei Liu <wl@xen.org>

README.md: Expand instructions for updating / fixing up backports

Describe how to reset backport state manually, and add to-dos to make
the UI more useful.

Also include a section on using `fixup!` commits.

While here, fix a bunch of trailing whitespace.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Allow builds to happen in temporary worktrees

Allow builds to happen in separate worktrees, so that further work can
carry on while the build is happening.

Add TreeWork ("worktree") to be able to have a configurable path to
place the worktrees.

Add a new Worktree type.  Add Repo.WorktreeAdd(), which will:
 - Create a new worktree of the name `name` in the given path
 - Create a new branch for that worktree based on the name

Add Worktree.Delete() which will remove the worktree, and delete its
branch from the main repo.

In Recipe.Build(), if the worktree path is set in the config, make a
new worktree to do the build; otherwise, fall back to creating a
temporary branch.  As with the temporary branch, clean up the worktree
only if the build succeeded.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

recipe: Refactor temporary branch creation

The two paths are identical except for the branch name and the error
message; just use a variable for the branch name and call the branch
creation code once.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Pipe build output directly to a file

Open `build.log` and pipe stdout and stderr to it when building,
rather than using CombinedOutput (which will send it to a memory
buffer instead).  This will cause output to be written to the file as
it goes along, rather than only at the end.

Signed-off-by: George Dunlap <george.dunalp@citrix.com>

Minor README.md adjustments

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Add missing file

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Use VersionsFromString for set-patches

Move most of old function into a separate function, rather than
indenting into a loop, to make the diff cleaner.

While we're here fix a failure that returned 0 (the default value)
rather than 1.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Use VersionsFromString instead of VersionsFromArgs

Update README.md with the new interface.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Implement xenversion ranges

Implement VersionsFromString(), which takes a XenVersionSlice and
filter function rather than a pointer to an xsa and a flag.

Parse `all`, `master`, and use `..` for ranges rather than `-` so that
we can do things like say `..4.8` (since `-4.8` might look like a
flag).

Also implement tests

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Break xenversion and xenrepo into separate files

Since xenversion is already pretty large (and soon going to get larger).

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

README.md: Add documentation for dedup-patches

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

README.md: Add more ideas for future development

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Add `-f` flag to all checkouts

All the current instances of 'git checkout' are meant to be
destructive (several have `git clean -ffdx` afterwards).  In cases
where a file is generated and untracked in one version of Xen but tracked
in another version of Xen, `git checkout` will fail without the `-f` flag.

Since we're going to be destructive anyway, add `-f` to all `git
checkout` commands.

Signed-off-by: Georg Dunlap <george.dunlap@citrix.com>

global: Fix checking for new versions

The documentation claims that `xsatool global update` will check for
and initialize new versions.  But the code only does the check when
initializing a new global.meta.

Fix this by setting `limit` when global.meta already exists to the
most recent non-master version, and adding any version greater than
that version.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Doc update

We use 'staging' rather than 'master' now.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Fix "backport needed" detection

VersionsFromArgs() and MainBackport() were both using
xsa.RepoHasPatches() for slightly different things neither of them
quite correct.

xsa.RepoHasPatches() was checking to see that 1) a recipe existed, and
2) a "patch branch" existed.  At some point these basically became
identical, and so this test stopped behaving as expected.

VersionsFromArgs() wants to know what versions it should use if
nothing (or "all") is specified.  So a add new method, "HasRecipe()",
which simply checks to see if a recipe exists (even if it's empty).

MainBackport() wants to know if we need to perform a backport for a
particular version.  Add a new method, NeedsBackport() which answers
this question directly.  Return true if:

* A recipe exists and it's empty

* MakePatches() wouldn't make any patches given the current tree state
-- that is, xsa/NNN-baseline == xsa/NNN.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xen: Disallow majors == math.MaxInt32 as well

So that we can use that as an "invalid value".

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

README: Expand 'canonicalize' section

Describe in more detail what effect 'canonicalize' will have (and
why).

Also mention the British spelling.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

meta: Avoid redundant XenVersion information in recipe files

In the per-XSA meta file, we used to map recipes from XenVersion to
recipe; and then the recipe itself also contained the XenVersion.
This was loaded off the disk verbatim and not checked.

This presents an opportunity to make a mistake when editing the file
by hand (or with generic JSON-parsing libraries): if they don't match,
you might ask for a recipe for 4.10 but end up with a tree based on
master.

There's no need to save the version number in each recipe in the file.
Exclude the XenVersion struct element from being marshalled, and set
it on load with the version in the map (as we set the xsa
information).

Old metadata formats will still load correctly; `xsatool NNN
canonical` will effectively remove the information.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xen: Use staging-VV rather than stable-VV

The logic is the same as using 'staging' rather than 'master': We
ultimately want to make sure that it checks in as-is, without relying
on the push gate to have succeeded.

Update it in XenStableBranch, repo update, and the systemtest.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

meta: Allow absolute pathnames in .xsatool

If the path has a leading slash, treat it as an absolute pathname
rather than being relative to the directory .xsatool is in.

Also add unit tests to make sure the cases work (and continue to
work).

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

global: Add global 'canonicalize' command

Also accept 'canonicalise' for both global and xsa commands.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xsa: Add 'canonicalize' command

Canonicalize will simply read the metadata file and write it out
again.  This may be useful after editing it by hand or with external
JSON tools, to put it back in "golang canonical" form.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xen: Use MaxInt32 rather than MaxInt64 for internal version of 'master'

We currently use MaxInt64 as the "version number" for 'master' internally so that 'master'
always compares as "greater than" all normal Xen versions.  Unfortunately,
on 32-bit builds 'int' is only 32 bits, so building results in the following
error:

./xen.go:22:3: constant 9223372036854775807 overflows int

The 'math' package doesn't contain a MaxInt (which is why it was
MaxInt64 in the first place); but MaxInt32 will be fit for purpose for
both architectures.  At such time as Xen's major number exceeds 2
billion, we can deprecate the 32-bit build of this tool.

The other option would have been to use code from this template to
calculate MaxInt at compile time:

https://groups.google.com/forum/#!msg/golang-nuts/a9PitPAHSSU/ziQw1-QHw3EJ

But I think that would have been a bit overkill.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xsa: Patch de-duping, first take

First take of patch deduping: Run a separate command which, for each
version of an XSA:
 - Makes a branch with the current recipe
 - Takes the hash of that tree
 - Tries to make a branch with a potential "de-dupped" recipe
 - If that works, compare the hash with the previous hash

If the dedupped recipe applies, and the hashes match, change to using
the de-dupped recipe.  Otherwise, use the current recipe.

This will need to be reworked somewhat to support automatic de-dupping
during patch creation, but get a working copy in the tree.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Add function to get a hash of the tree at a particular reference

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Fix systemtest after move to use staging for 'master' version

Commit 54c104c switched the default "reference" for XenVersionMaster
to 'staging', but didn't update systemtest with the new expectations.
Do so now by doing the following.

Have the "InitialTreeState" set up both `staging` and `master` to point to
the same place.

Teach Story206Init to expect 'master' to look like 'staging'.

While we're here, update some hard-coded XenVersion("master")
instances to be the constant XenVersionMaster instead.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

main: Always attempt load the config

Rather than loading most of the time in main() (and failing if it fails),
and then also loading the config in "repo init" (and tolerating its absence),
always attempt to load the config, and only fail if we end up missing bits of
information that we need.

This will set the stage for unifying the configuration and the
command-line options.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

global: Open repos on-demand as needed

Rather than opening all repos whenever opening the config, only open
the necessary repos as needed.

Access global repos via GetRepo() rather than directly accessing the
map.

Initialize the map, and the repos, as needed.

Add xsa.OpenRepos() to open the repos necessary to work with a
particular XSA.  Call this as a prep for most XSA-related functions.

G.repos.xsa was only ever accessed from systemtest; have it open
xsa.git itself instead.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---

main: Clean up command demuxer

Minimize changing of variables by setting loadConfig to 'true', and
only disabling it for "repo init", setting loadXSA to true for all
'xsanum' commands, and using 'switch' rather than 'else'.

This also fixes a bug where an unknown 'target' would cause xsatool to
dereference nil.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

main: Move 'systemtest' command outside of XsaMain

XsaMain() is meant to be called by systemtest; there's no sense in
being able to call systemtest via XsaMain.  Moving the test for
'systemtest' into main() allows us to get rid of systemtest
special-casing re argument counts.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xsatool: Use xsa/ prefix for all xsatool-created branches

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Use staging rather than master as the default base for `master` commits

The 'master' versions are meant to be applied to staging, and aren't
generally expected to be used directly by downstreams.  If there's a
difference between master and staging, having it apply to staging is
more useful.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xsa: Add set-patches command to set patches for a particular xsa + version

...rather than editing the metadata file manually.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xsatool: Update README.md with more complete usage information

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

xsa: Return success when backport succeeds

Forgot to change the "unimplemented" message and return value after
implementing the 'backport' command.

While we're here, make backport a bit more chatty about what it's
doing.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

recipe: Bring patch name for master in line with standard practice

Standard practice is to have the patch that applies to master be
simply "xsaNNN.patch" (or xsaNNN/*.patch in case of a series).

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

recipe: Fix situation where there's no recipe for a prerequisite

It's not uncommon to "open up" several XSAs in a row, and to begin
work on subsequent ones before the backports to previous ones are
done.

If when making the baseline for a given Xen version for an XSA, one of
the prerequisete XSAs doesn't have a recipe for that Xen version, just
skip making the baseline for that version.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Implement reset-base

Implement reset-base, to reset the 'base' version to the upstream
stable trees without rebasing.

While we're here, document 'repo update' and add some comments.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

systemtest: Include fakeups for all 206 backports

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

repo init: Enable git rerere on the repos by default

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

README: Include a brief description of how to build.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

README: Mention mirrordir and gitproxy

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

meta: Get rid of VersionMeta.Latest

NB that the action of resetting outstanding XSAs will be manual as of
this commit.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

repo init: Add --mirrordir and --gitproxy options

...to set the appropriate proxy location.  Also add options to systemtest
to allow testing with those options.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

ToolConfig: Add MirrorDir and ProxyURL options

If available, use in Repo.Build when building Xen to create .config.

To do this:

- Make a XenBuildConfig type that contains methods for adding configs
for URLs, as well as both the repo path and revision (for qemu-based patches)

- Write unit tests for these methods

Use these in Repo.Build.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

systemtest: Delete all existing branches when not making from a clean state

Except `master`, of course.

Make sure to open all repos before cleaning branches.  (xsa.git will typically not be open
after `repo init` if it wasn't cloned.)

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Repo: Refuse to execute without a command except for 'git clone'

Running with a non-open repo could destroy the wrong data.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

systemtest: Implement --build

Always run 'test-apply'; run 'test-build' afterwards if --build is specified.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

systemtest: Implement --clean option to start from scratch

Pass all arguments to systemtest.  Use the `flag` package to read `-clean`.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

systemtest: Always re-run 'repo init'

Always run `repo init`.  If `tmp` already exists, delete `tmp/.xsatool`.

Set a limit that ToolConfig.Load won't go up higher than, so that when
starting the test from 'scratch' we don't get "real" configurations
from any higher-level directoiries by accident.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

systemtest: Abort the failed rebase

So that subsequent git commands (from another test) work

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Implement Repo.RebaseAbort

Wish there were a better interface, but here we are.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Miscelaneous fixes

Add missing arguments, remove a duplicated stanza

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Run go fmt

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Include README.md

This is based on the design document posted before, but is updated
with more workflow description, as well as future development plans.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Delete stackgit data when deleting or resetting branches

If a developer has modified a branch to be a stackgit branch as part
of development, simply deleting or resetting that branch with git
commands will "work", but will leave leftover state lying around which
may cause problems later.

Before deleting or resetting a branch, check to see if the branch is a
stackgit branch.  If so, use `stg branch --delete --force` to get rid of all
the stackgit data.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Implement backport

Implement Repo.Rebase() (with full head / base / onto)

Use this to implement Recipe.Backport()

Finally, implement xsatool [nnn] backport:
 - Look for the latest xenversion that doens't have a "patch" branch
 - Rebase next version from that onto it with 'git rebase'.

Always only do one, so that the caller has a chance to test the build
and look it over before continuing the backport process.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

XSAMeta: Keep SupportedVersions sorted in reverse order

There are many situations where we want to test things on master first
and then go backwards through supported versions (e.g., building,
looking for backports, &c).  Keep the SupportedVersions in this order.

To do this:
 - Refactor IsGreaterEqualThen to be usable by both it and IsGreaterThan
 - Make a XenVersionSlice type which implements sort.Interface, using the above
 - Re-sort XSAMeta.SupportedVersions on insert and load.

Also:

 - Have XSAMeta.NewRecipe() add the new SupportedVersions, rather
than having the caller add it manuall.

 - Keep XenVersion.PrevVersion() around, even though we're not using
 it for now, in case it becomes useful in the future.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

recipe: Handle prerequisites

When making baselines, iterate through prerequisite list and apply all
patches.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Build: Use mirror paths for qemu unless there are patches

Cloning from the working tree is running into build problems saying it
can't find the right changeset, even though the changeset is present
in the working tree.  For now, use the mirror directory.

This needs to be sorted out properly somehow.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Use new branching scheme

New branching scheme:

 - $v-stable based on the recorded stable branch at the time the xsa
   was created

 - $v-baseline; the above, but with 'prerequisites' (outstanding XSAs
   not published yet)

 - $v: Branch with actual patches, only present when patches exist (or
   are being created)

To do this:

 - Separate Recipe.Apply() into ApplyBaseline (which only does -stable
   and -baseline) and ApplyPatches (which makes the main branch)

 - Get rid of IsApplied(), which doesn't do what it says on the tin

 - Implement HasPatchBranch, which detect whether the "patch"
   branch(es) exist for a given recipe

Then:

 - During Init, call only ApplyBaseline for all branches; only call
   ApplyPatches for master.

 - When calling sync-patches with 'all', have VersionsFromArgs filter
   out patches based on HasPatchBranch.  (sync-branches and test will still
   test all supported branches for 'all'.)

 - Add a test for the failure path of sync-branches with a
   non-existent branch

While we're here:

 - Use fmt.Print instead of fmt.Printf when there are no format tokens

 - Add missing '\n' to many status output messages

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

recipe: Use StableBranch to create VVV-baseline branch

Get rid of XenVersionFull from the recipe and replace it with
XenVersion for convenience.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Add stable branch reference to TreeRecipe

Add XenRepo.MakeStableBranch() and XenRepo.GetRefVersion(), which will
make a "stable branch" and get the ref for the appropriate version.

Check out the 'stable' branch for each version when creating a new
repo, and take a reference.

Also update the testing infrastructure to set up the tree such that
the stable branches reflect the appropriate branches at the time.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Implement 'repo update'

Implement Repo.Branches() with a pattern.  Add code to handle empty
output and 'stray' values.

Implement MainRepoUpdate, which will call 'git fetch' and 'git merge'
on master and stable-* branches.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

testing: Test master build

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

test: Check for patches in recipe rather than relying on the existence of a branch

Implement Recipe.HasPatches(), which returns true if any of the trees
has patches.

Call it in test.go:test() before applying and/or building.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Change to in-binary test

`go test` apparently has a default 10-minute timeout.  This isn't
enough for all the tests in the "system test", and there's no way to
change the default except to manually add a --timeout parameter to "go
test".

Instead pull the test out into a special xsatool command.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

testing: Implement 206 'implement and sync' tests

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

main: Accept an empty set of versions as 'all'

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Apply: Always check out local master rather than origin/master

To make testing work

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Testing: Test xsa 206 init

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

main: Implement 'init' command

New method of creating a new xsa:  "xsatool NNN init [trees]"

This will:
- For a given set of trees
- And all the currently-supported versions
- Create an XSA that contains all the currently-outstanding XSAs for that tree and set of versions
- And create branches for all of those versions in the correct tree
- And add it to the list of currently-outstanding XSAs

At that point, the user can go into the appropriate tree and create patches.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Recipe: Allow MakePatches to detect and tolerate "empty" trees

In order to move to a world where all supported branches are created
automatically, with prerequisites applied, as "empty" when the XSA is
created, allow Recipe.MakePatches() to detect and tolerate "empty"
versions:

- Have MakePatches() return the number of trees which contained
  patches

- Instead of verifying the reference, get the hashes for base and
  branch and compare them; simply return 0 if they are the same

- Don't bother copying patches if none are to be created.

Modify xsa.go:sync() to handle this case as well.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Implement ParseRef to change a ref into a changeset

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

main: add loadGlobal option

To indicate whether a command should try to load the global metadata.

Signed-of-by: George Dunlap <george.dunlap@citrix.com>

global init: Always create a 'master' version as well

This will help is keep track of un-released XSAs.

TODO: Still need a good way to reset this when we've published the
XSAs.

While we're here, fix a typo.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

system_test: Check for specific versions, not just presence

Check for the specific versions, not just the presence of the
branches.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

VersionMeta: Make XSA list per-tree

Not all XSAs apply to each tree; therefore to which XSAs need to be
applied as prerequisites for a given XSA, we need to store them
per-tree.

Change this to a map[Tree][]int.  Create SecurityMeta.InitVersion() to
initialize an empty version properly.

Also:
- explicitly list in an XSA which trees are supported (unused)
- Add SecurityMeta.AddXSA(), which will update VersionMeta based on xsa.Trees

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

XSAMeta: Store recipes in a map[XenVersion] rather than an array

This makes accessing it easier, and also makes the json easier for
humans to parse.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Recipe: Add ForEachTree method to do something for each tree

Have MakePatches, IsApplied, and Apply methods use it rather than
ForEachXenRepo().

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Use full path for AM operations

...so that Repo.Am() works regardless of your cwd.

Factor "normalization" into normalizePath.

Implement globToFullPath, which will take a glob and return a slice of
normalized filenames.

Use globToFullPath() for Repo.Am() and Repo.AmClean().

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Testing: Test "xsatool global update" initialization

Re-constructing the history of XSA 206, go back to version 4.4.

Check to make sure that after the initialization we have exactly the
versions we expect.

Also sketch out a plan for our 'system testing'.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Testing: Add a testing "input indirection" layer

If called from main(), print the string and query the user.

Otherwise, look up the response in the index.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Testing: Add a wrapper for XsaMain so that calling it is less ugly

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

global: Refer to global SecurityMeta structure, not a local one

In part so that the testing harness can see what's going on afterwards.

While we're here add a newline to the "manually add XSAs" message.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

XenRepo: Don't automatically fetch on open to make testing more predictable

This may need to be revisited at some point.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

system_test: Add versions and lack of metadata to 'state'

Delete all versions >= 4.9, and any tags after 4.8.0 or 4.7.2.

Also delete xsa.git/*.meta

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Add Repo.DeleteTag

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Testing: Introduce 'system' test

To begin with, just clone repos and begin to set them up in a specific
state, so that we can test operations.

To make testing iteration faster, set FullClone == false.  After test
development is done, this should be set to "true" to make the cloning
continues to work.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

main: Call OpenRepos when loading config

Rather than having to open them each place they're used.

Also do some minor reorganization of variables, just code motion.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

main: Open xsa repo in OpenRepos

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

git: Add Repo.ResetBranch

To check out a particular branch.  This will be used in testing to set
up a particular view of the tree.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Refactor main to be more test-friendly

Have a special function, XsaMain(), which does the work and is passed
parameters and a return value.  Have a wrapper which interacts with
the operating system under normal conditions.  This allows the testing
infrastructure to simulate being called as closely as possible.

Get rid of global references to 'xsa' entirely; instead pass
references to a local copy on the stack.

Collect all remaining global state into a struct called 'G', and reset
its state every time XsaMain() is called.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>

XenRepo: Quieten tagsToVersions

Signed-off-by: George Dunlap <george.dunlap@citrix.com>