* fix(git): instrument `SimpleGit` operations
Now we have the basis for instrumentation for SimpleGit, we can now
fully integrate it.
This creates a wrapper, `InstrumentedSimpleGit`, which has a simplified
interface for `SimpleGit` to allow us to focus on the important parts of
the interface for what we need, instead of trying to correctly extend /
implement SimpleGit's interface (and slightly complex types).
In each of our methods, we then make sure we instrument it with the
relevant Git subcommand being invoked.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* test(instrumentation): remove unused path
Currently, SimpleGit's `getRemotes` function being passed a `verbose:
false` is the same as not providing a `verbose`.
This fixes the code coverage failures, as we do not call this.
---------
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
As part of being able to fully instrument our Git operations - using
SimpleGit - we can introduce some Git-specific instrumentation helpers.
These helpers will be used as part of a future change, where we will
instrument methods of SimpleGit that we're using.
This provides a set of types which will be used as OpenTelemetry
Attributes to categorise command types.
A number of subcommands that aren't currently deemed to be too important
are bucketed into an `other` category.
As part of future changes to add an OpenTelemetry attribute for the
splits, we should make sure that we have a common type for the splits,
which can be used with `addSplit`.
This refactors - with some help from GPT-4.1 - to use Vitest's timer
mocking.
This also requires a slight refactor of the implementation to test more
appropriately, without duplicate calls to `Date.now`.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
As noted in #39406, we're seeing a number of self-hosted users who have
missed the onboarding requirement for a `GITHUB_COM_TOKEN` for their
authentication to `github.com`.
On top of the docs improvements in #39406, we can make this clearer by
adding a warning log when we're going to report a `rate-limit-exceeded`
error, noting which hostname is failing (in case of GitHub Enterprise).
This requires a slightly duplicated `fail` function re-definition, so we
can override the baseUrl.
In the case that the request fails for `github.com`, we can also point
to our docs for the configuration needed.
* docs(constraints): clarify that `binarySource=global` ignores them
Although this is a somewhat commonly known behaviour, it's worth making
this more clear, by clarifying this in the `constraints` docs, as well
as add a debug log.
* docs(constraints): simplify message
As noted by Michael, these may not be user-facing `constraints`, but the
constraints a Manager sets.
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* feat: Cleanup mutexes before each run
* Update setup.ts
* Update mutex.spec.ts
* Update setup.ts
* Unmock mutex in deb datasource spec to prevent race condition
* Update index.spec.ts
When using Redis in a cluster with authentication, we see errors
connecting to non-root nodes with:
WARN: Error while setting Redis cache value (repository=<org>/<repo>)
"err": {"message": "NOAUTH Authentication required."}
This change adds the username and password from the redis URL as
defaults for connections to non-root node servers as described in the
node-redis docs[0].
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
[0]: https://github.com/redis/node-redis/blob/master/docs/clustering.md#auth-with-password-and-username
feat(hostRules): automagically use host rules for any `api.github.com` lookups
As noted in #38732, the Typst datasource performs API calls to the
GitHub APIs, but as we do not have explicit datasource mapping for the
API calls (via `GITHUB_API_USING_HOST_TYPES`), we end up sending
unauthenticated API calls, which then can result in rate limits.
We had previously attempted to fix this in #30490, for a different
datasource, and there are likely other datasources impacted.
To simplify this, we can auto-wire any `https://api.github.com/` API
calls with the `hostType: github` hostRule, when matching against the
hostname from the `url`.
This also adds a note to deprecate the usage of
`GITHUB_API_USING_HOST_TYPES`, unless it's explicitly needed.
Closes#38953.
* ci: validate all Handlebars helpers are documented
* ci: validate all Handlebars helpers are documented
* chore: validate all handlebars helpers are documented
* chore: validate all handlebars helpers are documented
As part of #38953, we are changing the way that host rules work for
GitHub.com, and automagically wiring them in for datasources that
interact with `github.com`.
To do this, we should first provide a clearer definition of how host
rules should work, especially when there may be conflicting sources of
tokens, or where we may be on GitHub Enterprise Server vs GitHub.com.
This isn't technically needed, as right now the Merge Confidence API
allows URL-encoded or plain forms of the `:` symbol, but we should
perform our lookups more resiliently, to be safe.
Ideally we would use `encodeURIComponent`, but in keeping with the
existing escaping, we can use a regex replacement.
Jamie Tanna