2017-10-24 17:42:00 +00:00
|
|
|
package lfs
|
|
|
|
|
|
|
|
|
|
import (
|
2021-09-01 19:41:10 +00:00
|
|
|
"github.com/git-lfs/git-lfs/v3/config"
|
|
|
|
|
"github.com/git-lfs/git-lfs/v3/fs"
|
|
|
|
|
"github.com/git-lfs/git-lfs/v3/git"
|
go.*,lfs: mock time in copy callback log file test
In commit 00f1e9521ab5d39aab393796745189d39c27b9a0 of PR #5504 we added
the TestCopyCallbackFileThrottle() test function to confirm that the
CopyCallbackFile() method of GitFilter structure in the "lfs" package
now throttled its output of progress messages into a log file so that,
in general, no more than one message was written during the interval
defined by the tasklog.DefaultLoggingThrottle value. This new throttling
behaviour was added in commit 5bfa9009dafce59789b88b1a0854691b596f6e76
in the same PR.
The TestCopyCallbackFileThrottle() function attempts to validate
the throttling action by reading a test buffer in segments and waiting
or not waiting between each read, expecting the log messages to be
written or not written, as appropriate. However, because our CI test
suite may experience slow execution times as a result of running in
virtualized environments, reads may occur at times more than the
tasklog.DefaultLoggingThrottle interval apart even without the artifical
waits injected by the test function, causing the test to fail when it
sees more log messages than it expects.
We can avoid this problem by making the wait intervals in the test
deterministic using a mocked value for the current time. We use
the github.com/jmhodges/clock package for this purpose, adding an
object of its Clock interface type to the GitFilter structure. In
all non-test code this object is simply a wrapper for the "time"
package's functions, but in our test we can use a variant which allows
us to control the time values returned to the CopyCallbackFile() method,
either stepping forward or not, as we desire.
2023-09-28 06:13:30 +00:00
|
|
|
"github.com/jmhodges/clock"
|
2017-10-24 17:42:00 +00:00
|
|
|
)
|
|
|
|
|
|
2017-10-24 19:54:09 +00:00
|
|
|
// GitFilter provides clean and smudge capabilities
|
2017-10-24 17:42:00 +00:00
|
|
|
type GitFilter struct {
|
|
|
|
|
cfg *config.Configuration
|
2017-10-25 17:31:15 +00:00
|
|
|
fs *fs.Filesystem
|
go.*,lfs: mock time in copy callback log file test
In commit 00f1e9521ab5d39aab393796745189d39c27b9a0 of PR #5504 we added
the TestCopyCallbackFileThrottle() test function to confirm that the
CopyCallbackFile() method of GitFilter structure in the "lfs" package
now throttled its output of progress messages into a log file so that,
in general, no more than one message was written during the interval
defined by the tasklog.DefaultLoggingThrottle value. This new throttling
behaviour was added in commit 5bfa9009dafce59789b88b1a0854691b596f6e76
in the same PR.
The TestCopyCallbackFileThrottle() function attempts to validate
the throttling action by reading a test buffer in segments and waiting
or not waiting between each read, expecting the log messages to be
written or not written, as appropriate. However, because our CI test
suite may experience slow execution times as a result of running in
virtualized environments, reads may occur at times more than the
tasklog.DefaultLoggingThrottle interval apart even without the artifical
waits injected by the test function, causing the test to fail when it
sees more log messages than it expects.
We can avoid this problem by making the wait intervals in the test
deterministic using a mocked value for the current time. We use
the github.com/jmhodges/clock package for this purpose, adding an
object of its Clock interface type to the GitFilter structure. In
all non-test code this object is simply a wrapper for the "time"
package's functions, but in our test we can use a variant which allows
us to control the time values returned to the CopyCallbackFile() method,
either stepping forward or not, as we desire.
2023-09-28 06:13:30 +00:00
|
|
|
clk clock.Clock
|
2017-10-24 17:42:00 +00:00
|
|
|
}
|
|
|
|
|
|
2017-10-24 19:54:09 +00:00
|
|
|
// NewGitFilter initializes a new *GitFilter
|
2017-10-24 17:42:00 +00:00
|
|
|
func NewGitFilter(cfg *config.Configuration) *GitFilter {
|
go.*,lfs: mock time in copy callback log file test
In commit 00f1e9521ab5d39aab393796745189d39c27b9a0 of PR #5504 we added
the TestCopyCallbackFileThrottle() test function to confirm that the
CopyCallbackFile() method of GitFilter structure in the "lfs" package
now throttled its output of progress messages into a log file so that,
in general, no more than one message was written during the interval
defined by the tasklog.DefaultLoggingThrottle value. This new throttling
behaviour was added in commit 5bfa9009dafce59789b88b1a0854691b596f6e76
in the same PR.
The TestCopyCallbackFileThrottle() function attempts to validate
the throttling action by reading a test buffer in segments and waiting
or not waiting between each read, expecting the log messages to be
written or not written, as appropriate. However, because our CI test
suite may experience slow execution times as a result of running in
virtualized environments, reads may occur at times more than the
tasklog.DefaultLoggingThrottle interval apart even without the artifical
waits injected by the test function, causing the test to fail when it
sees more log messages than it expects.
We can avoid this problem by making the wait intervals in the test
deterministic using a mocked value for the current time. We use
the github.com/jmhodges/clock package for this purpose, adding an
object of its Clock interface type to the GitFilter structure. In
all non-test code this object is simply a wrapper for the "time"
package's functions, but in our test we can use a variant which allows
us to control the time values returned to the CopyCallbackFile() method,
either stepping forward or not, as we desire.
2023-09-28 06:13:30 +00:00
|
|
|
return &GitFilter{cfg: cfg, fs: cfg.Filesystem(), clk: clock.New()}
|
2017-10-25 17:31:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (f *GitFilter) ObjectPath(oid string) (string, error) {
|
|
|
|
|
return f.fs.ObjectPath(oid)
|
2017-10-24 17:42:00 +00:00
|
|
|
}
|
2018-01-05 22:01:29 +00:00
|
|
|
|
|
|
|
|
func (f *GitFilter) RemoteRef() *git.Ref {
|
commands,git,lfs: rename left/right RefUpdate vars
Since at least PR #2706, and indeed earlier, the local and remote
refs which are part of the RefUpdate structure have been referred
to as the "left" and "right" refs, terminology which stems from
the origin of this structure in the "git lfs pre-push" hook command,
where each line of input contains commit information in the form:
<local ref> <local sha1> <remote ref> <remote sha1>
However, outside of this context, "left" and "right" are ambiguous
terms, and may potentially be confused with the left and right
refs specified in a Git-style two-dot range notation. We therefore
replace these terms with "local" and "remote", which should help
clarify their purpose throughout the codebase.
2022-02-07 03:09:53 +00:00
|
|
|
return git.NewRefUpdate(f.cfg.Git, f.cfg.PushRemote(), f.cfg.CurrentRef(), nil).RemoteRef()
|
2018-01-05 22:01:29 +00:00
|
|
|
}
|
