Helm - allow loading all alloy files in /etc/alloy

PR Description
This PR implements this cli feature: https://github.com/grafana/alloy/commit/0b0b4a5e2d097238f94de36c0a8722b78ab5f01b
Currently, the chart only allows to load a single alloy file as an entrypoint.
This behaviour, even with modules, makes overrides or unloading components in some clusters difficult when using a common configuration.
This PR enables loading all alloy files in /etc/alloy (a la terraform).
Configmap can then be overridden in some environments/clusters by not loading, adding some files, or only modifying the needed one.
Which issue(s) this PR fixes

Fixes #228
Notes to the Reviewer
PR Checklist

[x] CHANGELOG.md updated
[x] Documentation added

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Fabien Culpo seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@tpaschalis I updated README with helm-docs.
Sorry, forgot this.

Basically, this PR tries to achieves what the meta k8s monitoring helm chart does: https://github.com/grafana/k8s-monitoring-helm/blob/2e2392002d17c98c100ade51e2ecaf2fa3e70a58/charts/k8s-monitoring/templates/alloy_config/_logs_service_loki.alloy.txt#L11
If/else on nonn "if-able" blocks

Opened proposal: https://github.com/grafana/alloy/issues/1176

I'm trying to think of the use-case around this. Specifically, I don't think it "feels" right just yet. Is there a circumstance where you'd want to load all files in a directory (/etc/alloy in this case), but also want to use the config map to create the config? Meaning, create a config using the alloy.configMap.content = "<config>, but also load additional files in the same directory. I don't even think it's actually possible to do that, since the ConfigMap is mounted at /etc/alloy.
I think a more intuitive solution might be:
alloy:
  configDir: /etc/alloy
  configMap:
    create: true
    mount: true
    key: config.alloy

configDir is always used.
configMap.mount controls whether the pod and container actually try to mount the configMap, if not, you're expected to replace that mount with your own volumeMount or your own.
So a few examples:
alloy:
  configMap:
    content: "my config"

Will create the configMap, with a config.alloy, and mount it. It will run against /etc/alloy/config.alloy
alloy:
  configMap:
    create: false

Will not create the configMap, but still expects one to exist, with a config.alloy, and mount it. It will run against /etc/alloy/config.alloy
alloy:
  configMap:
    create: false
    key: null

Will not create the configMap, but still expects one to exist, and will mount it. It will run against /etc/alloy
alloy:
  configMap:
    create: false
    mount: false

Will not create the configMap or mount it. It will run against /etc/alloy. You will need to use an extra volume mount.
configMap.create=true and configMap.mount=false should be an error.


Replace golang/lint with dominikh/go-tools

golang/lint is archived, they recommend using dominikh/go-tools. See also https://github.com/golang/go/issues/38968
Thank you for contributing! Please confirm this pull request meets the following requirements:

[x] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md
[x] I have no affiliation with the project I am suggesting (as a maintainer, creator, contractor, or employee).

Which change are you proposing?

[x] Suggesting edits to an existing topic or collection
[ ] Curating a new topic or collection
[ ] Something that does not neatly fit into the binary options above

Editing an existing topic or collection
I'm suggesting these edits to an existing topic or collection:

[ ] Image (and my file is *.png, square, dimensions 288x288)
[x] Content (and my changes are in index.md)

According to https://github.com/golang/lint/blob/master/README.md and https://github.com/golang/go/issues/38968, the existing Go linter is deprecated and unmaintained

Curating a new topic or collection

[ ] I've formatted my changes as a new folder directory, named for the topic or collection as it appears in the URL on GitHub (e.g. https://github.com/topics/[NAME] or https://github.com/collections/[NAME])
[ ] My folder contains a *.png image (if applicable) and index.md
[ ] All required fields in my index.md conform to the Style Guide and API docs: https://github.com/github/explore/tree/master/docs

Please replace this line with an explanation of why you think this topic or collection should be curated.

Something that does not neatly fit into the binary options above

[ ] My suggested edits are not about an existing topic or collection, or at least not a single one
[ ] My suggested edits are not about curating a new topic or collection, or at least not a single one
[ ] My suggested edits conform to the Style Guide and API docs: https://github.com/github/explore/tree/master/docs

Please replace this line with an explanation of your proposed changes.

Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

oh wow, TIL about golint! Thanks for this contribution, @CorralPeltzer. Our main branch was broken for a bit, could you try to merge main - the tests should go green after that and I'll be happy to merge.


Subscribing to page store in $layout.svelte throws error

Describe the bug
Subscribing to the page in $layout.svelte throws an error.
Logs

To Reproduce
Add this to the

I had the same issue, fixed it by doing a browser check first. See here: https://github.com/ivoberger/ivoberger.com/blob/master/src/routes/%24layout.svelte#L11
Site is in production and everything seems to be working.

I had the same issue, fixed it by doing a browser check first. See here: https://github.com/ivoberger/ivoberger.com/blob/master/src/routes/%24layout.svelte#L11
Site is in production and everything seems to be working.

Your workaround doesn't seem to work for me unfortunately

Are you still experiencing this with the latest version? I can't reproduce it

I can still reproduce this on the latest kit, however doing it like this seems to break:
import { browser } from "$app/env"
import { onMount } from "svelte"

onMount(() => {
	if (browser) {
		page.subscribe(() => {})
	}
})

Should I update this issue or create a new one?

That would be expected. To use the stores directly, you need to subscribe to the store synchronously during the initialization of the component (and not asynchronously later during mounting). If you want to be able to subscribe later, you need to grab the store synchronously by using getStores (like in Sapper). This is described in hhttps://kit.svelte.dev/docs#modules-app-stores

OK! Shouldn't be too hard for me to adjust the logic then to fix this unrelated issue.
@ivoberger @alteredorange, does this work for you all on your end?

