- reduce boilerplace necessary to implement an operation
- consolidate what an operation is in the core, which in turn pave the way for a generic cache layer mechanism
- avoid the previously complex unmarshalling process
- support operation metadata from the core
- simplified testing
I believe the issue was twofold:
When done importing, the calling context is likely still valid, so if the output channel is not read enough and reach capacity, some event producer down the line can be blocked trying to send in that channel. When closing it, this send is still trying to proceed, which is illegal in go.
In rateLimitHandlerClient, there was a need to 2 different type of output channel: core.ExportResult and ImportEvent. To do so, the previous code was using a single channel type RateLimitingEvent and a series of goroutines to read/cast/send to the final channel. This could result in more async goroutine being stuck trying to send in an at-capacity channel. Instead, the code now use a simple synchronous callback to directly push to the final output channel. No concurrency needed anymore and the code is simpler.
Any of those fixes could have resolved the data race, but both fixes is more correct.
* Add option to skip the AvatarURL input request
Using an empty string for the avatar cli flag e.g. `git-bug user create
-a ""` will still result in a prompt. As the avatar URL is an optional
option, it should be possible to skip asking for it entirely.
Otherwise automated user creation via a script must make use of pipe hacks.
* Add global --non-interactive cmdline option
* Replace --skipAvatar for --non-interactive option
* Cmd BugAdd: respect non-interactive option
* Cmd bridge configure: respect non-interactive opt
* Cmd CommentAdd: respect non-interactive option
* Cmd CommentEdit: respect non-interactive option
* Cmd TermUI: respect non-interactive option
* Cmd TitleEdit: respect non-interactive option
* Remove global non-interactive option
* Cmd UserCreate: Use local non-interactive option
* Cmd BugAdd: Use local non-interactive option
* Cmd BridgeConfigure: Use local non-interactive option
* Cmd CommentAdd: Use local non-interactive option
* Cmd CommentEdit: Use local non-interactive option
* Cmd TermUI: Drop non-interactive option
It should be obviouse that the termui is an interactive command.
* Cmd TitleEdit: Use local non-interactive option
* Update docs
* Bridge GitHub: respect non-interactive option
* Bridge GitLab: respect non-interactive option
* Bridge Jira: respect non-interactive and token opt
* Fix failing compilation
* Bridge launchpad: respect non-interactive option
* bridge: isNonInteractive --> interactive
Co-authored-by: Michael Muré <batolettre@gmail.com>
GitHub have introduced a new format for their access tokens, which does
not fit within the rules of the previous regex. For the time being, the
previous token format is still being supported by GitHub, so it makes
sense to continue allowing legacy tokens.
https://github.blog/changelog/2021-03-04-authentication-token-format-updates/
The Github bridge itself should not write anything. This commit removes
code writing to stdout and itroduces an event `ImportEventRateLimiting`
to `core.ImportResult` in order to inform about a rate limiting situation
of the Github GraphQL API. Now the communication with the user is
delegated to the various user interfaces.
The old implementation of the github bridge used maps to store several
channels holding data obtained from the Github API. Removing the maps and
simply packing data and channels together in a struct and passing it
through one single channel makes the program simpler in terms of
concurrency and, additionally, enables the garbage collector to free the
memory gradually without any additional provisions.
Work in progress. The github bridge contains a bug documented in issue #385.
This commit shows what is the problem. There might be more problems. I have
changed the GraphQL query for timeline items and there are much less wrong
imports now. (Are there any malformed imports left?) I would like to rework the
entire bridge/github/iterator in the near future in order to create a reliable
fix for this bug.
- allow the creation of arbitrary Lamport clocks, freeing the way to new entities and removing Bug specific (upper layer) code.
- generalize the memory-only and persisted Lamport clocks behind a common interface
- rework the tests to provide reusable testing code for a Repo, a Clock, a Config, opening a path to add a new Repo implementation more easily
- test previously untested components with those new tests
Note: one problem found during this endeavor is that `identity.Version` also need to store one time + Lamport time for each other Entity (Bug, config, PR ...). This could possibly done without breaking change but it would be much easier to wait for https://github.com/MichaelMure/git-bug-migration to happen.
