Sure, I will add it to the community sync agrenda.
My concern here is that the other IRC will still need to re-implement
significant portions of Polaris logic, some important blocks of the
top of the list: Auth token management, entity persistence, principals
management, entity access API; which i
Hi all,
Writing the following with my "nasty security guy" hat on:
Generally speaking, storing secrets is a quite sensitive topic that
deserves a lot of attention upfront, during the initial implementation
and for all changes related to it. What we already have in Polaris is
IMHO strictly speakin
Feel free to add it to the Polaris community sync agenda for Thu next
week
(https://docs.google.com/document/d/1TAAMjCtk4KuWSwfxpCBhhK9vM1k_3n7YE4L28slclXU)
On Tue, Jul 15, 2025 at 10:03 AM William Hyun wrote:
>
> Hey Robert,
>
> Thank you for your review and comments!
> To address some of your
I think this deserves a discussion in the next community sync, feel
free to add it to the agenda.
>From what I read in this thread: nobody is against the idea of being
able to federate to HMS.
However, technical concerns should really be considered, and I think
that it is a much safer option for
Hi all,
I did some investigation on what's going on with Renovate, why it's no
longer working.
It seems to be broken by my PR [1] to let Renovate suggest patch
version updates on 1.* release branches [1], which was done knowing
that Renovate supports multiple base branches in forking-Renovate [2]
Hey Dmitri,
Thanks for the update. I don’t have any strong concerns with this approach
— it looks good to me.
I would say calling two APIs (one to create the principal and another to
reset the credentials) is acceptable, especially since this also addresses
the broader issue of rotating/resetting
Good catch!
I merged the PR and renovate works again.
Thanks !
Regards
JB
On Tue, Jul 15, 2025 at 2:03 PM Robert Stupp wrote:
>
> Hi all,
>
> I did some investigation on what's going on with Renovate, why it's no
> longer working.
>
> It seems to be broken by my PR [1] to let Renovate suggest
Good question Mark -- I think there's likely a test gap here since this
should have failed CI. The docs also work for me locally. I only noticed an
issue when I started to see Hugo failures for unrelated PRs. It looks like
we also have #2087 in which case #2086 will not be necessary.
On Tue, Jul 1
Do we actually want it to run on release/1.0.x? Per "[DISCUSS] Disable
renovatebot on release branches", it looks like we do not.
On Tue, Jul 15, 2025 at 5:18 AM Robert Stupp wrote:
> Oh!
> According to the dependency dashboard [1] it works on both main and
> release/1.0.x :)
>
> [1] https://git
Thanks, Eric, for this step. When I build the page in my sandbox, I still
don't see the issue, and I guess that's because of the new addition of the
1.0 directory. How should I avoid this issue next time
On Tue, Jul 15, 2025 at 6:59 AM eric-maynard (via GitHub)
wrote:
>
> eric-maynard opened a
Feel free to open a PR,Eric.
On Tue, Jul 15, 2025 at 3:30 PM Eric Maynard wrote:
>
> Perhaps I misunderstood the functionality of PR #1891 -- if so, I
> apologize. Per the vote in the mentioned thread, it seems that there is
> consensus to not run renovatebot on branches for released versions lik
Yea - it already created 5 PRs (the hourly limit). Let's see whether
it catches the release/1.0.x branch as well.
On Tue, Jul 15, 2025 at 2:12 PM Jean-Baptiste Onofré wrote:
>
> Good catch!
>
> I merged the PR and renovate works again.
>
> Thanks !
>
> Regards
> JB
>
> On Tue, Jul 15, 2025 at 2:0
Oh!
According to the dependency dashboard [1] it works on both main and
release/1.0.x :)
[1] https://github.com/apache/polaris/issues/642
On Tue, Jul 15, 2025 at 2:16 PM Robert Stupp wrote:
>
> Yea - it already created 5 PRs (the hourly limit). Let's see whether
> it catches the release/1.0.x br
No problem, please see PR #2085.
Not sure what you mean Eric.
IIRC you merged the PR 1891, so I assumed you're also okay with that?
On Tue, Jul 15, 2025 at 3:07 PM Eric Maynard wrote:
>
> Do we actually want it to run on release/1.0.x? Per "[DISCUSS] Disable
> renovatebot on release branches", it looks like we do not.
>
> On Tue
I support Robert's proposal to leverage external IdPs in Polaris.
However, Arun's use case also has merit, IMHO, because it enables existing
deployments to migrate to newer Polaris versions, while keeping the old
Polaris Principals.
Migrating to an external IdP, while valuable from a security per
Perhaps I misunderstood the functionality of PR #1891 -- if so, I
apologize. Per the vote in the mentioned thread, it seems that there is
consensus to not run renovatebot on branches for released versions like
1.0.0, 1.2.3, and so on. I'm aligned with that.
If we maintained a branch like 1.x and p
Hey Robert,
Thank you for your review and comments!
To address some of your concerns,
1. Polaris would fall back to local execution (current behavior) in this case.
2. The delegation service would update the task status as a terminal
failure in its persistence, allowing users to retry once a relia
18 matches
Mail list logo