Tinkered around with it a bit and while I had some odd behavioral at first (dynamic pages just weren't build) it now works reliably. I could subscribe to the page store without any checks around it.

excellent, will close this, thanks


这个插件如何在补全头文件比如#include时，光标在>的右边，否则每次都多跳过这个符号一次

Note: we mostly implement features in the clangd language server, and rely on coc.nvim's LSP client framework to expose these in vim. Features requiring a lot of coc-specific work are unlikely to be implemented.

clangd 返回的 snippet 是 include <$0>，光标会在尖括号中间，只能手动跳过。


Feat: Create a Responsive Footer with Location Information

Describe the feature
Enhance the application by designing and implementing a responsive footer that includes the company's location. This footer should be adaptable to different screen sizes and provide essential information accessibly.
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Similar Issue might be opened to make the footer interactive and adding location information.

assign this issue to me

@himanshu-03 I believe I have opened similar issue earlier.

Can you please assign this issue to me under Gssoc'24? I want to work on this.

the footer is already responsive

@himanshu-03 I believe I have opened similar issue earlier.

Yes you need not worry it is assigned to you as of now.


[D1] Client API page: formatting, syntax, grammar.

Had another suggestion, but LGTM otherwise

Thank you. Will need PCX to review this.


Update ingress.yaml: support empty list for .Values.ingress.hosts

For now, if the hosts field is not set, there will be an error while running helm install.
However, the host field is not forced to set in Kubernetes. No host field just means any host is accepted.
I update ingress.yaml so it won't throw error for empty hosts list then.

@SleepyBag this PR needs to be fixed, several things are missing. One thing above all, the chart version bump.
@desaintmartin what do you think?

This is a very complicated way to state that host is optional, isn't it? Moreover, I am not sure we want to allow a wildcard ingress (for reference, it seems the helm default template when creating a chart does not either).

@SleepyBag so?

@SleepyBag any update?


Group options

Is it possible to add a feature for dynamically grouping options, like:
Naval Fate.

Usage:
  naval_fate.py ship new <name>...
  naval_fate.py ship <name> move <x> <y> [ship_options]
  naval_fate.py ship shoot <x> <y>
  naval_fate.py mine (set|remove) <x> <y> [mine_options]
  naval_fate.py [options]

Options:
  -h --help     Show this screen.
  --version     Show version.

Mine Options:
  --moored      Moored (anchored) mine.
  --drifting    Drifting mine.

Ship Options:
  --speed=<kn>  Speed in knots [default: 10].

I made a PR that enables just that: https://github.com/docopt/docopt/pull/313
This example would be:
Naval Fate.

Usage:
  naval_fate.py ship new <name>...
  naval_fate.py ship <name> move <x> <y> [-ship_options-]
  naval_fate.py ship shoot <x> <y>
  naval_fate.py mine (set|remove) <x> <y> [-mine_options-]
  naval_fate.py [options]

Options:
  -h --help     Show this screen.
  --version     Show version.

Mine Options:
  --moored      Moored (anchored) mine.
  --drifting    Drifting mine.

Ship Options:
  --speed=<kn>  Speed in knots [default: 10].

Feedback is very welcome.

Awesome work!

Thanks for your taking your time.
Docopt syntax is based on POSIX, and we allow extensions only if their syntax is widely used. Do you have any alternatives to [-ship_options-] syntax that are more widely recognized? You are trying to solve this particular problem, that other CLI likely encountered before. How did they solve it? What syntax did they use?

That's the best syntax I could come up with. Suggestions are welcome.
Another idea was to just use [ship_options] (exactly as suggested here by @conqp), but that would limit its usability only to options. That is ok for many applications and is probably more widely recognized. I'm interested in a bit more though (see example in the PR).
I wasn't able to find any mentions of similar problems nor their solutions by other parsers. Perhaps I'm bad at searching but I did try... From what I have encountered in the wild, subcommands would be the way to go, git-style. Naval Fate implemented with subcommands would, IMO, be as serious overkill.

I have made a fork for my own use. I tried to make the authorship and copyright info plain. I hope you are ok with this, @keleshev. Let me know if not.
I will try to implement some additional features there. Some of which might be acceptable for merge with Docopt in the future.

Docopt syntax is based on POSIX, and we allow extensions only if their syntax is widely used. Do you have any alternatives to [-ship_options-] syntax that are more widely recognized? You are trying to solve this particular problem, that other CLI likely encountered before. How did they solve it? What syntax did they use?

@frnhr @keleshev
I don't understand why we need an additional syntax for it. It works for options:
Usage:
naval_fate.py [options]

Options:
  -h --help     Show this screen.
  --version     Show version.

Just let it work for more_options the same way:
Usage:
naval_fate.py one [options]
naval_fate.py two [more_options]

Options:
    -h --help     Show this screen.
    --version     Show version.

More_options:
    -f, --foo     Foo

?

Well, we don't need a new syntax, that's true. And probably more POSIX-y as well. But when I see usage pattern like this:
dump_and_erase.py (configuration | settings | options) [options]

I have no way of knowing whether options is a command or an option group. This makes it a "magic string", no? Using [-options-] (or whatever other new syntax is best) solves this issue.
Additionally, it might be interesting to have non-optional groups of options, for example:
naval_fate.py two -options-for-two- [three -options-for-three-]

Options for two:
  --x2 X2  The X-coordinate
  --y2 Y2  The Y-coordinate

Options for  three:
  --x3 X3  The X-coordinate
  --y3 Y3  The Y-coordinate

These are obviously contrived examples, perhaps there are better examples in the wild...
But yeah, it's not in any standard...

Oh, this issue is five years old. And I don't use docopt any longer. You might consider closing this.

@conqp probably quicker if you close it yourself...


fix: typo object to obj in isfunction check

Describe your changes
Minor fix in isfunction check

Awesome!
Did this lead to a bug? Asking since it would be great to add a unit test as well

Did this lead to a bug?

No, I was just exploring the code.

it would be great to add a unit test

I added one. Please check if it's good enough.

I don't understand why this isn't running the CI-CD workflow 🤔


Added cache_many method and open_many constructor argument.

cache_many loads a list of keys to the in-cache memory.
open_many take a list of filenames and returns a list of open files.
This is mostly to support overloading of open.

Instead of having the if self.open_many is None: branch, I could include the vanilla open_many from tests/test_core.py to core.py and have it set as the default.  I'm not sure which of these is nicer.

That sounds like a good idea to me.

Here's an example of prefetch in action:
c = Chest(path="HA_base64-results",
          open=partial(glopen, endpoint="maxhutch#alpha-admin/~/tmp"),
          open_many=partial(glopen_many, endpoint="maxhutch#alpha-admin/~/tmp"))
sc = CachedSlict(c)
c.prefetch(sc[:,'H'].full_keys())
plt.plot(sc[:,'H'].keys(), sc[:,'H'].values())

+1


is there a way to blank FreeRDP

I need to create a remote session WITHOUT showing anything on the screen, only add a remote user to the remote machine, is that possible to use a easy way, humm something like  /noshow or /NoX11 to do it? or probably to delete some files?

@cleric333 for questions please use our irc channel or the mailing list. We'd like to only keep real issues here.


opt: support recursive CTEs

PR: https://github.com/cockroachdb/cockroach/pull/41368
From release notes:

Added support for WITH RECURSIVE with UNION ALL. [#41368][#41368] {% comment %}doc{% endcomment %}

Duplicate of #5956.


org settings: Adding a realm filter returns an error.

To replicate, just add a realm filter. It seems to successfully add it, but returns an error that the filter already exists.

@rishig Can't reproduce it locally.

The bug here is I think that we don't clear the input fields or disable the button when you submit a request to add a filter, which means if you accidentally double-click, you'll get the error described.  We should probably disable the button while the request is in transit, and then clear the input fields if it succeeds.

Okay, I'll fix this, @zulipbot claim


marvelmind_nav: 1.0.6-0 in 'hydro/distribution.yaml' [bloom]

Increasing version of package(s) in repository marvelmind_nav to 1.0.6-0:

upstream repository: https://bitbucket.org/marvelmind_robotics/ros_marvelmind_package
release repository: https://github.com/MarvelmindRobotics/marvelmind_nav-release.git
distro file: hydro/distribution.yaml
bloom version: 0.5.22
previous version for package: null

marvelmind_nav

No changes

Hydro is EOL for a long time already. We do not run a build farm for it anymore. Therefore we can't accept new releases. Please consider releasing your software for a current ROS distribution (Indigo, Jade, Kinetic).


variable declaration with cte

I'm having trouble declaring a variable and a cte in one statement. This is something that works with sqlcmd.
Statement
STMT=$(cat <<'EOF'
DECLARE @bar INT = 1
;with foo as (select @bar as foo)
select * from foo
GO
EOF
)

sqlcmd
$ sqlcmd -S sqlserver.corp.com -U username -P password -Q "${STMT}"
foo
-----------
          1

(1 rows affected)

mssql-cli
$ mssql-cli --username username --password password --server sqlserver.corp.com --query "${STMT}"
Commands completed successfully.
Msg 137, Level 15, State 2, Line 2
Must declare the scalar variable "@bar".

I've repro'd the bug on my end. mssql-cli is able to print the scalar value as long as it's not referenced in a CTE.
Thank you @jtougas for letting us know about this bug!


mpv is missing features on Darwin

Describe the bug

Pressing f to go into full-screen mode doesn't work (other keys like q work as normal).
When not in full screen, the title bar and the quit/minimize/maximize buttons should not be visible under most circumstances; this is the behavior I observe when using mpv via Homebrew. However, a Nix-installed version of mpv does show the title bar and such.

Steps To Reproduce
nix-shell -p --pure mpv on aarch64-darwin.
Expected behavior

f should go into full-screen mode
Title bar and friends should not generally be visible even when not in full-screen mode

Notify maintainers
@marsam
He seems to be the most recent contributor to the mpv recipe who uses Darwin. I know he's not listed as a maintainer for mpv, but I don't think anybody on the maintainer list actually uses Darwin.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"aarch64-darwin"`
 - host os: `Darwin 21.3.0, macOS 12.2.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.6.0`
 - channels(root): `"darwin, home-manager-22.05pre347261.6d8215281b2, nixpkgs-22.05pre345869.46821ea01c8"`
 - channels(brian): `"darwin, home-manager-22.05pre347261.6d8215281b2"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

This is probably because we use the deprecated cocoa backend, because we don't have swift: #37473

Before Swift support is added to Nixpkgs, you can use IINA in the meantime which is built around libmpv and currently available in Nixpkgs.
https://iina.io/

Note that our IINA is a binary package.


Cannot find module

Following the quickstart I ran:
meteor --mobile-server=<IP_ADDRESS>:3000
This gave me the following error:
/path/to/my/app/.meteor/local/build/programs/server/boot.js:348
}).run();
Error: Cannot find module '../core-js/symbol/iterator'
Any idea how to resolve this? Thanks

I got this error yesterday. I was using Meteor 1.4.2 and I had to downgrade Meteor to 1.4.1. Then, if it is not working yet, make sure that the 'meteor' command works.
My 'meteor' wasn't working, so something in node_modules and/or .desktop was corrupted. I made meteor working again (but now with 1.4.1) removing node_modules, .desktop and meteor-desktop from packages.json.
Finally the mobile server is working with 1.4.1, but meteor-desktop should be fixed somehow for 1.4.2.

This does not seem to be related to meteor-desktop.
This error seems like something that might be thrown if you do not have babel-runtime added but that applies to <IP_ADDRESS> only.
@michaelb-01, @lorenzogm please check a clear project without meteor-desktop added to confirm the download meteor version works fine standalone. If the problems happens only after adding this package I will investigate this further.

If the problem persists in a project without meteor-desktop then it will be best if you will submit this as a meteor issue.

Can I close this?


[5.7] Allow Gates / Policies To Accept "Guests"

This PR allows gates and policies to allow "guest users" (null) to be passed to them instead of automatically returning false. They can allow this by marking their user type-hint as optional or providing a null default value for the incoming user:
$gate->define('foo', function (?User $user) {
    return true;
});

The same convention can be used for policy methods as well as before and after callbacks.

Great work Taylor, this is superb! 👍

@JosephSilber did you have any issues with this implementation?

Authorize all the things!

the semantics of it still don't necessarily jive with me.  I'd agree with the other people who have commented that it doesn't make sense to "authorize" unless we can "authenticate".  In my mind, we can only authorize something if we know who we are talking to.
I feel the middleware suggestions are the more appropriate solution for most of these requirements.

The examples given so far are definitely perfect for middleware. Sooner or later, saying no gets old though. It's here for good now and it doesn't really affect those of us who stick to the traditional definition of authorization, so 🎉

I definitely see your point there, but now we are introducing added complexity and potential for errors, in a system (authorization) that is incredibly important and basically has zero room for errors, to accommodate (imo) a very edge case need, that also has other (better) solutions.

I'd agree with the other people who have commented that it doesn't make sense to "authorize" unless we can "authenticate". In my mind, we can only authorize something if we know who we are talking to.

I don't get why people are so hung up on this. I see the authorization system as a permission system - a way of encapsulating logic related to authorising things, whether that be for authenticated user's or guest users, it doesn't matter. There are plenty of use cases where checking permissions on guest user's is absolutely vital to an application:
Use cases for Anonymous / Guest policy checks:

$this->authorize('view', $promotion) -> Is it christmas time? You can view that promotion, even as a guest.
$this->authorize('view', $picture) -> Is the picture publicly viewable? You can view those pictures, even as a guest.
$this->authorize('view', $dashboard); -> Is this guest from a known EU IP address? You can view the dashboard, even as guest.

Can you achieve this with additional logic / custom classes in your app? Absolutely. But policy checks is the natural and logical place to store these permissions checks that don't need "authentication" before "authorization".

I too have to say I currently lean towards the line of thinking that this doesn't belong in the authorization system at all, but am open to being convinced otherwise. I mainly put this together as a proof of concept since other solutions I had seen felt clumsy to me.

I have never needed this functionality myself.

And when you do, this makes a lot of sense to have this stuff inside the authorization system - otherwise you have to essentially bake your own just because, for some reason, you can't perform authorization checks on guest users.
I've personally needed this on a lot of projects I've worked on and in every case I've had to run additional boilerplate code, almost compete, along side Laravel's authorization. In my app, there are two ways to check authorization of something - that is less than ideal to me. Things would of been much simpler if the policy can say "hey, I accept guest checking, send an optional user my way".
The shear fact that this has been asked for so many times and the overwhelming positive response to this PR in such a short time shows there is a need for it. As you mentioned, Symphony has it, so it's not like this is an edge case or something. All the other solutions were pretty mediocre in their implementation details, but your one Taylor makes a lot of sense and I personally see only positives to having this in core.

