This was exported from the AppVeyor UI, with a few modifications made to
upload the test results and throw an exception in the case of a test
failure.
Note that this overrides the settings specified in the AppVeyor UI.
Extend the GUI with a small progress bar within the backup job "details":
- add current action
- change the icon of the active job (paused, running)
- show / hide the GUI-extension (progress bar, filename, action) only if page-event contains a current filename
Extend the GUI with a small progress bar within the backup job "details":
- add current action
- change the icon of the active job (paused, running)
- show / hide the GUI-extension (progress bar, filename, action) only if page-event contains a current filename
Extend the GUI with a small progress bar within the backup job "details":
- add current action
- change the icon of the active job (paused, running)
- show / hide the GUI-extension (progress bar, filename, action) only if page-event contains a current filename
This class extends HttpClient and uses an OAuthHttpMessageHandler under the covers to automatically authenticate requests.
Additionally, it automatically respects the global HttpContextSettings for overall timeout, read/write timeout, and SSL certificate validation.
(BufferRequests isn't currently handled, as HttpClient doesn't seem to easily expose that flag, and as of .NET 4.5, seems to not buffer by default.)
For SharePoint, this means instead of giving the site ID as a parameter (and a relative path as the backup URL), the full URL to the folder in SharePoint (e.g., 'sharepoint://{tenant}.sharepoint.com/{PathToSite}/{DocumentBase}/{subfolder}') can be given, and the site ID will be looked up.
(This should match the existing SharePoint backend, including the convention of using '//' to indicate the document root, though I can't explicitly test that since the SharePoint sites I have access to require 2FA, which the old backend doesn't support.)
I've tested both explicit ID and site path methods of specifying the destination, and they appear to be working.
For Office 365 groups, it now supports looking up a group by its email address.
These backends are implemented via the common base class, MicrosoftGraphBackend, with only a few minor tweaks (different id parameters, protocol keys, descriptions, etc.)
All three backends support streaming, quota retrieval, and rename.
This class implements the abstract HttpMessageHandler class (mostly via the default HttpClientHandler implementation).
This abstract class is used by System.Net.Http.HttpClient as the underlying HTTP mechanism, and in this particular case is used to automatically add an authorization header to each request.
It also provides a method for marking a request as one that should not be authenticated.
These parameters weren't being used in the method body, or being passed in by any callers (it looks like a copy / paste error when a previous method was converted into this one)
These are replaced with a new optional parameter (method) which allows the caller to request a custom HTTP method to be used.
This is done by renaming the second file (or first if only one file is being created) and updating the in memory set of expected files,
while keeping track of the original info so it can be reported if it is still present (e.g., if the rename operated as a copy instead).
Without this, the auto create folders flag was broken for backends which lazily enumerate List() (as they instead throw after the try block is ended)
Calling Test() dierctly also better matches the IBackend interface contract.
Using GetAwaiter().GetResult() is similar to using Task.Result, but rethrows the original exception rather than wrapping it in an (unnecessary) AggregateException.
If one of these fields is accidentally reassigned, it's possible for
threads to be oblivious to an existing lock. By making the fields
readonly, we will be notified at compile-time if we inadvertently
redefine one of these fields.
Kenneth Skovhede