I built this based on prom-label-proxy to support mapping basicAuth to
a set of tenant label matchers
https://github.com/kfdm/promql-guard
On Sat, Feb 15, 2020 at 1:43 AM Simon Pasquier wrote:
>
> You can have a look at those 2 projects too:
> https://github.com/hoffie/prometheus-filter-proxy
>
How do I make it so there is no entry?
On Fri, 14 Feb 2020, 18:07 Simon Pasquier, wrote:
> Correct, the PR is in the promu repository (I've updated it just now
> to address comments from Brian though it should have been done long
> ago):
> https://github.com/prometheus/promu/pull/170
>
> Right
Correct, the PR is in the promu repository (I've updated it just now
to address comments from Brian though it should have been done long
ago):
https://github.com/prometheus/promu/pull/170
Right now, it leverages the PR labels to classify the change (BUGFIX,
CHANGE, ...) and it uses the PR's title
Sure. Done.
On Thu, Feb 13, 2020 at 4:52 AM Daniel Trüssel wrote:
> On 12.02.20 01:49, Tobias Schmidt wrote:
>
> The mailing list should get archived on the mail-archive.com now. At
> least I added archive+...@mail-archive.com to the list subscribers as
> described.
>
> We hope that helps.
>
>
You can have a look at those 2 projects too:
https://github.com/hoffie/prometheus-filter-proxy
https://github.com/openshift/prom-label-proxy
On Fri, Feb 14, 2020 at 4:13 PM Conrad Wood wrote:
>
> On Fri, 2020-02-14 at 15:58 +0100, Julius Volz wrote:
> > On Fri, Feb 14, 2020 at 2:01 PM Conrad
>
> Even with all that the release shepard would still need to go through all
> the commits and double check that nothing was missed, plus fixing poor
> wording. I don't think saving 2-3 minutes off a release is worth all these
> downsides.
I agree with Bartek's response here, it's not a 2-3
On Fri, 2020-02-14 at 15:58 +0100, Julius Volz wrote:
> On Fri, Feb 14, 2020 at 2:01 PM Conrad Wood
> wrote:
> > That is a good point, I did not consider that labels might have
> > been
> > aggregated away. Clearly that needs to be considered.
> >
> > However, the ACLEvaluator also needs to look
On Fri, Feb 14, 2020 at 2:01 PM Conrad Wood wrote:
> That is a good point, I did not consider that labels might have been
> aggregated away. Clearly that needs to be considered.
>
> However, the ACLEvaluator also needs to look at the label values once
> the query returns(see Example 2). Or is
FWIW I'm looking into this. From my understanding, the bulk of the
issue is that "promu crossbuild" can't reuse the Go build cache
between CI runs hence it rebuilds everything from scratch every time.
On Thu, Feb 13, 2020 at 5:36 PM Ben Kochie wrote:
>
> Part of the problem is that we run the
But we don't have to block on changelog entries like we do for DCO legal
requirements.
For example, in GitLab codebases, we have a CI test that warns if a
changelog entry is missing. Unless you tag the review with a label.
On Fri, Feb 14, 2020 at 2:22 PM Brian Brazil <
The way I've been doing it in the node_exporter is to ask for the changelog
entry, but I don't block on it. If the code is ok, but they don't add a
changelog entry, I'll merge and do it myself.
Usually what saves the round trip time is I include a copy-paste text of
exactly what I want in the
On Fri, 14 Feb 2020 at 13:15, Matthias Rampke wrote:
> The friction is real – DCO is not a submission quality issue but a
> roundtrip one. This would be even more difficult with wording.
>
I'm with Matthias on this one. We've often have PRs which are ready to
merge, but have been sitting there
On Fri, 14 Feb 2020 at 12:50, Bartłomiej Płotka wrote:
> Hi,
>
> > Even with all that the release shepard would still need to go through
> all the commits and double check that nothing was missed, plus fixing poor
> wording. I don't think saving 2-3 minutes off a release is worth all these
>
The friction is real – DCO is not a submission quality issue but a
roundtrip one. This would be even more difficult with wording.
I agree that in *many* cases contributors can write the changelog entry;
having the field in the PR template would encourage them to do so
proactively.
/MR
On Fri,
DCO is a strawman argument. We're always going to have issues with
submission quality.
I've had very good luck asking for changelog entries on the node_exporter.
On Fri, Feb 14, 2020 at 8:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:
> On Fri, 14 Feb 2020 at 07:10, Frederic
On 14 Feb 13:07, 'Matthias Rampke' via Prometheus Developers wrote:
> No – I mean to explicitly *not* use commit messages or anything that
> requires the contributor to change. I want to keep it in the PR
> *description* that is editable through the GitHub UI.
>
> /MR
Like a prombot command
Sorry, I somehow was treating those the same. PR description would do even
better agree!
Kind Regards,
Bartek
On Fri, 14 Feb 2020 at 13:08, Paul Traylor wrote:
> Typically for my projects, I try to put the changelog entry in the
> merge commit. So Something like
>
> [BUGFIX] Fixes the bug
Typically for my projects, I try to put the changelog entry in the
merge commit. So Something like
[BUGFIX] Fixes the bug #123
and then when writing a release, I run something similar to `git log
--first-parent --pretty=oneline` to build my changelog
On Fri, Feb 14, 2020 at 10:05 PM Bartłomiej
No – I mean to explicitly *not* use commit messages or anything that
requires the contributor to change. I want to keep it in the PR
*description* that is editable through the GitHub UI.
/MR
On Fri, Feb 14, 2020 at 1:05 PM Bartłomiej Płotka
wrote:
> I think I like this idea of reusing a commit
I think I like this idea of reusing a commit message for this! We can
definitely build some automation around this and it looks like such
workflow would be a huge improvement!
Thanks Matthias.
Kind Regards,
Bartek
On Fri, 14 Feb 2020 at 13:02, 'Matthias Rampke' via Prometheus Developers <
In the exporters that I maintain I specifically ask contributors not to
fill in the changelog. I want to keep a somewhat editorial voice there. I
often rephrase changes to highlight what the change means for users, and
usually provide extra remarks like upgrade instructions or deprecation
notices.
Hi,
> Even with all that the release shepard would still need to go through all
the commits and double check that nothing was missed, plus fixing poor
wording. I don't think saving 2-3 minutes off a release is worth all these
downsides.
*It is 2h do it properly for mere mortals Brian (:
22 matches
Mail list logo