If we merge this, we'll have to also remove the authentication check from the can middleware. It's a breaking change, but a really small one. Shouldn't be a problem for 5.7.

I've spent a lot of time thinking about this PR, and I've gone from being completely against it, to being "meh".  The PR provided clearly works, but whether it's a good solution from an organization or semantic standpoint is something we could bikeshed forever.
One technical note, though. Taylor, are you suggesting that gates/policies would simply make their User parameter optional?
public function show(?User $user, Blog $blog)
{
    return $blog->published;
}

My concern here would be generating a false sense of security, because this may encourage users to conditionally use the $user in their check.
public function show(?User $user, Blog $blog)
{
    if ($user) {
        return $blog->author == $user);
    }

    return $blog->published;
}

In this example, the if($user) block may provide a false sense of authorization, because a user who is not the author of the blog could simply log out of the application to view the blog.  I guess I would prefer we don't pass the User to the gate/policy instead.
public function show(Blog $blog)
{
    return $blog->published;
}

Although I imagine this would require a little more code on the backend of it.
One thing to note if this does get merged, it will require a relatively significant rewrite of the docs on authorization.

In this example, the if($user) block may provide a false sense of authorization, because a user who is not the author of the blog could simply log out of the application to view the blog.

Isn't that the expected behavior? The logic in that method states that published blogs are viewable by all.
In fact, the code there seems weird, since the way it is written not all logged-in users can view all published blogs. Which makes no sense.
I would rewrite that differently  make it clearer:
if ($blog->published) {
    return true;
}

if (! $user) {
    return false;
}

return $blog->author_id == $user->id;

Here's example piece of code to show guest authorization would be so awesome. Keeping all your permission logic in one place means you can use @can('view', $picture) in your views, use Gate class and $this->authorize in your controllers without having to bake your own class for additional policy checks for guest users.
use App\Member;
use App\Picture;

class PicturePolicy {

    /**
     * Determine if the member can view the picture.
     *
     * @param Member $member
     * @param Picture $picture
     *
     * @return bool
     */
    public function view(Member $member, Picture $picture): bool
    {
        // If the picture is public, anyone can see it, EVEN GUESTS.
        // No authentication required.
        if ($picture->public) {
            return true;
        }

        // All the following checks need an authenicated user,
        // so deny viewing picture if policy is checking with a guest user.
        if (is_null($member)) {
            return false;
        }

        if ($member->isAn('admin') || $member->isA('moderator')) {
            return true;
        }

        if ($picture->ownedBy($member)) {
            return true;
        }

        if ($picture->sharedWith($member)) {
            return true;
        }

        return false;
    }

}

If folks haven't been struggling with this in the past, I guess they haven't needed to do authorization without authentication, or they have just shoe-horned this kind of permission logic into their views or controllers. Keep all authorization logic in policies, regardless if guest or not 👍

I vote no. This is extremely unnecessary and not worth it at all. After numerous systems built never came across a need for this. Feels like a edge case that comes around so seldom that its not worth it. That's it it feels not right. 😊

Policies and authorization have, traditionally in web dev, applied to known entities. I admit, there's nothing tying us down to tradition, I just can't wrap my head around authorizing unauthenticated users. In all cases presented so far, a middleware fits perfectly.
However, after several years of this conversation bouncing around, it seems inevitable that it will make it into the framework, in some form or another. So, let the chips fall where they may.
-1 from me

@JosephSilber thanks for that updated example.  makes more sense than mine.

After reading your tweet announcing this I saw @ sebdesigneu tweet about using the null object pattern as an alternative and I find it a good idea which also provides an opt-in mechanism for those who want this.
If we add to the Guard some way to add a GuestUser resolver or class, this could do the trick.
I have not tested it,  it is just an idea, but it would look like this:
<?php

namespace App;

//  App\GuestUser.php
class GuestUser extends User {
    public function getIsGuestAttribute() {
        return true;
    }
}

// in a service provider

public function boot {
    Auth::setGuestUserClass(\App\GuestUser::class);

    Gate::define('view-post', function ($user, $post) {
        if ($user->is_guest) {
            return $post->is_published;
        }

        return $post->user_id === $user->id;
    });
}

Today, in most of the projects I work on, I use the null object pattern to handle guest users and I end writing a custom helper and a middleware to share it in all my views.
It is a different approach than the proposed one but the added bonus to have a GuestUser object available throughout the app would be nice. Maybe some changes to the auth()->check() would be needed to handle the case when we have a GuestUser instance.

I don't see how the NullObject pattern really changes the code here... you are checking for $user->is_guest vs is_null($user). It's the same amount of code. But, I don't want to get in a null-object debate around this use-case because it's pretty irrelevant I think and the main thing under discussion is should this feature exist at all.

@devcircus

I just can't wrap my head around authorizing unauthenticated users

Symphony has. And there's more than a dozen examples on this PR to show exactly how and when it's needed. Imagine a developer from Symphony coming over to Laravel and finding out you can't perform authorization on guests - that must be pretty frustrating. I'm not saying we need complete parity to whatever Symphony is doing, but a framework of that size and scale having a certain feature is indicative of solid reasoning.
Also it's not just Symphony offering this - see Django REST framework docs.

In all cases presented so far, a middleware fits perfectly.

Absolutely not. A middleware is good for "global" based authentication checks, it's a poor choice to put logic related to entity/model based permission checks. Policy checkers are the best place for those. If you have permission logic in your middleware, you can no longer re-use that logic in your views, for example:

"Should I show this picture because it's publicly viewable, even by guests?"
"Can we show this shiny promotion button because it's finally xmas time and we're doing our promotion, even for guests?"

However, after several years of this conversation bouncing around, it seems inevitable that it will make it into the framework, in some form or another

Good. It's been something that's been wanted by many for a long time and finally we have a decent implementation that is backwards compatible and a totally opt-in feature in the next version of Laravel.

It definitely should exists, I am implementing something similar in every project and I would totally see value if it is inside the framework. NullObject or not, I don’t really care...

Would a more segregated avenue be to introduce a dedicated Guest model alongside the User model? That way  we can authorize against the guest model explicitly? It seems to me that the functionality should be declarative and explicit in its intent. I could see this working very well with a guest user that has traits to permit it to undergo authorization checks.
This means that any non-logged-in-user would automatically be a guest user, so it might have larger implications in the overall auth system. I could see the auth()->user() functionality returning the Guest model if the user isn't logged in, thus allowing for any checks: auth()->user()->can(...);.

+1 From me. Doesn't seem to change anything for those who don't want to use it, and opting-in by making the $user argument nullable is as simple as it gets.

Policies for guest users are a great addition although the implementation does not look Laravelian :blush:
I think a
$gate->defineGuest()

would be more aligned with your style.

Overall, it looks good and useful.

I think null could be problematic because you cannot differentiate beetween a not logged in anonymous website visitor and a logged in guest user.

What is a logged in guest user?

I like this idea. I don't think it's the right use case for time based promotions (why are so many people leaving a christmas promotion unpublished to guests when it's christmas time?) but I can see a use for it. I have some customers that use a static IP for their VPN, and it would be nice to grant access based on a "user" that comes from that address without needing to bake in my own auth middleware or some other roundabout solution that doesn't require authentication.

and it would be nice to grant access based on a "user" that comes from that address without needing to bake in my own auth middleware or some other roundabout solution that doesn't require authentication.

Exactly. Another use case in my app is we check to make sure you are able to register an account - we use Cloudflare to check which country your from and if your from a certain list of blacklisted countries, you aren't able to register.
With this PR, it would be possible to do:
@cannot('create', $user)
    Sorry, we are currently not accepting registrations in your country.
@endcannot

If you wanted to get really smart, you can use $this->deny() in your policy to return a specific reason why they aren't able to register an account and spit out a more specific/appropriate reason.

I've been thinking a lot about this over the last couple days, and I think I've been flipped.  I've been getting hung up on the thought that authorization requires authentication.  The question is do we have to authorize a user to perform an action, or can we simply authorize an action? Up until now, we've only been authorizing users to perform an action, and it seems we (myself included) have become entrenched in that thinking.
I've been trying to think of a real life scenario where you can authorize a user or a guest to perform an action, since often it's helpful to pair up programming patterns with real life patterns.
Imagine a museum with a new exhibit opening on July 1st, and a guard posted at the entrance.  If a person approaches the entrance, and the date is after July 1st, the guard will not care who the person is, and will allow them to enter.  However, if the date is prior to July 1st, the guard will ask to see some identification. If the person has no ID, they will not be allowed to enter.  If the person has an employee ID, and they work in the gift shop, they still will not be allowed to enter.  However, if the person has an employee ID, and is the museum curator, the guard will let them pass.

If we change the definition of authorization, it works perfectly, and laravel is well within bounds to define authorization as it sees fit. However, to do so, would be switching the underlying behavior midstream.
The problem is, it has the potential to be quite confusing, not only because we're changing the actual foundation of Authorization in Laravel, but we're redefining what web authorization means to a LOT of developers.
That said, I'm actually ready for it to be merged so we can move on. As with most features I don't want, I'm sure I'll end up using it. 😁

However, to do so, would be switching the underlying behavior midstream.

It's an opt-in feature targeted at the next version of Laravel so not really "switching the underlying behavior midstream"

it has the potential to be quite confusing

Type hint that you can expect a null user and you may get a null user. The code is telling you what it want's to do. Not sure what's confusing?

but we're redefining what web authorization means to a LOT of developers.

Do you happen to have a link or some source/rulebook we can read that says "authentication must happen before authorization"? I would like to understand the logic as I think it's a pretty simplistic view to take.
As mentioned by @browner12, there's plently of examples not only presented above, but also in real life that don't require you "authenticate" or "identity" someone before performing authorization logic.
For example:

A new customer (guest) is trying to open a bank account, are we currently accepting new accounts to be open?
A guest is trying to enter the night club, is it VIP only night tonight or do we allow guests?

In Flarum we don't use Laravel's authorization system directly, but we have implemented something highly inspired by it.
Instead of authorizing "users", we authorize "actors". An actor is simply the entity who is using the application. It may be a User or a Guest. Guests are people too!

That's sounds like a good t-shirt slogan for Laracon this year. "Guests are people too!"

I would love to see this merged!

Marking the user parameter as optional is an explicit action, and its intent is very clear: I don't necessarily expect there to be an authenticated user.

@JosephSilber until now the Gate doesn't have any hard dependency (typehint) to the App\User or the Illuminate\Contracts\Auth\Authenticatable (which seems wrong to me, the Illuminate\Contracts\Auth\Access\Authorizable would be more appropriate). Also there is a Gate::forUser() method which is being used extensively.
So for me it means that there is a always $user argument in my callbacks, which is just an entity, but not necessarily an authenticated user, and I can pass whichever entity I want.
Whether there is an authenticated user or not is not a precondition for authorization. It means that there is an entity that is allowed/denied to perform an action. Your Bouncer package exhibits this nicely by having polymorphic entity relationships.
Having an optional $user parameter implies that there might be no entity at all to check against this action, which is semantically different than expecting that there is no authenticated entity. It also implies that the action's logic might be irrelevant to the $user (like the xmas promotion), which defeats the purpose of authorization.
I think it doesn't make sense to have a $user which is null, since the gate check is probably coming from a request which is triggered by a human being (which is a user, be we can't necessarily identify/authenticate them). This doesn't automatically mean that the user is null or they don't exist, they just might be a guest. Or maybe the check is done through $user->can() or Gate::forUser($user), so again, the $user could come from the db or anywhere.
The big issue here is that the guest functionality belongs in the scope of Authentication, not Authorization, but that's another story. We can still hack around that though.
Naive idea: Instead of using reflection to determine if the $user has a nullable typehint, I would use reflection to determine if there is a typehint and that typehint implements/extends a AllowsGuests interface or something. So adding the AllowsGuests interface in my User model would let/force me to implement a User::createGuest() method, that the Gate would call to get the guest instance.
if (! $user = $this->resolveUser()) {
    if (! $class = $this->allowsGuests($ability, Arr::wrap($arguments))) {}
        return false;
    }

    $user = $this->resolveGuest($class);
}

protected function resolveGuest(string $class)
{
    return call_user_func([$class, 'createGuest']);
}

Maybe a forGuest method would be handy too?
public function forGuest(string $class)
{
    $callback = function () use ($class) {
        return $this->resolveGuest($class);
    }

    return new static(
        $this->container, $callback, $this->abilities,
        $this->policies, $this->beforeCallbacks, $this->afterCallbacks
    );
}

This is not breaking BC, and respects the typehint and the intent of the callbacks, that they expect an instance of $user and not null.
In order to allow guest authorization they just have to add the AllowsGuests interface to the entity, which could internally (in the Authorizable/Authenticatable trait maybe?) make an empty instance of the same class, or let the developers override the createGuest to extend the class however they want.
Not sure this is ideal or better than @taylorotwell's implementation though.

Could this implementation perhaps be extended to the broadcaster channel authorization as well? I recently submitted a proposal that seems similar to this pull request: https://github.com/laravel/framework/issues/24608

Throwing my opinion, I'm not completely sure about this, but as so far I'm not really fond of having guest logic mixed in with authenticated user logic. I'd rather define separate policy for them where I know this code applies only to a guest user, not scattering around trying to glue things together what applies when and why.
In addition gate lacks the ability to separate policies and abilities, e.g. sometimes you have admin and client separated (frontend, backend, separate database tables and guard), but they both have permissions. At this point you can't deal with this in a simple matter without tweaking how gate works. So if this is considered, an optional path is a must - admin environment doesn't deal with guests, but the client might.

I've been thinking about this for a few days now and I just can't shake the feeling that it's going to end badly.
I can't quite put my finger on it, neither can I articulate just what exactly makes me feel this way, but every time I think about it, I just know it's going to bite someone in the ass at some point, but as long as it is a strictly opt-in feature, and I remember not to opt-in, I guess I'm fine with it existing.
My one concern is that this forces reflection checks for every policy check, which might have a measurable impact on apps that heavily rely on policy checks. For most applications it will probably be negligible, but I know I'll have to change the way I handle checking post editing permissions on post list views in a couple of my apps.

@garygreen

guest logic and authenticated logic are both one of the same thing; your checking permission someone has access to do something. And yes, as highlighted by people above, guest's are people too.

I agree that they're the same, but when they're in one function theres a bigger change an if mistake might cost more than having two separate class files/functions. Developers are people too, we make mistakes.

Laravel already supports multiple user providers and you can wire this up through middleware. Additionally you can use Gate::forUser() if you want to check against a different type of user than the one already authenticated.

That's not what I'm pointing at, yes you can provide different user but you can't provide different policies/abilities based on user type. Admin has one set of permissions, Client/Guest has other. Yes it might be a bit rare to have separated auth where both have different permissions, but it happens.
I'm not against this change, but I'm not for it either. I'd prefer avoiding doing checks $user !== null etc. and but at the same time I'm more fond of having have guest Class based on active guard driver.

My one concern is that this forces reflection checks for every policy check, which might have a measurable impact on apps that heavily rely on policy checks

Just done a benchmark, on PHP 7.2:
10,000 policy checks, reflection takes: 18ms
1,000 policy checks, reflection takes: 2ms
100 policy checks, reflection takes: 0.5ms
This is on a Intel core i5 2500k machine running on Windows. Not sure how many policy checks your app does for each request but seems to me there will probably be other bottlenecks in your app. Definitely a consideration though as we wouldn't want to slow down policies but I think above benchmarks show it's negligible.

There's already some wanting to extend this unauthenticated "user" idea to private broadcasting channels. Which, I guess, if you buy into the current argument, is the next logical step.
🤯

@garygreen

You would have to specifically type hint that you expect a null user and specifically return true from the policy for it to be granted. That's two big coding mistakes and if you have already type hinted that you can expect a null user - you have a bug in your code that need's fixing anyway.

So this is basically saying, even if you don't plan allowing a guest, you need to test every auth function to make sure it doesn't allow a guest, because someone might copy paste code and forget to remove the optional part. This is the main thing I don't like having it in one place.

Unit tests brother.

Guilty 😓 most of the time...

until now the Gate doesn't have any hard dependency (typehint) to the App\User

...and it still doesn't.

Instead of using reflection to determine if the $user has a nullable typehint, I would use reflection to determine if there is a typehint and that typehint implements/extends a AllowsGuests interface or something

You don't have to typehint anything if you don't want. Providing a default null value works just the same:
Gate::define('ability-name', function ($authority = null) {
    // $authority may be any model, or null
});

Maybe a forGuest method would be handy too?

Definitely makes sense, but should just set the user resolver to a no-op. (maybe should be called withoutUser) :woman_shrugging:

I'd rather define separate policy for them where I know this code applies only to a guest user, not scattering around trying to glue things together

On the contrary, it makes more sense to group logic by action (ability) than by user type. I should be able to look at a policy's action method and know exactly who's allowed and who isn't.

In addition gate lacks the ability to separate policies and abilities, e.g. sometimes you have admin and client separated (frontend, backend, separate database tables and guard), but they both have permissions

FWIW, you can achieve this using my Bouncer package, as outlined in the docs.

This raises alarm bells:

If we merge this, we'll have to also remove the authentication check from the can middleware. It's a breaking change, but a really small one.

To change authorization between minor versions (5.6 to 5.7) could be dangerous given we’re dealing with what users can and cannot do in an application. I can imagine there’s going to be a lot of instances of developers doing a composer update to 5.7, and then their applications suddenly behaving differently.
This isn’t a trivial framework issue, but an issue that can have a real impact on application security, and a company’s reputation and income.

Maybe just provide this as a swap-in Gate implementation? If you want old behavior, no changes required, if you want new - with guest, you just change the Gate binding to different implementation?

@martinbean

To change authorization between minor versions (5.6 to 5.7) could be hugely dangerous given we’re dealing with what users can and cannot do in an application.

As I'm sure your aware, Laravel doesn't follow semvar so there can be breaking changes between versions, as stated in the docs.

I can imagine there’s going to be a lot of instances of developers doing a composer update to 5.7, and then their applications suddenly behaving differently.

Blindly updating Laravel to the next major version without consulting the docs on the upgrade notes would be pretty foolish IMO. There's plenty of examples in the past where major versions have changed the behaviour of things and it's all detailed in the upgrade notes for developers to easily understand how it affects your app. This would be no different.

This isn’t a trivial framework issue, but an issue that can have a real impact on application security (users suddenly being able to view resources they couldn’t before), and a company’s reputation and income.

This has already been long discussed and as mentioned above, you would have to specifically type hint that you expect an optional user AND return true from the policy/gate. The code is being explicit in what it expects. So if your already doing an optional type-hint for user without expecting an optional user, then there's technically a bug in your code that should be addressed.

Blindly updating Laravel to the next major version without consulting the docs on the upgrade notes would be pretty foolish IMO

@garygreen Yes, it would, but people will do it.

@martinbean Do you have a suggestion on implementation details to make it a move smooth upgrade then?

To change authorization between minor versions (5.6 to 5.7) could be hugely dangerous given we’re dealing with what users can and cannot do in an application.

Removing the authentication check from that middleware will not affect what users can and cannot do in your application.

Well i am new to this discussion, but i have gone through all of your comments.
Being direct, IMO this needs to be implemented. One of the points was that "developers make mistakes too". I would say a developer can make a mistake you can't imagine (a user can forget to even check the authorization at all for a particular resource), irrespective of how strictly you implemented something.
why i am in favour of this? Bcz IMO it will enable us to avoid clumsy methods of doing this the other way + it does not have any implication on already implemented authorization logic.
+1

Merge it... ;)

This would be a good feature for 5.7 👍

@taylorotwell I love the idea of this neat trick to define something from the dev perspective.
However, I would never use such approach in an app that is maintained by more than 1-2 people who are 100% on the same page with laravel.
Here's why it might be a huge problem:
You have different people on the team, some of them might not be familiar with all the laravel quirks, maybe you got someone new joining.
There's an error somewhere because of TypeError and it gets hotfixed quickly by following the stacktrace and changing method signature from User $user to ?User $user.
Assuming fix gets merged and deployed, everything is working just fine.
But what we just did is change the business logic completely without even noticing. The code won't tell us that we've opened part of the app to the guests.
I see great value in having such an important thing as authorization being as explicit as possible.

That's what tests are for, right?

Tests dont really help for this no? Because your codebase wont have tests to check that a guest cant access it. You'll have to write it even if you dont plan to use it.

To be honest you should always test for these “unauthorized” test cases. What if you accidentally removed the policy call for example, how would your tests tell you?

This is something that the framework absolutely did not allow prior to this. It would not have made sense to test this prior to this possible addition. Still 👎🏻 for authorizing the non-existence of an authenticatable entity.

@m1guelpf @rovansteen I'm with you guys. I'm just pragmatic.
Saying this is what tests are for is not helping anyone. As @devcircus mentioned this is introducing something you'd not have tested (not mentioning you don't test the 3rd party code). In real life those things happen and I'm suggesting that we go for decisions that make things easier and add value rather than lead teams to a minefield.

Well, at the moment you do write tests to check that the policy does work as intended, but you know that only logged in user can reach the policy. With this change, you have no tests if someone adds a ?User to it.

Then you are talking about unit testing. If you have feature tests it’s something you should definitely test (do we prevent a guest from entering a comment on this blog post for example).
This change wouldn’t change anything for current implementations. So I’m curious why you think this would be too dangerous? Is it because the change (adding a “?”) is really small so can be done accidentally? Or that developers might not understand what the nullable type hint exactly means?

For example when building admin panel, theres mostly only auth tests that ensure only logged in users can pass, apart from that it's common knowledge in team that only admin can access it as the whole thing is under one auth guard group, so further tests for guest are skipped. User policy class can have both (why I think is bad) - frontend and backend logic in one file, but new developers wont know which is which unless you add a comment to all of them. So adding ? to user on a wrong check could go wrong in both cases. The things I've seen, nothing's impossible - mixing js and php inline if conditions is the most popular so far.

"theres mostly only auth tests that ensure only logged in users can pass"
That is a bold assumption.
Most apps will have a seperate admin role, if not many roles with different permissions if you ask me..

but you know that only logged in user can reach the policy. With this change, you have no tests if someone adds a ?User to it, so you have to add it for every policy you have.

Don't you guys have an auth middleware on routes that require you to be authenticated to access a set of routes, anyway? You should absolutely be testing if guests can access a route or not, what if your developer accidentally removed the authorize check?! All you need to do is spin through your named routes and assert they have an auth middleware, not that difficult really.
Also let's assume you did "accidentally" add a question mark inside the policy... surely your doing some logic in the policy to access stuff on the user object anyway? You would get an error of some kind. And if your not using the user object, then ironically this PR is for YOU. Happy days.
I've personally needed this feature on many projects I've worked on and would love to see it merged. I'm easy about how it's implemented whether it be a guest user object or some other way of hinting, but in it's current form it makes a lot of sense to me; you type hint that you expect an optional user, and you may get an optional user. Nothing too unclear about that, IMO.
Mantra: Policies should not be restricted to just authed users - guest's are people too. 😄

Don't you guys have an auth middleware on routes that require you to be authenticated to access a set of routes, anyway? You should absolutely be testing if guests can access a route or not, what if your developer accidentally removed the authorize check?! All you need to do is spin through your named routes and assert they have an auth middleware, not that difficult really.

Laravel is flexible, not everything needs to be web.php etc.. You could have it registered in service provider:
Route::middleware(['web', 'auth:admin'])->group(\base_path('routes/admin.php'));

Also let's assume you did "accidentally" add a question mark inside the policy... surely your doing some logic in the policy to access stuff on the userobject anyway? You would get an error of some kind. And if your not using the user object, then ironically this PR is for YOU. Happy days.

Not everything needs a User check, there can be situations where you check IP address, cookie, session or URL parameter or anything else.

I've personally needed this feature on many projects I've worked on and would love to see it merged. I'm easy about how it's implemented whether it be a guest user object or some other way of hinting, but in it's current form it makes a lot of sense to me; you type hint that you expect an optional user, and you may get an optional user. Nothing too unclear about that, IMO.

We're (mostly) not arguing that this is bad and should not be merged, it's more of finding/discussing the way how it is/could/should be implemented, what could be bad etc..

@jarektkaczyk

Here's why it might be a huge problem: You have different people on the team, some of them might not be familiar with all the laravel quirks

You optionally type hint that you expect a null value and guess what?... You MAY get a null value! It's hardly a "Larvel quirk" it's in line with a language feature. Implying developers would not realise is an odd thing to say, imo

@garygreen yes, you must be right, I'm pretty new to this thing anyway :+1:

Laravel is flexible, not everything needs to in web.php etc.. You could have it registered in service provider:

In your example you are registering a global middleware check for authed routes.. not sure what your concern is? In your example your policies would never even be checked if there wasn't an authed user. In any case, as you say Laravel is flexible and when registering a route you always have the option of adding a middleware. Plus you should be unit testing properly to make sure non guests can access your routes, not sure why you aren't?

Not everything needs a User check, there can be situations where you check IP address, cookie, session or URL parameter or anything else.

Yah I removed that part of my original comment as realised it may not always be the case. But ironically your examples of ip address, cookie, etc are all perfect examples of why this feature is so useful - you don't need authentication before authorisation.

In your example you are registering a global middleware check for authed routes.. not sure what your concern is? In your example your policies would never even be checked if there wasn't an authed user. In any case, as you say Laravel is flexible and when registering a route you always have the option of adding a middleware. Plus you should be unit testing properly to make sure non guests cannot access your routes, not sure why you aren't?

Not sure where you're pointing at but without an auth middleware there's only the guest user so there's no point in checking if the user is authenticated. Adding ?User means that auth middleware allows guests.

@donnysim what solution do you suggest, then?

No one likes my solution 😅

No one likes my solution

Yah, because your suggestion is to scatter your permission logic across multiple files / checks which is more clumsy and prone to error, IMO.

Yah, because your suggestion is to scatter your permission logic across multiple files / checks which is more clumsy and prone to error, IMO.

But the same thing could be said about everything. It really depends, does separating frontend and backend controllers make it more difficult or clumsy? No, it makes it more clear and separated.

But the same thing could be said about everything. It really depends, does separating frontend and backend controllers make it more difficult or clumsy? No

That comparison is completely unfair.
It's more useful to categorise permissions by ability which have one endpoint. Of course this is a matter of perspective and depends on what design pattern you want, but I've always found it far more intuitive to have permissions based on entity and ability, so whenever you do e.g. @can('edit', $post) whether from a backend or frontend doesn't matter, if you've got access, you should be authorized.

Separating guest and auth policies does not mean that @can('edit', $post)  will be any different, you could explicitly state e.g. that Policies/Guest/UserPolicy::class is for guests and Policies/UserPolicy for authenticated user instead of mashing them together and adding ?.  Nothing would change from checking the permission perspective.

Separating guest and auth policies does not mean that @can('edit', $post) will be any different

It absolutely does. You would need to have a different ability name or have a wrapper around your models to direct them to a different policy. You've diluted your permission logic and split it across multiple endpoints, that suggestion is pretty horrendous imo, but each to their own I guess.

It's really not, the Gate is decides what goes where and who does the check on what. The only thing that would be different is you'd have separate policy files.
e.g.
protected $policies = [
    Post::class => PostPolicy::class,
];

protected $guestPolicies = [
    Post::class => GuestPostPolicy::class,
];

That's the only difference for policies everything else is for Gate to decide, not the developer.
The abilities part sure, you'd probably need to register two different functions:
Gate::define('show-post', function ($user, $post) {
    return $user->id == $post->user_id;
});

Gate::defineGuest('show-post', function ($guest, $post) {
    return $guest->ip === 'x.x.x.x';
});

It's not really as simple as adding ?User. Take this situation:
Gate::before(function ($user, $ability) {
    if ($user->isSuperAdmin()) {
        return true;
    }
});

What is expected to happen when some policies/abilities allow guest user? Should this be ran for both even if the responsible policy does not allow guest? Should this be ran only for authenticated user?

I guess that's one option, but I'd vote for this PR over that suggestion as it's a far cleaner syntax and simpler api surface.
If you still want to split your guest policies into separate ones (not a good idea imo, but meh), well even with this PR you can still do that. Do you still have the "accidental" question mark problem? Yes, but again that's really down to your code, team, linting, unit tests, w/e.


Fail to extract features on youtube 8M extraction

I installed the youtube8M feature extractor on CentOS7 system. when Iuse the command
"bazel build -c opt --linkopt=-s
--define MEDIAPIPE_DISABLE_GPU=1 --define no_aws_support=true
mediapipe/examples/desktop/youtube8m:extract_yt8m_features"
Some errors information appeared like below:
INFO: Repository eigen_archive instantiated at:
no stack (--record_rule_instantiation_callstack not enabled)
Repository rule tf_http_archive defined at:
/home/rd/.cache/bazel/_bazel_rd/7174b4479e18b62513c67bab8183f8f7/external/org_tensorflow/third_party/repo.bzl:134:34: in
ERROR: /home/rd/.cache/bazel/_bazel_rd/7174b4479e18b62513c67bab8183f8f7/external/linux_opencv/BUILD.bazel:16:16: Traceback (most recent call last):
File "/home/rd/.cache/bazel/_bazel_rd/7174b4479e18b62513c67bab8183f8f7/external/linux_opencv/BUILD.bazel", line 14
cc_library(name = "opencv", <5 more arguments>)
File "/home/rd/.cache/bazel/_bazel_rd/7174b4479e18b62513c67bab8183f8f7/external/linux_opencv/BUILD.bazel", line 16, in cc_library
glob(<1 more arguments>)
pattern cannot be absolute
ERROR: /home/dukun/featurextractor/mediapipe/third_party/BUILD:56:11: no such target '@linux_opencv//:opencv': target 'opencv' not declared in package ''; however, a source directory of this name exists.  (Perhaps add 'exports_files(["opencv"])' to /BUILD, or define a filegroup?) defined by /home/rd/.cache/bazel/_bazel_rd/7174b4479e18b62513c67bab8183f8f7/external/linux_opencv/BUILD.bazel and referenced by '//third_party:opencv'
ERROR: Analysis of target '//mediapipe/examples/desktop/youtube8m:extract_yt8m_features' failed; build aborted: Analysis failed
INFO: Elapsed time: 13.034s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (2 packages loaded, 210 targets configured)
It seems like some kind of OpenCV problem, but I'm sure I totally followed the instruction on "https://google.github.io/mediapipe/getting_started/install#installing-on-centos" to install MediaPipe and successfully ran the Hello World desktop example.
So where is the problem ?

Hi @Derek-Kun, Could you please respond the issue still exists with the latest build. Thanks!


Add NSURLExtensions

Add NSURLExtension(Easily get query in the Dictionary)
Update README.md

Thanks for the pull request :+1:
Will add it in the next release


The type 'NDArray' exists in both 'NumSharp.Core

after update package i faced with this error
Severity	Code	Description	Project	File	Line	Suppression State Error	CS0433	The type 'NDArray' exists in both 'NumSharp.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' and 'NumSharp.Lite, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'	WpfApp1	H:\xxxx\xxx\MainWindow.xaml.cs	135	Active

What libraries are you using?

i use this libraries
NumSharp => 0.20.5
SciSharp.TensorFlow.Redist =>1.15.0
SharpCV =>0.40
TensorFlow.NET =>0.14.2

You can downgrade SharpCV to 0.3.2.

This problem shows again when you want to use
https://www.nuget.org/packages/TensorFlow.NET/0.15.1
together with
https://www.nuget.org/packages/NumSharp/0.20.5
Any advice ?


SelectRow

When I use select row, it does not appear in the table.
IMG: https://ibb.co/dULcKS
 render() {     const selectRow = {       mode: 'checkbox',  // multi select       clickToSelectAndEditCell: true     };
Table:
 <BootstrapTable selectRow={selectRow} striped hover pagination version='4' ref='table' data={this.state.listbanco}>                   <TableHeaderColumn dataField='id' isKey={true}>ID</TableHeaderColumn>                   <TableHeaderColumn dataField='nome'>Nome</TableHeaderColumn>                   <TableHeaderColumn dataField='conta'>Conta</TableHeaderColumn>                 </BootstrapTable>
package.json:
{   "name": "crud",   "version": "0.1.0",   "private": true,   "dependencies": {     "axios": "^0.18.0",     "bootstrap": "4.0.0",     "font-awesome": "^4.7.0",     "mdbreact": "file:D:/re-pro-master",     "react": "^16.3.2",     "react-bootstrap-table": "^4.3.1",     "react-dom": "^16.3.2",     "react-error-overlay": "^4.0.0",     "react-scripts": "1.1.4",   },   "scripts": {     "start": "react-scripts start",     "build": "react-scripts build",     "test": "react-scripts test --env=jsdom",     "eject": "react-scripts eject"   } }
Why can this be happening?

Hey @Denis-String,
I just added:   const selectRow = { mode: 'checkbox'} and it worked for me.

It does not work here, I put it as you told it.
Did you test with Bootstrap 4 and React 16.3.2?

I found the problem, I use MDBootstrap and when I import the CSS happens this problem, would you have any idea how to solve it?
In order for me to be able to use both MDB and React Table


Add Schedule Software/Config Updates support

Could you add support for the BloxOne /api/upgrade_policy/ APIs, so we can manage maintenance windows and config updates via Go?  The OpenAPI documentation can be found here:  https://csp.infoblox.com/apidoc/docs/UpgradePolicy.

Sorry, meant to put this on the bloxone-go-client repo.  Closing here.


Automatically bump Homebrew formula

With a Homebrew formula for .NET in place with Homebrew/homebrew-core#60929, it would be great to set up CI such that  action-homebrew-bump-formula or bump-homebrew-formula-action could automatically bump the Homebrew formula every time a new version of .NET is released. I can assist in tackling this if you think this would be a good addition.

I can't think of a big reason not to do this. I assume the automatic trigger helps you maintain the Homebrew package vs. having to notice the update through some non-integrated tag watcher (or manually).
One question: How do you propose getting your PAT into the secrets cache for this repo? (I'm not familiar if GitHub actions has some good way to do this, or if you'd have to send it via public key encryption (or something) and trust us to handle it properly.)

I can't think of a big reason not to do this.

Great!

I assume the automatic trigger helps you maintain the Homebrew package vs. having to notice the update through some non-integrated tag watcher (or manually).

Indeed!

One question: How do you propose getting your PAT into the secrets cache for this repo?

I hope you or some other maintainer (perhaps preferably a bot user of some kind) could create a PAT and add it as a secret in this repository, then I don't even need to know what it is, only that it exists and under which name.

If I were to implement this now, which repository, which GitHub Actions events, etc., would be best to hook into?

@asbjornu - I am going to work on https://github.com/dotnet/source-build/issues/2776 this next week.  I see this as a good place to trigger the Homebrew formula.

@MichaelSimons, excellent! 🙌🏼

@asbjornu, I am working on the release pipeline Michael mentioned above. There is no problem with updating the Homebrew formula, but I'm worried that submitting a PR directly from our release pipeline sets the precedent that every distro/platform will be able to have it's own job in our pipeline, which isn't scalable. Is there a more maintainable solution that you can think of? Perhaps a list of webhooks in a file that we could POST to? Maybe an external repo running a scheduled GitHub Action that polls for new tags?
As a side note, I looked at the two GitHub Actions you linked above, and I couldn't find any equivalent for Azure Pipelines, which is what we use.

@asbjornu, I am working on the release pipeline Michael mentioned above.

Awesome!

There is no problem with updating the Homebrew formula, but I'm worried that submitting a PR directly from our release pipeline sets the precedent that every distro/platform will be able to have it's own job in our pipeline, which isn't scalable.

While I agree in theory, I think trying to find a solution that scales to infinite amounts of package repositories is a premature optimization. I would therefore suggest that a number of acceptable package repositories is found (I suggest the number 10) and that until that number is reached, nothing is done about the scalability problem. In the best case and perhaps even most likely scenario, that acceptable threshold is never surpassed. Thoughts?

Is there a more maintainable solution that you can think of?

Not really. It is quite common for the owner of an event to be responsible for announcing to event consumers that the event occurred. I would even say that a push model scales better than a pull model for event notifications.

Perhaps a list of webhooks in a file that we could POST to?

How would that be different from submitting a PR?

Maybe an external repo running a scheduled GitHub Action that polls for new tags?

While that is possible, it transforms the problem from a rather simple notification in the form of a PR into a pretty complex solution for all package repositories.

As a side note, I looked at the two GitHub Actions you linked above, and I couldn't find any equivalent for Azure Pipelines, which is what we use.

Afaik, the GitHub Actions just execute a command line behind the scenes so they should be possible to reproduce in AzDO. But I don't use AzDO myself, so I'm not sure exactly how that would look like.

I think trying to find a solution that scales to infinite amounts of package repositories is a premature optimization

We're less concerned about premature optimization than we are concerned about setting the precedent for accommodating every distro's unique update process in our pipelines. Ideally we could have some type of event anyone could subscribe to and trigger automation off of when a release goes out. That was my idea with the webhook suggestion. For now, we have put in place some automation that will notify the new dotnet distro-maintainers GitHub team with an announcement whenever there's a new source-build release.

We are creating discussion announcements for each release (example).  You can trigger GitHub actions when announcements are created.  It should be pretty easy to identify the release announcements and grab the source-tag from them to trigger workflows such as bumping the Homebrew formula.  If there is anything that we could add to the announcement to support this workflow, please let us know.

I don't hold any stake in this, but passing by, my suggestion would be to include JSON in an HTML comment at the end of the announcement post, so tools can parse that out without worrying about being fragile to changes in the message's wording. (From the other point of view: the friendly wording can be changed without potentially breaking people.)

[Triage] Closing with the recommendation stated in https://github.com/dotnet/source-build/issues/1836#issuecomment-1138761300.
@lbussell - please open an issue to track @dagood's suggestion - https://github.com/dotnet/source-build/issues/1836#issuecomment-1138806925


RDD support

For now we are limited to use JavaRDD and using JavaSparkContext to have easy-to-work-with RDDs in Kotlin.
My suggestion is to provide a Kotlin wrapper (or set of extensions) for the Scala RDD class to be able to work with those as well. Converting between RDDs and Datasets can also be made accessible using this.

@khud could you please look into it? I remember that you've had some support for RDDs, is it possible to incorporate your work inside our current solution?

A couple of years ago I tried to do so. It's not so easy, because it needs a lot of boilerplate code. I believe JavaRDD works well with Kotlin:
val rdd = sc.parallelize(listOf(1,2,3)).collect()
rdd.map { it * it }.reduce { x, y -> x + y }

I'm sure that some problems exist but it would be great to know what particular kind of improvements make you happy.

@Jolanrensen do you have any further questions about RDD support?

@Jolanrensen do you have any further questions about RDD support?

@asm0dey sorry for the late response. No, it's clear. I do think it might be a bit confusing for users to use Java RDD and Java SparkContext in Kotlin, but @khud is right that it would need a large amount of boilerplate code. It would be ideal if Apache would encompass Kotlin into the Spark API like they did with Java, but for now, using the Java classes together with this API is the best we've got.

@Jolanrensen there is an issue about it in Apache Spark's Jira: https://issues.apache.org/jira/browse/SPARK-32530
You can vote and even comment there. We're interested to be included in upstream too.

Closing it for now as won't fix due to lack of demand. We'll reopen it if the demand will grow.


Providing another map service

Is this app provide another map service ? Like ArcGIS Server ?
I want to use arcgis server wms service on google map.

Have a look at WMS_FORMAT_STRING in TileProviderFactory!


Uncaught TypeError: Cannot redefine property: render

Uncaught TypeError: Cannot redefine property: render
    at Function.defineProperty (<anonymous>)
    at <unknown> (file:///..../app/node_modules/@uiw/react-color/cjs/index.js:188:10)

NextJS (tried to turn off SSR, checked for window variable etc) - no difference. Do you have any advises here? Thank you in advance

@indapublic
https://github.com/uiwjs/next-remove-imports

@indapublic

https://github.com/uiwjs/react-md-editor/issues/52#issuecomment-848969341

I am also having this same issue in a React unit test, any solutions?

I've attempted to use the 'next-remove-imports', but I'm still getting 'Cannot redefine property: render' error.
Am I doing something incorrectly?
My next.config.js:
const { withSentryConfig } = require('@sentry/nextjs');
const removeImports = require("next-remove-imports")();
const withPlugins = require('next-compose-plugins');

let config = {
  reactStrictMode: true,
  experimental: { esmExternals: true },
  eslint: {
    // Warning: This allows production builds to successfully complete even if
    // your project has ESLint errors.
    ignoreDuringBuilds: true,
  },
};

module.exports = withPlugins([
    removeImports,
    [ withSentryConfig,
        { silent: true ,
        hideSourcemaps: true },
    ]
], config);

@victoriaSh
// next.config.js
const removeImports = require('next-remove-imports')();

module.exports = (phase, { defaultConfig }) => {
  return removeImports({
    ...defaultConfig
  });
};

// next.config.js
const removeImports = require('next-remove-imports')({
  test: /node_modules([\s\S]*?)\.(tsx|ts|js|mjs|jsx)$/,
  matchImports: "\\.(less|css|scss|sass|styl)$"
});

module.exports = removeImports({
  webpack(config, options) {
    return config
  },
});

// next.config.js
const removeImports = require('next-remove-imports')()
module.exports = removeImports({
  webpack(config, options) {
    return config
  },
});

Hi there, it looks like the same error occurs on Jest test suites ran on a pure React project (no NextJS involved here).
I use the commonJS bundle and tracked the error down to @uiw/react-color-colorful lib import.
In the built source (in @uiw/react-color/cjs/index.js file), it happens here (line 188):

I'm not sure that the next-remove-imports lib is a solution in this case. Do you have any other solution in mind ?
Thanks !

OK, I found a solution by myself.
If other people get the same issue, that what I did:

Import react-color classes from '@uiw/react-color/esm'
Add @uiw/.*, colors-named, and colors-named-hex patterns to your Jest configuration in transformIgnorePatterns value (eg: transformIgnorePatterns: ['/node_modules/(?!@uiw|colors-named|colors-named-hex)'],

I have a NextJS project and faced the same issue.
Just found out that importing components from @uiw/react-color/src/index, solved the issue.
For example:
import { Circle } from "@uiw/react-color/src/index";

Had this same issue when using Astro. Changing imports to @uiw/react-color/src/index worked
import { Sketch } from "@uiw/react-color/src/index";

The reason this breaks is because in the package export, every sub package is exported with export * from "foo". The problem with that is multiple packages define a render export.
When this is compiled down to CommonJS, it ends up like this. Each of these Object.keys blocks is looping over all the exports from the sub package, and attaching them to exports using Object.defineProperty.
var _reactColorSwatch = _interopRequireWildcard(require("@uiw/react-color-swatch"));
Object.keys(_reactColorSwatch).forEach(function (key) {
  if (key === "default" || key === "__esModule") return;
  if (Object.prototype.hasOwnProperty.call(_exportNames, key)) return;
  if (key in exports && exports[key] === _reactColorSwatch[key]) return;
  Object.defineProperty(exports, key, {
    enumerable: true,
    get: function get() {
      return _reactColorSwatch[key];
    }
  });
});
var _reactColorWheel = _interopRequireWildcard(require("@uiw/react-color-wheel"));
Object.keys(_reactColorWheel).forEach(function (key) {
  if (key === "default" || key === "__esModule") return;
  if (Object.prototype.hasOwnProperty.call(_exportNames, key)) return;
  if (key in exports && exports[key] === _reactColorWheel[key]) return;
  Object.defineProperty(exports, key, {
    enumerable: true,
    get: function get() {
      return _reactColorWheel[key];
    }
  });
});

The problem is, tou cannot use Object.defineProperty to redefine an existing property. So the first block defines a render property on exports, and then subsequent packages try to set the same property, causing the error.
The solution is to avoid exporting sub packages like this, or at least being careful that each sub package defines unique exports.
As a super hacky fix, I have added a patch to my project which adds the configurable option to each Object.defineProperty in the CommonJS file. This allows subseqent packages to overwrite the render export without the error, but it's not ideal.
var _reactColorWheel = _interopRequireWildcard(require("@uiw/react-color-wheel"));
Object.keys(_reactColorWheel).forEach(function (key) {
  if (key === "default" || key === "__esModule") return;
  if (Object.prototype.hasOwnProperty.call(_exportNames, key)) return;
  if (key in exports && exports[key] === _reactColorWheel[key]) return;
  Object.defineProperty(exports, key, {
    enumerable: true,
+   configurable: true,
    get: function get() {
      return _reactColorWheel[key];
    }
  });
});


feat: command to replicate minimal information of the social user

https://legendaryum.atlassian.net/jira/software/projects/LE/boards/1?assignee=712020%3A71750ee7-8648-475c-99c7-c39c60a8e3fc&selectedIssue=LE-2696


Two reverts to resurrect the builds

The commits being reverted has broken the build (all the targets):
https://ci.linaro.org/view/All/job/lhg-oe-build/174/
These changes need to be re-implemented and then resubmitted via pull requests.


screen too dark

Hi, thanks for your work.
I tried the tutorial without a camera and the MCU board is the same as yours. It can detect if there is a person in the picture. But the screen was too dark. Where can I adjust to make the screen brighter.

Hi @Super-Karl,
Thanks for trying our tutorial. Unfortunately, we are not sure how to do that either. I would recommend posting this issue in the STM dev community to see if someone can help.

Close due to inactivity. Feel free to reopen.


[BEAM-4273] Adding context switch to operations missing it.

Some operations are missing context switches, and thus msecs and possibly metrics may be missattributed when jobs run.
r: @tvalentyn

Run Python PostCommit
for good measure

Run Python PostCommit


[WIP][MXNET-862] Basic maven jenkins pipeline

Description
This is a WIP PR to share progress on the maven nightly jenkins pipeline. The goal is to create a Jenkins for continuous deployment that will build scala jars, test them on multiple different environments, and then deploy them to the apache snapshot repository. It can also provide some setup for building out additional continuous deployment efforts for other platforms such as pip.
Note that this PR depends on https://github.com/apache/incubator-mxnet/pull/13046 and is rebased on top of it. Those changes are displayed as part of the first commit in the PR.
@nswamy @lanking520 @andrewfayres @piyushghai @marcoabreu
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[x] Build pipeline for build, test, deploy
[ ] Test on multiple distributions
[ ] Build and test both cpu and gpu
[ ] Use static linking for scripts

@mxnet-label-bot add [Java, Scala, CI, Maven]

Lets wait until after the release before we move forward with this PR as discussed on dev@ :)

@zachgk Can you rebase this PR?
@mxnet-label-bot Update [pr-work-in-progress]

I am currently thinking that since these are relatively large commits, I would split them into three different PRs that will create respectively a basic pipeline, a pipeline with multi-environment testing, and the final pipeline integrating the static linking code. After rebasing, I reduced the amount of code as part of this PR (it has some of commit 2), so it should be roughly equal to the code from 20 days ago. This also no longer has code from the packageTest utility because that was merged into master.
@mxnet-label-bot update [CI, Java, Maven, Scala, pr-awaiting-review]

As part of the later PRs, the changes to the current files will include:

Add new Docker containers specific to publishing and a clean dependency-less environment for testing so the updates to ubuntu_scala will be moved
The scala deployment will be moved from scala-package/dev to ci/publish/scala
It will use the static building script instead of the scala-package/dev/compile-mxnet-backend.sh script for building the backend

Note that this PR forms a working pipeline that will build, test, and then deploy the package for ubuntu 16.04

@marcoabreu Could you please review again?


Disable the test test_batchnorm_training

@piiswrong @rahul003 @eric-haibin-lin @cjolivier01 @sandeep-krishnamurthy  @nswamy

What's the status on fixing the last skipped test?

@piiswrong  The issue is still open and needed specific Visual studio to debug. Since the test only failed on windows machine.  CC'ing @eric-haibin-lin who owns the issue

The Build is failing in perl-gpu test not related to this commit.


Port REPL UI tests

Implementation of the tests has barely changed, but that's difficult to see in the PR. Pretty much just the addition of the interpreter parameter, and passing it down to the Prepare method.
Test implementation used to be a multitude of derived classes for the convenience of controlling what test to run under what interpreter, but now it's a single class (send tests are separate as they were different enough).
Some class inheritance in the runner in order to control which tests run under what interpreter ;)  but seriously it's not as confusing as before.
It's easier to tell now which tests are covered under multiple interpreters.

👍


skip empty strings when split disabled_extensions option.

Bug Template
Title: When parsing disabled_extensions option, we should skip empty strings when strsplit the commandline option string.
Description: When parsing disabled_extensions option, we should skip empty strings when strsplit the commandline option string. Otherwise we end up with a warning msg when MainCommon tries to parse the disabled_extensions, as there is an empty string in the list by default.

/assign stevenzzzz

Dup https://github.com/envoyproxy/envoy/issues/9377


[WIP] Added test to ssh into a docker container.

Closes #272.
Also adds the option to specify the ssh port.

Is this going to run during make ci?

@kris-nova Yes


Builds failing likely due to Python 2 support ending

Builds failing when pip tries installing:
Traceback (most recent call last):
  File "get-pip.py", line 24244, in <module>
    main()
  File "get-pip.py", line 199, in main
    bootstrap(tmpdir=tmpdir)
  File "get-pip.py", line 82, in bootstrap
    from pip._internal.cli.main import main as pip_entry_point
  File "/tmp/tmpw8qqxl/pip.zip/pip/_internal/cli/main.py", line 60
    sys.stderr.write(f"ERROR: {exc}")
                                   ^
SyntaxError: invalid syntax

Testing a fix just switching everything over to Python 3. Might break some builds... but better than having this image just rot forever...

Well, Python 3 caused a new can of worms, which I didn't want to jump around resolving for an OS that's going to be unsupported in a few months...
Using https://bootstrap.pypa.io/2.7/get-pip.py instead. Fixes it.


[A song to Fire & Ice] Add "data-i18n" tags to the sheet

@Fraetor & @ajott
I'd like to do a French translation of the "A song of ice & fire" character sheet.
Actually, the html file doesn't include any "date-i18n" tags, so I can create a "translation.json" file nor than a "fr.json" file.
https://github.com/Roll20/roll20-character-sheets/blob/master/A Song of Ice and Fire/SIFRPNew.html
Would it be possible for you to edit the original html file so I can do the translation ?
Thank you very much

Hi,
A translation would be great, however I am not actually very experienced in HTML, and have previously only tweaked the dice logic on this sheet, which doesn't require anything fancy. As such I am unsure quite how I would go about readying the sheet for translation.

Thank you for the anwser @Fraetor
So is @ajott the main author of the sheet ?

According to the commit history, the sheet was originally written by @raulhess with major changes subsequently by @CoalPoweredPuppet.

Perhaps @Anduh and his script can help...

I'm willing to take a run at this.

I can run my script at this and see what the results are.

@Anduh please do, and tell us the results ^^

If be happy to review it following the script (new here so unsure what the
script accomplishes but probably similar to my regex search)
On Tue, May 12, 2020, 11:53 AM Gregb342<EMAIL_ADDRESS>wrote:

@Anduh https://github.com/Anduh please do, and tell us the results ^^
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Roll20/roll20-character-sheets/issues/6090#issuecomment-627528097,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGQ24T5U3SQ2ANFQPFKHMDLRRGLL7ANCNFSM4L4GHARQ
.

Hi everyone,
I just push a request to add a army sheet layer to the character sheet.
Next step, i plan to add "data-i18n" tags to the sheet and a french translation. (in 1 ou 2 weeks).

Hi @Baledin @Gregb342 @Fraetor ,
Today, i just push a update of the character sheet that integrate the translation support.
#6492

Hi Everyone,
Translation was merged to the character sheet.
French Translate (my native language and based on the french version of the RPG book) will be available in the next merge #6514, be enjoy to translate to other language.
@Anduh : I think this issued can be mark as solve after the next merge. :-)


Monitor job via Unity.py or Unity.js

jobs in 23.1 are always Workflows, not individual PGE/algorithms
for this ticket, you can monitor the Workflow as a box (not see per-step)
"should" not need to change vs. monitor any other type of job at this level of abstraction

jobs in 23.1 are always Workflows, not individual PGE/algorithmsim

@anilnatha is this already done in 23.1?


The LoadBalancerIPPool ignores base and broadcast for IPv4 for BGP announcements

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
Testing out the new LB-IPAM with the BGP control-plane.
Only thing is that the routes are service IP routed by BGP via a /32 and don't need to skip the base or broadcast for ipv4.
After requesting a wrong address with annotations io.cilium/lb-ipam-ips and a label selector and receives a load balancer ip from the wrong pool and the operator log is spammed with:
level=error msg="Unable to allocate IP" error="provided IP is not in the valid range. The range of valid IPs is 2001:db8:262f:1337:1337::/125" subsys=lbipam
level=error msg="Unable to allocate IP" error="provided IP is not in the valid range. The range of valid IPs is 2001:db8:262f:1337:1337::/125" subsys=lbipam
level=error msg="pool upsert failed" error="handlePoolModified: revalidateAllServices: revalidate: stripOrImportIngresses: Error while attempting to allocate IP '<IP_ADDRESS>'" subsys=lbipam
level=error msg="Unable to allocate IP" error="provided IP is not in the valid range. The range of valid IPs is 2001:db8:262f:1337:1337::/125" subsys=lbipam
level=error msg="pool upsert failed" error="handlePoolModified: revalidateAllServices: revalidate: stripOrImportIngresses: Error while attempting to allocate IP '<IP_ADDRESS>'" subsys=lbipam
level=error msg="Unable to allocate IP" error="provided IP is not in the valid range. The range of valid IPs is 2001:db8:1337:1337:1337::/125" subsys=lbipam
level=error msg="pool upsert failed" error="handlePoolModified: revalidateAllServices: revalidate: stripOrImportIngresses: Error while attempting to allocate IP '<IP_ADDRESS>'" subsys=lbipam

Cilium Version
Client: 1.13.0-rc4 8602409b 2022-12-23T11:31:53+13:00 go version go1.19.3 linux/amd64
Daemon: 1.13.0-rc4 8602409b 2022-12-23T11:31:53+13:00 go version go1.19.3 linux/amd64
Kernel Version
Linux arend 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux
Kubernetes Version
Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.6", GitCommit:"ff2c119726cc1f8926fb0585c74b25921e866a28", GitTreeState:"clean", BuildDate:"2023-01-18T19:15:26Z", GoVersion:"go1.19.5", Compiler:"gc", Platform:"linux/amd64"}
Sysdump
No response
Relevant log output
apiVersion: v1
items:
- apiVersion: cilium.io/v2alpha1
  kind: CiliumLoadBalancerIPPool
  metadata:
    creationTimestamp: "2023-01-23T17:53:26Z"
    generation: 2
    labels:
      kustomize.toolkit.fluxcd.io/name: cilium
      kustomize.toolkit.fluxcd.io/namespace: flux-system
    name: internal-pool
    resourceVersion: "50362378"
    uid: dc5e75b8-4330-41ab-97b2-8b4d54dec0a0
  spec:
    cidrs:
    - cidr: <IP_ADDRESS>/27
    - cidr: 2001:db8:1337:1337:1337::/123
    disabled: false
    serviceSelector:
      matchLabels:
        pool: internal
  status:
    conditions:
    - lastTransitionTime: "2023-01-23T17:53:26Z"
      message: ""
      observedGeneration: 1
      reason: resolved
      status: "False"
      type: io.cilium/conflict
    - lastTransitionTime: "2023-01-23T17:55:14Z"
      message: "60"
      observedGeneration: 2
      reason: noreason
      status: Unknown
      type: io.cilium/ips-total
    - lastTransitionTime: "2023-01-23T17:55:14Z"
      message: "60"
      observedGeneration: 2
      reason: noreason
      status: Unknown
      type: io.cilium/ips-available
    - lastTransitionTime: "2023-01-23T17:55:14Z"
      message: "0"
      observedGeneration: 2
      reason: noreason
      status: Unknown
      type: io.cilium/ips-used
- apiVersion: cilium.io/v2alpha1
  kind: CiliumLoadBalancerIPPool
  metadata:
    creationTimestamp: "2023-01-23T17:53:26Z"
    generation: 10
    labels:
      kustomize.toolkit.fluxcd.io/name: cilium
      kustomize.toolkit.fluxcd.io/namespace: flux-system
    name: public-pool
    resourceVersion: "50471420"
    uid: 7e58e600-4654-4c34-b740-fe4391d485c0
  spec:
    cidrs:
    - cidr: <IP_ADDRESS>/29
    - cidr: 2001:db8:1337:1337:1337::/125
    disabled: false
    serviceSelector:
      matchLabels:
        pool: public
  status:
    conditions:
    - lastTransitionTime: "2023-01-23T17:53:26Z"
      message: ""
      observedGeneration: 1
      reason: resolved
      status: "False"
      type: io.cilium/conflict
    - lastTransitionTime: "2023-01-23T18:07:25Z"
      message: "0"
      observedGeneration: 7
      reason: noreason
      status: Unknown
      type: io.cilium/ips-used
    - lastTransitionTime: "2023-01-23T18:59:47Z"
      message: "92424"
      observedGeneration: 8
      reason: noreason
      status: Unknown
      type: io.cilium/ips-available
    - lastTransitionTime: "2023-01-23T19:18:14Z"
      message: "125640"
      observedGeneration: 10
      reason: noreason
      status: Unknown
      type: io.cilium/ips-total
kind: List
metadata:
  resourceVersion: ""

Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Cc @dylandreimerink

Sorry, this issue has somehow slipped by be in the past. This is a known limitation of the current LB-IPAM implementation. This has been discussed in more detail here #24351 so I would like to close this issue in favor of the other discussion.


bug: error "is not a relative path" changing answers_file path

Working with Windows 10 updated to last patch an copier v6 installed from git repo master (need fix for #520).
I'm still testing copier behavior and i want to keep answers file separated from created project. I want to be able to delete project dir and recreate the test project without being asked again all the questions.
But trying to change answers file path i get this error:
pydantic.error_wrappers.ValidationError: 1 validation error for Worker
answers_file
  "C:\home\prjHome\templates\templates-build\gg-py-package-template-test\.copier-answers.yml" is not a relative path (type=value_error.path.not_relative; path=C:\home\prjHome\templates\templates-build\gg-py-package-template-test\.copier-answers.yml)

I couldn't find anywhere in the doc that answers file path must be relative to something. (By the way, relative to what?

Forgot to add how copier it is called.
For the above error copier is called by a win batch file:
:: testing prj build with copier
set CURDIR=%~dp0
call workon copier
call copier -a %CURDIR%\.copier-answers.yml copy %CURDIR%\..\..\gg-py-package-template %CURDIR%\..\work\template-test
call deactivate

.copier-answers.yml is in the same dir as the batch file.
If I change the batch to use a relative file as follows:
:: testing prj build with copier
set CURDIR=%~dp0
pushd  %CURDIR%
call workon copier
call copier -a .\.copier-answers.yml copy ..\..\gg-py-package-template ..\work\template-test
call deactivate
popd

the answers file is simply ignored and I'm prompted again for answers with the default values.

It works doing a weird thing like this
:: testing prj build with copier
call workon copier
call copier -a ..\..\gg-py-package-template-test\.copier-answers.yml copy
    C:\home\prjHome\templates\gg-py-package-template
    C:\home\prjHome\templates\templates-build\work\template-test
call deactivate

but again, why i have to use an answers file path relative to the destination dir, while it is in the same directory as the script?
Could you explain please?
Thanks

👋 welcome to copier!
It has to be relative because its value is available at render time, and used to put that file. Also because it's used to update projects, and for that a project must be git-tracked, thus the file must be in the repo anyway.
Closing, as this seems more a question than an issue.


Adds more unit test for keys.go

Adds more unit test for keys.go
Signed-off-by: Pritesh Bandi<EMAIL_ADDRESS>

Codecov Report

Merging #268 (5dc299e) into main (510def1) will increase coverage by 4.03%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main     #268      +/-   ##
==========================================
+ Coverage   69.56%   73.59%   +4.03%
==========================================
  Files          23       23
  Lines        1909     1909
==========================================
+ Hits         1328     1405      +77
+ Misses        483      405      -78
- Partials       98       99       +1

Impacted Files
Coverage Δ

config/keys.go
71.89% <0.00%> (+50.32%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Ignore certain containers?

I have one container that no longer has a public image available and it crashes when parsing that container.
Is there a way to tell the script to skip a specific container?
Thanks.

I agree with ignoring certain containter feature - can it be added?