Track onFailure for websocket and check if websocket connection is alive

Hi ,

how can I check if my websocket connection is open/running ?

I wonder if the openEvent,closingEvent and FailureEvent variables can return a value other than null ? I would like to know why my websocket is failing sometimes.
      onOpenCallbackMarket = openEvent -> {

     };
      onMessageCallbackMarket = (message) -> {

    };
     onClosingCallbackMarket = closingEvent -> {

     };
     onFailureCallbackMarket = failureEvent -> {

    };

https://github.com/binance/binance-connector-java/blob/master/src/test/java/examples/websocket/TradeStreamWithAllCallbacks.java
You can take a look at this example file. It handles callbacks from websocket.

@chairz  it just restarts the websocket. Is it possible to get a message why it failed ?

@naserkaka I have proposed a PR about this idea, without knowing you had asked for. Maybe you can review it and see if it fits your needs.

Hi @Hazard4U , this will help a lot , now I can catch the error for failureOnCallback  and see more detailed information why it failed. This was needed, thanks!

so this is how I can catch the message in onFailure ? for now.
 onFailureCallbackMarketDataUser = (message) -> {
                logger.error("onFailureCallback() message:" + message);
            };

Hi @naserkaka, happy to say we've merged @Hazard4U 's PR along with some other adjustments to make callbacks pass the original data to the user.
It's available now at newly released 3.0.0rc2 and an example can be consulted at src/test/java/examples/websocketstream/TradeStreamWithAllCallbacks.java. Pls have a try.
This being said, we're closing this issue. Thx.


BitMex spot connector

Why
The rationale behind this user story.
What
Define or outline the task(s) that needs to be done.
Definition of Done
Condition(s) or requirement(s) to be satisfied to mark this story as completed.

Bitmex spot connector has been added


Possibly unhandled rejection

when upload was error i have got this error:
Possibly unhandled rejection: {"data":"
The upload path does not appear to be valid.
","status":401,"config":{"method":"POST","transformRequest":[null],"transformResponse":[null],"jsonpCallbackParam":"callback","url":"http://localhost:8080/upload","data":{"file":{"$ngfBlobUrl":"blob:http://localhost:8080/92a870df-21ce-4616-91e5-0e59b529cf3a","$ngfWidth":425,"$ngfHeight":425,"upload":{},"progress":100}},"_isDigested":true,"_chunkSize":null,"headers":{"Accept":"application/json, text/plain, */*"},"_deferred":{"promise":"..."}},"statusText":"File Upload Error"}
how can i fix ?

I have the same error while uploading big files.
Did you find any solution ?

Same here, I don't like the workaround as this error on the console is useful on our own code. ngFileUpload should handle its promises properly so when I use
Upload.upload({
                    url: 'some/url',
                    data: {file: image, model: imageInfo}
                }).then(function () {
                    //code on success
                }, function (error) {
                    //code on error
                });

no error should be thrown.

$scope.uploadFiles = function(file) { 		$scope.attach = file; 	    file.upload = Upload.upload({ 	        url: 'sendemail', 	        data: {file: file}  	    }); 		console.log($scope.attach);     }
Anyone can help me with same error? How can I fix it?

For what it's worth :
I've been digging around in Upload.upload's source code and found out this:
https://github.com/danialfarid/ng-file-upload/blob/d911c553d0c1be76276a3b50ad5e3e8345c91747/src/upload.js#L153-L165
This is the deffered's promise that is returned when calling Upload.upload, so using either:
Upload.upload({
   ...
}).then(function success() {
   ...
}, function error() {
   ...
})

Or
Upload.upload({
   ...
}).success(function success() {
   ...
}).error(function error() {
   ...
})

Should work.

@Eregrith It actually doesn't work--I tried implementing both rejection and catch, but neither squashes the error.  I'm creating a PR now, but can't tell how to build the project since the author didn't include instructions.  Hopefully he'll respond decently quickly since this is a bit of a pain and shouldn't warrant us squashing all unhandled promise rejections since we track and fix them as a matter of best practice.

Actually nevermind, it's old enough to be using grunt, got it built :-)


ytwatchlater extractor fails to collect ids: "Your browser is deprecated. Please upgrade."

Using the ytwatchlater extractor, sign-in is successful as per usual, but trying to get the watch later playlist results in a page with only a warning, with no video links.

It works for me, please post the full output you get when running youtube-dl --verbose URL OTHER_OPTIONS.

$ youtube-dl --verbose :ytwatchlater
[debug] System config: []
[debug] User config: ['--add-metadata', '-f', 'bestvideo[ext=mp4][width<=1920]+bestaudio[ext=m4a]', '-o', '%(title)s.%(ext)s', '-nck']
[debug] Command-line args: [u'--verbose', u':ytwatchlater']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.03.24
[debug] Python version 2.7.8 - Linux-3.16.0-33-generic-x86_64-with-Ubuntu-14.10-utopic
[debug] exe versions: avconv 11-6, avprobe 11-6, ffmpeg 2.5.git, ffprobe 2.5.git
[debug] Proxy map: {'all': 'socks://localhost:1234/', 'socks': 'socks://localhost:1234/', 'no': 'localhost,<IP_ADDRESS>/8,::1,nmmu.ac.za,.tenet.co.za'}
[youtube:watch_later] Downloading login page
[youtube:watch_later] Logging in
[youtube:watch_later] watch_later feed: Downloading page 1
[download] Downloading playlist: Youtube Watch Later
[youtube:watch_later] playlist Youtube Watch Later: Collected 0 video ids (downloading 0 of them)

An update released today seems to have fixed this issue. This was still persistent in the previous update. This is no longer the case.


[Bug]: Horizontal Scroll in Light Mode

Give a brief about the bug ✍
On changing to light mode, we get a horizontal scroll, although there is not extra content to view by scrolling.
What is the expected behavior? 🤔
No horizontal scroll is expected.
Provide step by step information reproduce the bug 📄
The bug can be fixed by adding removing overflow in x direction. I would also like to change the light mode background to a softer color which is better to look at.

Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hey @rahul-p19 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Reduce usage of GetDevice() API in Android controller

Problem
Android Controller code needs update to remove usage of GetDevice() API.
Change overview

Use GetPeerAddressAndPort() to get device's address
Use ReleaseDeviceById() to disconnect the device.
Remaining usage of GetDevice() have been removed in #10590

Testing
Run existing CI tests to ensure that the controller behavior is intact.

Can you patch in this commit to fix the CI?
austinh0@0be80e7

Just saw this message. I have pushed a commit similar to what you mentioned in your comment. I'll pull in your commit as well to take care of the rest.


Support other filesystem types

Resolves https://github.com/metal-stack/csi-driver-lvm/issues/13
For example xfs added

I added the @mwennrich as reviewer as well, lets wait for his approval

first #78 must be merged, to make CI pass.

Can you please add a bats (in tests/bats ) to test with xfs as well

Due testing I found an Issue with old volumes signatures.
If we create volume where another volume had been before, blkid returns xfs_external_log type. So I added force formatting in this case.

You must silent this warning:
G204: Subprocess launched with a potential tainted input or cmd arguments (gosec)

@majst01 help with failed pipeline, please.

@majst01 help with failed pipeline, please.

This is because you PRs from outside are not able to log in into our registry for push.
From my side this is fine now !

When this feature will be released?

We made a release now and container images are also published on ghcr. You can use this deployment chart as well if you want: https://github.com/metal-stack/helm-charts/releases/tag/v0.3.27
Thanks for your contribution!


[Multi-Actions] Figure out generic action configurations

Reference: https://www.notion.so/dust-tt/Multi-Actions-Technical-Proposal-662aa8afbc584f4285d89becc0a6417b
This one requires a bit of framing
The shared action configurations fields are:

description
force_use_at_iteration

Maybe max_uses_per_run, min_uses_per_run
We need to figure out where we will store that. I presume the simplest is that it will exist on all action configuration models.
As part of this, add these new fields to all existing action configuration (including generation)
Figure out what are the invariants in naming that cover existing actions, generation and future one. What are the base classes in code? BaseActionResource likely?

TLDR:

just adding force_use_at_iteration for now

It's the only one we really for backward compatibility. We'll def want description later on. Possibly max_uses_per_run and min_uses_per_run 👍

👍


Detailed Vehicle Info - items disappeared after reinstall of AAIdrive app

Hi everyone.
Long time lurker, first time posting.
In the last month I had a connection problem with my 2019 F31 with iDrive5 and had to uninstall and reinstall the app. Clearing data somehow didn't fix the problem.
I reinstalled the app and noticed that some entries from the iDrive5 "Detailed vehicle info" menu went missing. I'm not sure exactly what it was but I remember I had and entry named "Windows" where it showed all of my windows status and also roof window, how much % was it open, if it was tilted etc.
Also in the Driving details entry which I still have, there were more data entries, for example it showed the mode of the automatic transmission if it was Coupled, Uncoupled, Coasting, etc.
All of these entries are gone I cannot bring them back. I don't know what I did the first time I installed the app a year or more ago.
Is there an addon I must install, a mod somewhere or was it simply removed from the app between updates?

Those extra options are enabled if you enable Show Advanced Settings under the Settings tab. This way I don't need to have all those strings translated, since I'm unsure what half of the car data means :)


doc: Make it clear that the example config is the default

The way the README is written, it sounds like you need to use the provided cache configuration table before you can require('impatient').
This PR changes the README in two ways:

It clarifies that the config block given is the default
It spells out that all that's required is just require('impatient')

Meant to mention, looking through the old issues, I see I'm not the only one who got tripped up by this (#65)

Thanks!


The deployment procedure of downloading a .bot file to overwrite my local .bot file is counter-intuitive

Following the deployment guidance here, I am instructed to create a bot in Azure, then download the .bot file from it to overwrite my local one. But I already have a bot locally, I also already have a .bot file in this local bot. Why am I having to create a .bot file out on the portal then download that and stamp it over top? This feels unnatural and unnecessary. I should simply be able to push the bot I've created & tested locally out to the service on which I wish to host it.

There will be an update to the Azure portal that will stop using .bot files, as this is our model moving forward, starting with 4.3.  The applications settings that currently live in .bot files will not moved into appsettings.json or .env files for C# and JS respectively

@sgellock can you check your last sentence there? Not sure if that's supposed to be "will get moved" or "will not be moved" :) thanks!

@brandonh-msft thanks for calling that out.  I've updated my grammatical errors.  TL;DR:  .bot files are not what we are recommending you use for application configuration settings.  some customers find value in the .bot file, and for those customers that do, then they option exists.  but for the large majority of customer feedback we've gotten, language/platform existing mechanism are expected and preferred.  e.g. appsettings.json and .env files


[EPMUII-8315]. Make it possible to set default rendering mode

Please fix failed unit tests

Please fix failed unit tests
Fixed


AttributeError: '_socketobject' object has no attribute 'send_json'

as titled

For anyone who stumbles upon this, this issue happens when you assign the .bind() or .connect() to a variable. ex
sock = ctx.socket(...)
x = sock.connect()
x.send_json(...)


Update UtilsApi.md

The configuration object is missing in line 38. It should be a parameter for ApiClient.

To fix this issue, we've updated the client's templates and regenerated it.


Added DOCKER_OPTIONS environment variable

Fixes pires/kubernetes-vagrant-coreos-cluster#129
The name of the variable is DOCKER_OPTIONS instead of DOCKER_OPTS so it won't collide with users local environment settings.

@tcichowicz amazing job! Thank you :)

No problem, glad to be of help ;)


Double/Incorrect Transformations

Describe the bug
When attempting to translate/move the BPGaussianActor in the scene, the Niagara particles will double-transform and if the object is rotated, the particles will transform on the incorrect axis when moved.
To Reproduce
Steps to reproduce the behavior:

Load a .ply into the workspace and drag blueprint into scene
Switch view to orthographic front/side view
Translate the blueprint up and down with the manipulator tool
notice the particles are moving 2x as fast as the manipulator tool
reset position to 0, and rotate the blueprint 90 degrees on the Y axis
Translate the blue print up and down in world space
notice the actor is moving on multiple axis'

Expected behavior
The niagara particles should be inheriting the precise location of the root component, and not drift away from it when transforming the actor.
Desktop (please complete the following information):

OS: Win10
UE Version: 5.3.2

Additional context
I could be wrong, but perhaps this has to do with a problem converting local transforms to world space?

Thanks for your feedback, we have verified this bug, we will fix it in the next submission.

Hello, we have resolved this issue in the v1.1.0 version. Feel free to give it a try.


Removing default fonts is unclear

Describe the bug
I'm attempting to use the bundled MJML file inside of providers like PostMark, but they do not allow <link /> tags, which is inserted by default with the core fonts; such as <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700" rel="stylesheet" type="text/css">. Using the CLI, I've tried:

mjml --config.fonts {} ./src/*.mjml -o ./build/
mjml --config.fonts null ./src/*.mjml -o ./build/
mjml --config.fonts false ./src/*.mjml -o ./build/

With all 3 resulting in things like:
<link href="{" rel="stylesheet" type="text/css">
<link href="}" rel="stylesheet" type="text/css">

What's odd is that it doesn't ALWAYS do this with the empty object, but it does sometimes... a bit stumped here on how to remove those defaults. Is there a reason to keep them by the way? Shouldn't we default to a more standard system-stack, like -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji?
To Reproduce
Steps to reproduce the behavior:

☝

Expected behavior
No custom fonts should be rendered.
MJML environment (please complete the following information):

OS: MacOS
MJML Version 4.5.1
MJML tool used cli

Email sending environment(for rendering issues):

Platform used to send the email PostMark

Can you try with mjml --config.fonts={} ./src/*.mjml -o ./build/ ?

👋 When running mjml --config.fonts={} ./src/*.mjml -o ./build/ that seemed to work fine, but when using the -w command, it does not mjml --config.fonts={} -w ./src/*.mjml -o ./build and adds those brackets inline:
      <!--[if !mso]><!-->
        <link href="{" rel="stylesheet" type="text/css">
<link href="}" rel="stylesheet" type="text/css">
        <style type="text/css">
          @import url({);
@import url(});
        </style>
      <!--<![endif]-->

Yup the watch command doesn't pass options correctly it should be fixed in the next release

Ah gotcha! Any pending work to be done before the next version is released?

A few merge, but it should be out monday

Sounds great, appreciate the quick replies as always. Happy to close this one, unless you think it's a good idea to keep open until this issue is resolved in master to help anyone else that comes across this issue.

Sure ! We'll close it when it's released

It should be good now ! I'm closing :)

Thanks works perfectly!


Migrate to Official Python Atlas Client

Signed-off-by: verdan<EMAIL_ADDRESS>Atlas community recently released an official python client to interact with Apache Atlas. For now, we are relying on our custom client, which does not have all the endpoints implemented yet.

@verdan lgtm! I think it is mostly up to you to decide:

% of feature parity between your client and atlas official one.
if we want to contribute back atlas python client, how often they do python release considering it is from an Apache project.

We do have a few helper functions we added in our version of client, which will be missing in the official client. But those are mostly for the Amundsen, and we will move them to amundsen repos.

if we want to contribute back atlas python client, how often they do python release considering it is from an Apache project.

This is my main concern, as the Atlas community is sometimes slow in releasing new versions. However the good thing is that the first version is shipped with all the existing endpoints, so this is already better then the one we are using. 😄

I found several bugs in the official client. Not even in a mood to create "Given-when-then-but" fashion of bug reports for those.
We need to ensure the client is stable enough before migrating.

@mgorsk1 @pPanda-beta We need to decide how we want to proceed with this. I already have the working implementation of the Atlas Proxy using the official client. All the code to Atlas is already upstreamed. As Palash mentioned it's a bit tricky with not having any test cases at all. On the other hand, the investment to rewrite our test cases in Amundsen atlas proxy is already a huge investment of time.
So we need to decide if we really want to do this without the proper test cases in the official atlas package.

I'd expect that this rfc always assumed tests need to be refactored for new client. Couldn't be avoided I guess and I think we would be fine just having tests on our side.

True, and also the missing endpoints in pyatlasclient also needs to be implemented which is again a separate effort (because of the complex structure of pyatlaslient) if we stick with the current implementation.
@pPanda-beta do you agree on using the official client then, and moving our implementation effort away from the pyatlasclient?

Another question is - will rewriting/refactoring tests make it possible to use them in the official client too ?

Another question is - will rewriting/refactoring tests make it possible to use them in the official client too?

Nope. We'll be writing unit tests of our functions assuming the methods of the official client are returning everything correctly by mocking them.

reviving this one as we don't want it to become blocker for upcoming features (i think tag/badge refactor is blocked by this)
cc @verdan @pPanda-beta

Can this be merged at this point, or does it need to go through a vote? It seems like https://github.com/amundsen-io/amundsenmetadatalibrary/pull/247 is pretty close to getting over the line


Noanim doesn't work

The noanim window rule simply doesn't work. I have tried the hyprland-bin from the AUR and the hyprland-git from the AUR, which both seem to be version 0.15.1Beta. Red bar at the top saying my config is broken and the feature doesn't work either.

config line pls, pretty sure it does

hyprland-config.txt

the rule is a comment...
it works, just tested with kitty.

I know it's a comment. I am not going to deal with that red message the entire time. It didn't work on my system, despite having the proper version...

check your hyprctl version


Add Compiler option -D_DISABLE_EXTENDED_ALIGNED to disable error C2338

cartographer and mongo-cxx-driver failed with error C2338, it should fix form the error message provides the instructions that add -D_DISABLE_EXTENDED_ALIGNED option to disable this error.
Delete the useless 'static.patch' in mongo-cxx-driver because it did not applied anymore(it did not apply in previous).

Looks good, thanks!


Enhance input validation in sampling script

This update introduces input validation for the command-line arguments to ensure that all necessary files are provided and accessible, preventing runtime errors and enhancing user experience.

Hi @mandlinsarah,
Looks like this change encounters the error: 'ValueError: Checkpoint file not found: /content/gemma/2b/' , if i tried to provide the correct model checkpoint and tokenizer paths. Could you please review your modified code again for all cases.
Please refer to this gist file.
Thank you.


Add admission webhooks for ServiceBinding resource

Define validation and mutating webhooks for the ServiceBinding resource.
Validation is currently limited to existance/absense of certain fields.
Over time we can add more robust validation of field content.
Signed-off-by: Scott Andrews<EMAIL_ADDRESS>

I'm intentionally holding off on adding webhooks for the ClusterWorkloadResourceMapping until #41 merges.

Codecov Report

Merging #51 (30c0762) into main (2ae9ff3) will increase coverage by 28.82%.
The diff coverage is 92.98%.

:exclamation: Current head 30c0762 differs from pull request most recent head 2131860. Consider uploading reports for the commit 2131860 to get more accurate results

@@            Coverage Diff             @@
##            main      #51       +/-   ##
==========================================
+ Coverage   2.16%   30.99%   +28.82%
==========================================
  Files          4        5        +1
  Lines        185      242       +57
==========================================
+ Hits           4       75       +71
+ Misses       181      161       -20
- Partials       0        6        +6

Impacted Files
Coverage Δ

apis/v1alpha3/zz_generated.deepcopy.go
10.40% <ø> (+10.40%)
:arrow_up:

apis/v1alpha3/servicebinding_webhook.go
92.98% <92.98%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2ae9ff3...2131860. Read the comment docs.


Flaky-test:  PulsarStateTest.testPythonWordCountFunction

When running tests in Github CI, this exception occasionally occurs:
org.apache.pulsar.tests.integration.functions.PulsarStateTest
  -     org.apache.pulsar.tests.integration.functions.PulsarStateTest.pulsar-standalone-suite
  -     PulsarStateTest.testPythonWordCountFunction
         -     which gave: PulsarStateTest.testPythonWordCountFunction:78->publishAndConsumeMessages:410 » ThreadTimeout

Interestingly, line 410 of publishAndConsumeMessages is the first line of this block:
@Cleanup Producer<byte[]> producer = client.newProducer(Schema.BYTES)
    .topic(inputTopic)
    .create();

This issue was first mentioned here: https://github.com/apache/pulsar/issues/6137

Here's a log that includes this test:
11_run integration tests.txt

The scenario appears after two years. affect master, branch-2.10, branch-2.9...
FYI:
https://github.com/apache/pulsar/pull/15801
https://github.com/apache/pulsar/pull/15757
https://github.com/apache/pulsar/runs/6602813932?check_suite_focus=true
https://github.com/apache/pulsar/runs/6602339258?check_suite_focus=true

Also, it has failed on my PR https://github.com/apache/pulsar/pull/15571/ many times recently.
https://github.com/apache/pulsar/runs/6608041290?check_suite_focus=true

The test is recovered.

It's back https://github.com/apache/pulsar/runs/6652119261?check_suite_focus=true

Closed as stale and no new reports for several months. Please open a new issue if it's still relevant to the maintained versions.


feature: add concurrency to the GitHub Actions

Feature Description
The GitHub Actions do not have concurrency enabled, resulting in many redundant GitHub Actions running for the same change and not relevant notification of failed actions. See screenshot

Ideally, when a commit is ammended or a PR is updated, there must be only one CI job running for a particular check/build.
Proposed Solution
Add a concurrency option to GitHub Actions, see here for reference: https://docs.github.com/en/actions/using-jobs/using-concurrency
Alternative Solutions
No response
Want to contribute?

[X] I would like to work on this issue.

Additional Context
No response

/assign


tictactoe.sl bug

moveMadeIn := b_[2]; // why is this new line here?
https://github.com/vuphan314/led/commit/2c7716ce943aafab192e10dc5306fad3c0cbdb98

fixed at
https://github.com/vuphan314/led/commit/0f066ea300ddbc258d15c355482edcf7eedf28a9


python313: 3.13.0rc2 -> 3.13.0rc3

https://docs.python.org/3.13/whatsnew/changelog.html#python-3-13-0rc3

Things done

Built on platform(s)

[x] x86_64-linux (including freethreading)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 345809 run on x86_64-linux 1

6 packages built:

python313
python313.debug
python313FreeThreading
python313FreeThreading.debug
python313Full
python313Full.debug

Result of nixpkgs-review pr 345809 run on aarch64-darwin 1

3 packages built:

python313
python313FreeThreading
python313Full


⚠ ClamAV has degraded performance

In 3072d98, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 79 ms

Resolved: ClamAV performance has improved in ce68bb9.


gn broken with /\zs

Hello
I have noticed that using gn is broken when the search pattern contains \zs. Take the folling file:
function! TestMatch1()
	echom "Change me to single quotes"
endfunction

function! TestIgnore1()
	echom "\<lt>Leave me as double quotes> "
endfunction

function! TestMatch2()
	echom "Change me to single quotes"
endfunction

function! TestMatch3()
	echom "Change me to single quotes"
endfunction

function! TestMatch4()
	echom "Change me to single quotes"
endfunction

function! TestIgnore2()
	echom "\<lt>Leave me as double quotes> "
endfunction

function! TestMatch5()
	echom "Change me to single quotes"
endfunction

Paste the above code into a buffer and run :setf vim. Now search for this:

/\v^function.\s+TestMatch\d+\(\)\n.*\zs".*"$

You should see that it highlights only the double quotes following a function that matches TestMatch\d\+.
HOWEVER, if you type gn it will match from the start of first closest match to the end of the second closest match.

Mandatory Pics
Shows search for /\v^function.\s+TestMatch\d+\(\)\n.*\zs".*"$

Shows what happens after gn pressed

Use Case and Thanks
I was trying to use :global combined with a search that used \zs in order to surround patterns with [, ] using tpope's vim-surround by doing something like ysgn[ but because of this bug, I was unable to achieve this and had to use a work-around.
Thanks,
dylnmc

That is a limitation of how to handle a multi-line regex in combination with \zs. Basically what gn does is this:

It searches backwards for the last match of the current regular expression.

It searches forward for the next match of the current regular expression.

This should make clear, that the cursor will be on start of the next match, even if it was there already at the start of 1). Finally

it searches for the end of the current regular expression. and puts the cursor there.

So in Vimscript, it does this:
let pat=`your pattern here`
call search(pat, 'b')
call search(pat, '')
cal search(pat, 'ce')

If you do this with your multi-line pattern, you will receive the same selection.
And it is clear, that it won't work as you expected it, since at step 3, vim will search for the next line starting with function. So it will correctly got to line 11 instead on staying on the same line.
I think this is the expected behaviour of gn considering on how it works.

Maybe this is not the only approach, because the search highlighting works correctly ... (?).

@chrisbra If you consider how you might make a text object that has a similar objective, then it seems more reasonable to:

search until the end of the next match (eg, with search() using the e flag or something similar)
search until the beginning of the match (eg, with search() using the b and c flags)

Is that an option for gn (and vice versa for gN)?
Thanks for looking into it,
dylnmc

Would it make sense to do something similar for :global?
vim9script
new
['aaa', 'bbbccc', '']->repeat(3)->setline(1)
global/aaa\nbbb\zsccc$/delete

Expected: only these lines remain:
aaa
aaa
aaa

Actual: only these lines remain:
bbbccc
bbbccc
bbbccc

Using \@<= instead of \zs fixes the issue:
\%(aaa\nbbb\)\@<=ccc$
^^^        ^----^

Test:
vim9script
new
['aaa', 'bbbccc', '']->repeat(3)->setline(1)
global/\%(aaa\nbbb\)\@<=ccc$/delete

But \@<= can't backtrack too much.  From :help \@<=:

But to limit the time needed, only the line where what follows matches
is searched, and one line before that (if there is one).

If it's not possible to change the behavior this late, maybe we could document the pitfall.  I couldn't find anything relevant at :help :global.  The help does say:

(for a multi-line pattern, only the start of the match matters).

But in the first example, the start of the match is ccc as specified by \zs.  So one could assume that :global would mark and delete the bbbccc lines, not the aaa lines.
Either the help means "only the start of the pattern matters":
diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt
index 56e9ad82f..b571d3ecc 100644
--- a/runtime/doc/repeat.txt
+++ b/runtime/doc/repeat.txt
@@ -76,7 +76,7 @@ examples.

 The global commands work by first scanning through the [range] lines and
 marking each line where a match occurs (for a multi-line pattern, only the
-start of the match matters).
+start of the pattern matters).
 In a second scan the [cmd] is executed for each marked line, as if the cursor
 was in that line.  For ":v" and ":g!" the command is executed for each not
 marked line.  If a line is deleted its mark disappears.

Or we should mention that an exception is made for \zs:
diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt
index 56e9ad82f..02d4dc0dd 100644
--- a/runtime/doc/repeat.txt
+++ b/runtime/doc/repeat.txt
@@ -75,8 +75,9 @@ NOTE [cmd] may contain a range; see |collapse| and |edit-paragraph-join| for
 examples.

 The global commands work by first scanning through the [range] lines and
-marking each line where a match occurs (for a multi-line pattern, only the
-start of the match matters).
+marking each line where a match occurs.  For a multi-line pattern, only the
+start of the match matters; however, if the pattern uses |/\zs| to match after
+the first line, the latter is marked (not the line where "\zs" matches).
 In a second scan the [cmd] is executed for each marked line, as if the cursor
 was in that line.  For ":v" and ":g!" the command is executed for each not
 marked line.  If a line is deleted its mark disappears.

Would it make sense to do something similar for :global?
vim9script
new
['aaa', 'bbbccc', '']->repeat(3)->setline(1)
global/aaa\nbbb\zsccc$/delete

Expected: only these lines remain:
aaa
aaa
aaa

Actual: only these lines remain:
bbbccc
bbbccc
bbbccc

Well, I would not call that "similar", since the previous issue was
about the end of the match.  This is about the start of the match, when
it was set with \zs.

Using \@<= instead of \zs fixes the issue:
\%(aaa\nbbb\)\@<=ccc$
^^^        ^----^

Test:
vim9script
new
['aaa', 'bbbccc', '']->repeat(3)->setline(1)
global/\%(aaa\nbbb\)\@<=ccc$/delete

But \@<= can't backtrack too much.  From :help \@<=:

But to limit the time needed, only the line where what follows matches
is searched, and one line before that (if there is one).

It would work in many cases though, like in this example.  But not
when the part before \zs matches more than one line.

If it's not possible to change the behavior this late,

I looked into changing this, and it's not too difficult.  However, the
behavior is strange.  The pattern is tried for every line in the global
range, and when it matches it might set the mark for another line.  This
may actually be outside of the range.  Is the mark still set then?
It would not be backwards compatible, but who would use \zs with :global
right now, since it has no effect?  So it might not matter.

maybe we could document the pitfall.  I couldn't find anything
relevant at :help :global.  The help
does say:

(for a multi-line pattern, only the start of the match matters).

But in the first example, the start of the match is ccc as specified by \zs.  So one could assume that :global would mark and delete the bbbccc lines, not the aaa lines.
Either the help means "only the start of the pattern matters":
diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt
index 56e9ad82f..b571d3ecc 100644
--- a/runtime/doc/repeat.txt
+++ b/runtime/doc/repeat.txt
@@ -76,7 +76,7 @@ examples.

 The global commands work by first scanning through the [range] lines and
 marking each line where a match occurs (for a multi-line pattern, only the
-start of the match matters).
+start of the pattern matters).
 In a second scan the [cmd] is executed for each marked line, as if the cursor
 was in that line.  For ":v" and ":g!" the command is executed for each not
 marked line.  If a line is deleted its mark disappears.

Or we should mention that an exception is made for \zs:
diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt
index 56e9ad82f..02d4dc0dd 100644
--- a/runtime/doc/repeat.txt
+++ b/runtime/doc/repeat.txt
@@ -75,8 +75,9 @@ NOTE [cmd] may contain a range; see |collapse| and |edit-paragraph-join| for
 examples.

 The global commands work by first scanning through the [range] lines and
-marking each line where a match occurs (for a multi-line pattern, only the
-start of the match matters).
+marking each line where a match occurs.  For a multi-line pattern, only the
+start of the match matters; however, if the pattern uses |/\zs| to match after
+the first line, the latter is marked (not the line where "\zs" matches).
 In a second scan the [cmd] is executed for each marked line, as if the cursor
 was in that line.  For ":v" and ":g!" the command is executed for each not
 marked line.  If a line is deleted its mark disappears.

I wonder when using \zs with :global would be useful.  If we have a good
example then we might have a reason to make it work.  If not, then
adjusting the help would be a better solution.
--
"The amigos also appear to be guilty of not citing the work of others who had
gone before them.  Even worse, they have a chapter about modeling time and
space without making a single reference to Star Trek!"
(Scott Ambler, reviewing the UML User Guide)
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I wonder when using \zs with :global would be useful.  If we have a good
example then we might have a reason to make it work.  If not, then
adjusting the help would be a better solution.

I have a mapping which deletes all the lines matching the last search.  It relies on the :global command, and executes something like this:
:execute 'global ;' .. @/ .. '; delete'

Most of the time it works as expected.  But if the last search is a multi line pattern containing \zs, it deletes unexpected lines.  I guess I should make it bail out in that case.


Can't get OAuth2 flow to work

Swagger UI provides a html file (https://github.com/swagger-api/swagger-ui/blob/cc408812fc927e265da158bf68239530740ab4cc/dist/oauth2-redirect.html) as redirect URL of an OAuth2 flow, but it looks like openapi-explorer needs an undocumented oauth-redirect-url param
Could this be generated as a dist file and do whatever postMessage magic is expected?
(also, a nice addition would be to allow passing the OAuth2 client-id as a param for hosted docs)

I can definitely be this doesn't work as it is supposed to, we shouldn't need any postMessage magic, but I can definitely see that it would help to have a generated file like the swagger-ui one. I can also see the need to have the client_id for oauth, let me take a good look at what is happening here and see what we can do.

Okay, so some changes in version 0.7 now there is a method to set the clientId, setAuthenticationConfiguration('authName', { clientId }), which will populate the Authentication screen in the explorer. Clicking on the GET TOKEN button will lead the user through the flow. If for some reason the redirect location needs to be specified there are additional instructions in the repository oauth configuration documentation
I'm going to close this issue for now, but if there are any issues we can reopen it, I fully expect depending on the AS you are using, we might need to make some adjustements.

Fantastic work @wparad !! Let me test this out :) We're using Auth0 so they do support PKCE and all, but will report any issue. In case I face issues, do you prefer that I reopen this issue, or create a new one?
2 minor comments in the meantime, hoping I'm reading/doing the code correctly:

IIUC, the authorizationCode flow may need a secret (though in single-page apps and native apps they recommend having an empty secret and PKCE). Seems like https://github.com/Rhosys/openapi-explorer/blob/127150e21a5c13ff6ee332b1c816e49e9866e262/src/templates/security-scheme-template.js#L270 used to include it, but now I'm getting only the client ID
setting the client id worked great for me, though I believe the securityObj.redirectUri only defaults to the current page if there's an explicit call to setAuthenticationConfiguration. If you don't call setAuthenticationConfiguration and manually enter a client id, it triggers an error on https://github.com/Rhosys/openapi-explorer/blob/127150e21a5c13ff6ee332b1c816e49e9866e262/src/templates/security-scheme-template.js#L173

Hope this helps :)

Thanks for the bug report on defaulting the redirect_uri, in most cases this isn't going to work due to the restrictions a lot of providers put on the format of this url, but it isn't bad to have a sane default.
Regarding the secret, we want to avoid bad security practices, which would include putting client secrets anywhere other than source code. If someone runs across this and wants to use a secret, they can always point the token url at the same location in the service api which accepts token exchanges. Usually for more complex apps, this exchange isn't happening through the OpenAPI Explorer anyway, so it is a moot point.
I could see hypothetically the one use case, might be for a platform that provides client/secrets to its users and wants to use the explorer to allow their customers a DX to let them test those clients with the platform. Again we want to dissuade vulnerable and poor security practices, would recommend potentially adding additional "event triggers" that a UI could do something custom before calling some service API. But unless that is a real concern for you/your users, I want to avoid discussing it here :)
If you run into related issues, tracking that problem here is better for posterity. If it is only somewhat related, a separate issue is probably better.

For what it's worth, we run an authorization platform that integrates with all OAuth providers (I believe Auth0 is one of them), and one of biggest opportunities we have is to prevent these poor practices. I wouldn't be surprised in near future implicit and client credentials grants are removed from here, and replaced with push authentication requests, which the cutting edge security providers already support.
I'm hesitant to remove features that teams are using, especially when it could be being consumed as a developer interacting with an API they don't control (i.e. using this isn't of postman). But it allows for potential vulnerabilities if done incorrectly, so there are huge tradeoffs.


Frontier silicon async

Description:
Related issue (if applicable): fixes #
fixes #11853
Checklist:

[ x] The code change is tested and works locally.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ x] New dependencies have been added to the REQUIREMENTS variable (example).
[x ] New dependencies are only imported inside functions that use them (example).
[ x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[x ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

Removed debug. Build fails for Python 3.6 - I does not look like it is because of the frontier_silicon component.


More than 2 items on mobile

Is there anyway so that I can show more than 2 items on mobile, as it looks like the code is forcing the number of items when on smaller screens even though i have set to display 4 items.
This would be really useful as i have really small icons and i want to show more than 2 items for smaller screens.

Yes, with a bit of CSS.
The slider item count is defined by a CSS variable, --swiffy-slider-item-count, that can be overwritten.
This is the CSS from Swiffy Slider that controls the number of slides on mobile:
@media (max-width: 62rem) {
    .swiffy-slider {
        --swiffy-slider-item-count: 1;
    }
    .slider-item-show2-sm {
        --swiffy-slider-item-count: 2;
    }
}

You can then add a custom css class to give you i.e. 4 slides on mobile:
@media (max-width: 62rem) {
    .custom-slider-item-show4-sm {
        --swiffy-slider-item-count: 4;
    }
}

And then add custom-slider-item-show4-sm class to your .swiffy-slider instance.
Merry Christmas


Exception: javax.crypto.IllegalBlockSizeException

I'm trying to store a JWT access token using SecurePreferences.
But when i store a 245+ char long string i get:
de.adorsys.android.securestoragelibrary.SecureStorageException: javax.crypto.IllegalBlockSizeException
Is there any limitation on how large strings that can be decrypted?
I made this small test to check on what char count it fails on, and its always on char 246
    @Test
    fun testCrash() {
        val source = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrst1234567890."
        val fakeToken = Random().ints(500, 0, source.length)
                .asSequence()
                .map(source::get)
                .joinToString("")

        for (i in 0..fakeToken.length) {
            val substring = fakeToken.substring(0,i)
            print("COUNT: ")
            print(" ${substring.count()} ")
            print(substring)
            println()
            SecurePreferences.setValue("ACCESS_TOKEN_KEY", substring)
        }
    }

I guess this is the same issue:
https://stackoverflow.com/questions/10007147/getting-a-illegalblocksizeexception-data-must-not-be-longer-than-256-bytes-when

Thanks for using Secure Storage. This has been already answered in https://github.com/adorsys/secure-storage-android/issues/28. Unfortunately, with Secure Storage 1 this cannot be solved.

Closing this as duplicate. No activity for over two weeks


Fix paths

I found some incorrect paths and typo.

change from lts to version for javascript
some typofix

 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.:x: mkontani sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks!!


Added defensive coding and warning - fixes #33

What problem does this PR address?
Adds a bit of addition defensive coding
Is there a related Issue?
#33
Have you...

If you are willing, please enable me, as the Repo owner, to edit your fork that contains your PR so I can add any missing items such as the readme.md

Re-reading through this & the wider code base I don't think this change is actually needed


Instructions for git clone was referring to old repo.

Instructions for git clone was referring to old repo. Updated to point to current repository.

Thank you very much @ashageetha


feat: Update security-secretstore-setup config

Changes for https://github.com/edgexfoundry/edgex-compose/issues/463

If your build fails  due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/main/.github/Contributing.md
PR Checklist
Please check if your PR fulfills the following requirements:

[x] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[x] I am not introducing a new dependency (add notes below if you are)
[ ] I have added unit tests for the new feature or bug fix (if not, why?)
[x] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
[ ] I have opened a PR for the related docs change (if not, why?)

Testing Instructions

New Dependency Instructions (If applicable)

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 34.65%. Comparing base (ef9dbcf) to head (da59c5e).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4926   +/-   ##
=======================================
  Coverage   34.65%   34.65%
=======================================
  Files         131      131
  Lines       13157    13157
=======================================
  Hits         4560     4560
  Misses       8203     8203
  Partials      394      394

Flag
Coverage Δ

34.65% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Import a new theme

Summary
New color theme and text styles from Figma design have been imported. Custom dialog layouts have been corrected to match the Material 3 design system.
Reasons

The new color scheme and text styles were needed for a consistent design
Removal of unnecessary overrides simplifies the codebase
Fixes to dialogs and window inserts were necessary for Material 3 compatibility

References

closes #162

Moved to AndroidBle


[bug] Hosted Gorilla:

Exception: Invalid response object from API: '{"object":"error","message":"This model's maximum context length is 2048 tokens. However, you requested 2302 tokens (1790 in the messages, 512 in the completion). Please reduce the length of the messages or completion.","code":40303}' (HTTP response code was 400)
Is there any way to just cut the completion / request to the first 2048 tokens?

Hey @surya-narayanan Yes! you can use any tokenizer (e.g., https://platform.openai.com/tokenizer) to count # of input tokens,  and then set max_tokens in request such that the total # of tokens is < 2048.
Here's example code:
completion = openai.ChatCompletion.create(
      model=model,
      messages=[{"role": "user", "content": prompt}],
      max_tokens=257, # Change this as appropriate for your request
    )
    return completion.choices[0].message.content


Fold all updates since May from master and internal repo into v1

This also includes some in-progress changes to the packages workflow (will be handled separately, this at least moves the ball forward there although it isn't done yet).
This includes through internal revision 6487010.

@isc-shuliu in case you get to the CI failures before I do, there are three classes of issues:

Failures early because of our processing of tags - we're turning e.g. latest-em and latest-cd into "latest" which doesn't exist. Need to be smarter here.
Failures early because of community edition licenses expiring - we should detect and fail early (without an error) in this case. If there's some kind of "skipped" option for the job that is neither success nor failure that would be ideal, if possible.
We only want the highest value of z among builds (year.x.y.z)
Failures later in the process because of the ZPM->IPM rename (this is a bigger can of worms I don't expect you to open just yet ;))

@isc-shuliu here's an updated checklist after the work I did earlier this week:

[ ] Be smarter about expired community edition licenses; could have a min version flag or a file with a list of tags to ignore?
[ ] Issues in the clean install step (this is likely to be the bigger can of worms, but we can at least investigate + fix the missing container part)
[ ] Fix unit tests (currently have a failure due to a code change) - we might need to talk about the code change
[ ] Fix "verify" phase (currently failing due to ZPM/IPM differences)
[ ] Ensure "verify" passes
[ ] Make test/verify failures fatal again
[ ] Really fix clean install + upgrade (this one is on me and is likely enormous)


Don't automatically add axis: {"autorange": True, "range": None} when converting existing figures

In figure_resampler_interface.py#149
I'm generating some nested graphs that are meant to always display data within the same range. For my case it's telemetry from my car, and let's imagine the example of Oil Temp. I know the oil temp can only be within the range [40, 100] during operation, so my oil temp graph is set to always have that range. That way, any time I open a trace, I can tell at a glance if the line is near the top of the graph, it must mean bad things.
When I add FigureResampler to my existing Dash app, it completely breaks my careful construction of the graph and throws a global 'autorange' onto it. This both loses the initial fixed range, and also continuously re-ranges the Y axis whenever I scroll horizontally
graph_things.py
# Make all my various graphs. Copy pasted segments.
def plot_car_trace():
    fig = subplots.make_subplots(rows=subplot_rows, cols=subplot_cols, shared_xaxes=True, shared_yaxes=False, ...)

    fig.add_trace(oil_pump_scatter(), row=1, col=1)
    fig.update_yaxes(row=1, col=1, range= [40, 100])

    fig.add_trace(vehicle_speed_scatter(), row=2, col=1)
    fig.update_yaxes(row=2, col=1, range= [0, 200])

    # don't even let the user mess up the ranges
    fig.update_yaxes(fixedrange=True, autorange=False)
    fig.update_xaxes(autorange=False, range=[0, 5 * 60])  # Show 5 minutes of data
    return fig

dash_app.py
app = DashProxy(__name__, transforms=[ServersideOutputTransform()])
# etc

@app.callback(...)
def update_figure(trace_hash, trace_json, filename):
    fig = FigureResampler(plot_car_trace())
    return fig

# as per examples
def update_fig(relayoutdata, fig):
    if fig is None:
        return no_update
    return fig.construct_update_data(relayoutdata)

app.run(debug=True, port=9023, dev_tools_hot_reload=False)

I've split my code into two files, since I don't necessarily always want to use Dash to display the Figure. So I don't want to, eg. set the FigureResampler(subplots.make_subplots()), and then separately add each trace to it, or reset the axis ranges in a second step.
Is there a way I can disable autozoom when simply wrapping an existing Figure using FigureResampler(existingFig)?

Hey @remulasce,
Thanks for submitting this clear issue! I agree that it does not make a lot of sense that the layout is not fully copied when wrapping into a Figure(Widget)Resampler.
I think removing this code from the constructor (as I do in #228) will fix this issue.
https://github.com/predict-idlab/plotly-resampler/blob/c9054781cdf82d614f194d3fee6b9d3e0be84278/plotly_resampler/figure_resampler/figure_resampler_interface.py#L163-L169
To be honest, I am not entirely sure why we added this code in the constructor in the first place..

I recall attempting to comment out the lines myself and having a problem where the bounds update event dash callback was throwing, possibly due to the bounds not being provided in a raw translation update? I got it kind of working by disabling Y autoscale but not X.
In the end I found the latency of the server having to receive an update, then push new trace data to the client, to be too long when scrolling around and I didn't want to have to set up a whole memory cache system and also fix this issue. Instead I started using a ScatterGL plot, which handles my requirements at full resolution and framerate without lag.


Fontsource font preview display page allows font substitution

Describe the bug
When searching and previewing fonts, the fontsource preview page allows font substitution.   This does not allow the user to visually see that a font does or especially doesn't support required glyphs.   Google's page however will show the expected boxes where glyphs are missing.  Note the two screen shots of the Lora font on fontsource and Google. The font substitution actually looks not bad(in this case), but this can easily lead to an inappropriate font choice.
fontsource:

Google:

Steps to Reproduce
Search for any font and type in a character that is unsupported.   For example:
Mɔgɔkɔrɔw kaɲi ka kɛ ni ŋania ɲuman ye
Font substitution will happen.
Expected behavior
When glyphs are missing, show missing glyphs.
Version
No response
OS
No response
Browser
No response
Additional context
No response

To fix that, we'll just need to add back in the fallback-font to the preview, it should be fairly easy (we had it on the old website).


HBASE-25292 [branch-2.4] Improve InetSocketAddress usage discipline

Back-port of https://github.com/apache/hbase/pull/2669 to the 2.4 release line.
(cherry picked from commit f813479)
Co-authored-by: Andrew Purtell<EMAIL_ADDRESS>

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
3m 25s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 28s
branch-2.4 passed

+1 :green_heart:
compile
4m  5s
branch-2.4 passed

+1 :green_heart:
checkstyle
1m 23s
branch-2.4 passed

+1 :green_heart:
spotless
0m 40s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
3m 27s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 15s
the patch passed

+1 :green_heart:
compile
4m  0s
the patch passed

+1 :green_heart:
javac
4m  0s
the patch passed

-0 :warning:
checkstyle
0m 17s
hbase-client: The patch generated 7 new + 6 unchanged - 0 fixed = 13 total (was 6)

-0 :warning:
checkstyle
0m 35s
hbase-server: The patch generated 2 new + 20 unchanged - 0 fixed = 22 total (was 20)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
16m 10s
Patch does not cause any errors with Hadoop 2.10.2 or 3.1.4 3.2.4 3.3.6.

-1 :x:
spotless
0m 13s
patch has 21 errors when running spotless:check, run spotless:apply to fix.

+1 :green_heart:
spotbugs
4m  4s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 42s
The patch does not generate ASF License warnings.

46m 51s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux b488d40470c7 5.4.0-163-generic #180-Ubuntu SMP Tue Sep 5 13:21:23 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Eclipse Adoptium-11.0.17+8

checkstyle
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-client.txt

checkstyle
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/artifact/yetus-general-check/output/patch-spotless.txt

Max. process+thread count
79 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 30s
Docker mode activated.

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 32s
branch-2.4 passed

+1 :green_heart:
compile
1m 32s
branch-2.4 passed

+1 :green_heart:
shadedjars
4m 39s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 10s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 24s
the patch passed

+1 :green_heart:
compile
1m 31s
the patch passed

+1 :green_heart:
javac
1m 31s
the patch passed

+1 :green_heart:
shadedjars
4m 35s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  7s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 29s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m 20s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 35s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
161m 47s
hbase-server in the patch passed.

+1 :green_heart:
unit
0m 21s
hbase-external-blockcache in the patch passed.

193m 18s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 9470f0e117f0 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/testReport/

Max. process+thread count
4542 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Thank you. This is looking good to me but since I was involved in creating this patch I'll give @apurtell (or others) a chance to take a look as well.
Thank you @sbernauer!

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
3m  9s
Docker mode activated.

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 10s
branch-2.4 passed

+1 :green_heart:
compile
1m 33s
branch-2.4 passed

+1 :green_heart:
shadedjars
3m 56s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 14s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  1s
the patch passed

+1 :green_heart:
compile
1m 33s
the patch passed

+1 :green_heart:
javac
1m 33s
the patch passed

+1 :green_heart:
shadedjars
3m 55s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 13s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 21s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m  9s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 36s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
173m  6s
hbase-server in the patch passed.

+1 :green_heart:
unit
0m 24s
hbase-external-blockcache in the patch passed.

203m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 2bdecb39f840 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/testReport/

Max. process+thread count
3869 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 39s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 33s
branch-2.4 passed

+1 :green_heart:
compile
4m 10s
branch-2.4 passed

+1 :green_heart:
checkstyle
1m 22s
branch-2.4 passed

+1 :green_heart:
spotless
0m 42s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
3m 29s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 20s
the patch passed

+1 :green_heart:
compile
4m 13s
the patch passed

+1 :green_heart:
javac
4m 13s
the patch passed

+1 :green_heart:
checkstyle
1m 22s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
16m 35s
Patch does not cause any errors with Hadoop 2.10.2 or 3.1.4 3.2.4 3.3.6.

+1 :green_heart:
spotless
0m 40s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
4m  8s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 47s
The patch does not generate ASF License warnings.

45m 45s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux 9bb5c9fead33 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
82 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 42s
Docker mode activated.

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 10s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 21s
branch-2.4 passed

+1 :green_heart:
compile
1m 35s
branch-2.4 passed

+1 :green_heart:
shadedjars
4m 48s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  9s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 10s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 21s
the patch passed

+1 :green_heart:
compile
1m 35s
the patch passed

+1 :green_heart:
javac
1m 35s
the patch passed

+1 :green_heart:
shadedjars
4m 43s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  8s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 29s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m 25s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 34s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
162m 56s
hbase-server in the patch passed.

+1 :green_heart:
unit
0m 19s
hbase-external-blockcache in the patch passed.

192m 42s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux b2ed5df78618 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/testReport/

Max. process+thread count
4850 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 34s
Docker mode activated.

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 12s
branch-2.4 passed

+1 :green_heart:
compile
1m 34s
branch-2.4 passed

+1 :green_heart:
shadedjars
3m 59s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 14s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 58s
the patch passed

+1 :green_heart:
compile
1m 34s
the patch passed

+1 :green_heart:
javac
1m 34s
the patch passed

+1 :green_heart:
shadedjars
3m 54s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 11s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 22s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m  4s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 36s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
172m 53s
hbase-server in the patch passed.

+1 :green_heart:
unit
0m 25s
hbase-external-blockcache in the patch passed.

200m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 2e70ebf63040 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/testReport/

Max. process+thread count
4119 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/2/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 36s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 29s
branch-2.4 passed

+1 :green_heart:
compile
4m  5s
branch-2.4 passed

+1 :green_heart:
checkstyle
1m 21s
branch-2.4 passed

+1 :green_heart:
spotless
0m 41s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
3m 25s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 15s
the patch passed

+1 :green_heart:
compile
4m  4s
the patch passed

+1 :green_heart:
javac
4m  4s
the patch passed

+1 :green_heart:
checkstyle
1m 19s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
16m 18s
Patch does not cause any errors with Hadoop 2.10.2 or 3.1.4 3.2.4 3.3.6.

+1 :green_heart:
spotless
0m 39s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
4m  6s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 43s
The patch does not generate ASF License warnings.

44m 48s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux 9e4f3a696cb6 5.4.0-163-generic #180-Ubuntu SMP Tue Sep 5 13:21:23 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
80 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 44s
Docker mode activated.

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 19s
branch-2.4 passed

+1 :green_heart:
compile
1m 32s
branch-2.4 passed

+1 :green_heart:
shadedjars
4m 33s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  8s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 10s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 23s
the patch passed

+1 :green_heart:
compile
1m 33s
the patch passed

+1 :green_heart:
javac
1m 33s
the patch passed

+1 :green_heart:
shadedjars
4m 44s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  9s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 29s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m 30s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 35s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
160m 57s
hbase-server in the patch passed.

+1 :green_heart:
unit
0m 17s
hbase-external-blockcache in the patch passed.

190m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux faa77d5ffed0 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/testReport/

Max. process+thread count
5178 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 35s
Docker mode activated.

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.4 Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
1m 59s
branch-2.4 passed

+1 :green_heart:
compile
1m 32s
branch-2.4 passed

+1 :green_heart:
shadedjars
3m 58s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 13s
branch-2.4 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 59s
the patch passed

+1 :green_heart:
compile
1m 34s
the patch passed

+1 :green_heart:
javac
1m 34s
the patch passed

+1 :green_heart:
shadedjars
3m 56s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 11s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 21s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m  3s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 37s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
178m 34s
hbase-server in the patch passed.

+1 :green_heart:
unit
0m 24s
hbase-external-blockcache in the patch passed.

206m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5515

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux b43101c0cd01 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.4 / 62f2383c70

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/testReport/

Max. process+thread count
4217 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-zookeeper hbase-server hbase-external-blockcache U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5515/3/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

@sbernauer Thanks for opening this PR.
So you guys needs this on branch-2.4? The patch here removes a configuration, so typically we do not want to include it in a patch release.
And looking at the discussion on #2669 , there are also some other follow on tasks need to be done before making a release.
Thanks.

See HBASE-25335.
I think at least we should also backport HBASE-25336?

Ah! Yes, sorry.
We have a patch for that as well and can put up a PR as well.
Only makes sense if we agree that this one should go in though I believe. They might even depend on each other, I haven't checked now.
But we can definitely do HBASE-25336 as well!

I'm OK with backporting all these issues to 2.4.

Thank you! I'll merge it then and we'll get the second PR up as well.

Thanks a lot for the quick review!

Created https://github.com/apache/hbase/pull/5537 as a follow-up


B-18194-INT add auth check to weight ticket update

Agility ticket
Summary
Make sure a MilMove user is authorized to modify the data
How to test

Login as a customer with an existing move in the PPM Upload documents stage (or create one and get to that step in the process)
Create a weight ticket, update it, and ensure everything works as normal/expected

Test coverage on server failed.
Last run: Wed 24 Jan 2024 08:44:53 PM UTC
Refer to this report to see coverage details for the server app.
Documentation for test coverage can be found at this link.

Test coverage passed on initial build to main in build 60037, increasing from 78.3 to 78.4


[RFE] Add azureADProvider as supportedAuthProvider for rancher CLI

Is your feature request related to a problem? Please describe.
I have a customer that has just moved from AD to Azure AD and are unable to request tokens using the rancher CLI or kubectl.
Requesting that azureADProvider be added as a supportedAuthProvider to allow for the rancher CLI (and kubectl) to request a new token when an existing token has expired.
Describe the solution you'd like
Allow rancher CLI to pull a token using azureADProvider, similar to how we can currently do this with localProvider, activeDirectoryProvider, and other supported authentication providers when kubeconfig-generate-token is set to false.
Describe alternatives you've considered
Set kubeconfig-generate-token to true, however this would impact the security posture required by the customer, and is not acceptable for them.  Is there another way to pull tokens while authenticating to Azure AD?
Additional context
https://ranchermanager.docs.rancher.com/reference-guides/cli-with-rancher/kubectl-utility#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl
https://github.com/rancher/cli/pull/336
(However, even though this builds, I doubt it will actually work based on the kubectl-utility documentation)

Please reopen this, because no support for azuread/AzureEntra:
If admins have kubeconfig token generation turned off, the kubeconfig file requires the Rancher CLI to be present in your PATH when you run kubectl. Otherwise, you’ll see an error like: Unable to connect to the server: getting credentials: exec: exec: "rancher": executable file not found in $PATH.
This feature enables kubectl to authenticate with the Rancher server and get a new kubeconfig token when required. The following auth providers are currently supported:
Local
Active Directory (LDAP only)
FreeIPA
OpenLDAP
SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth

Can we please open this?
We are also using Azure AD and would like to have the option of authentication via the CLI

Isnt this currently being worked on here:
https://github.com/rancher/cli/pull/346

https://github.com/rancher/rancher/issues/44282
https://github.com/rancher/rancher/issues/42939


Move list of Git-downloaded extensions into a YAML file

About 500 of the Canasta Dockerfile's 761 lines are devoted to one thing: downloading the roughly 120 extensions that Canasta gets via Git. The code for every download is roughly the same, so this represents a lot of duplicated code. This could be done much more cleanly by putting all the needed information about these extensions into a single file (probably YAML makes the most sense), then having the Dockerfile read this file and cycle through the extensions, downloading each one. Having this separate file could also make it easier for people to use Canasta as a base image for their own MediaWiki distributions, since presumably the big difference between one distribution and the next is the set of extensions used.
(Very similar code could be created for downloading skins - this issue covers only extensions, since the need for streamlining skin downloads seems much smaller. But it would be great to do both, I think.)

Thinking more about this, it may make sense to also include the names of patch files in the YAML file. There are currently four extensions that are patched, and if the patch file information was moved into the YAML file, it would remove another 20 or so lines of code from the Dockerfile. (Ignoring the additional lines of code that would need to be added to handle all this stuff.) More importantly, it would remove another reason for images that inherit from Canasta to ever have to modify the Dockerfile.
By the way, here is what a section of the YAML file could look like for the SemanticScribunto extension, which is patched:
- SemanticScribunto: # v. 2.2.0
    url: https://github.com/SemanticMediaWiki/SemanticScribunto
    revision: 1c616a4c4da443b3433000d6870bb92c184236fa
    patches: semantic-scribunto-autoload.patch

(The code could assume that every patch file is located in the /_sources/patches directory.)

I think it's a good idea, and I like the approach with YAML files, but the main drawback needs to be considered - this approach makes it impossible to benefit from layers caching
Cached layers are not utilized much on Canasta currently (most of the extensions are downloaded in a single RUN command), but on Taqasta, we make use of it (by splitting extensions downloads in batches https://github.com/WikiTeq/Taqasta/blob/master/Dockerfile#L178)
This allows the builder to avoid re-downloading all the extensions when some specific extension version is changed and instead makes it re-use the cached version for most of the unchanged layers (for Taqasta, it's crucial to reduce build times as much as possible)

More importantly, it would remove another reason for images that inherit from Canasta to ever have to modify the Dockerfile.

I don't think this changes much for the images that inherit from Canasta - currently, any image that inherits from Canasta also inherits all the extensions that were downloaded during the base image build. If there is a need to change the extension version, the image removes the extension directory and downloads the one it wants. It's quick to do because it's just a single command
If migrated to YAML files the image that inherits from Canasta will have two options - either do it the same way as before, by deleting the directory and downloading the desired extension version, or modify the YAML file and run the Canasta script to redownload all the extensions accordingly to the modified YAML file, which is a pretty time-consuming operation ( the Canasta script also need to support this use-case, e.g., wipe the extensions directory before re-downloading )
Also, apparently, to be allow the inherting image to re-apply patches, it'd be necessary to keep all the .git directories in place on the resulting Canasta image, which will grow the image size noticeable

Yes, I was partly wrong about such a change making it easier for Canasta-based images to define their own set of extensions and skins. After all this time, I am still not very knowledgeable about Docker, so I keep thinking about a Docker base image as something like a "base class" that can be overridden, even though that is definitely not the case (as you point out).
However, I say "partly" because there may still be ways in the future to allow for building the Canasta image with a custom set of extensions and skins. (Without having to download, delete and then re-download.) One option is to have environment variables that define the name of the YAML files to use, instead of just the default canasta-extensions.yaml and canasta-skins.yaml (or whatever they would be called). Another is to to turn Canasta into two Docker images - a base image containing only MediaWiki, and a 2nd image containing the extensions and skins. (Although with that approach, the YAML file setup would not really change anything either way.)
I didn't understand the thing about layer caching. What is the ideal approach: a single RUN command to get all the extensions, a separate RUN command for each extension, or something in between, like a RUN command for each letter of the alphabet, or a RUN command for every five extensions? Whatever approach is best, my guess is that the Dockerfile code that handled the YAML files could do that.

What is the ideal approach: a single RUN command to get all the extensions, a separate RUN command for each extension

The ideal approach is to have separate RUN commands for each execution because these RUN commands are converted into layers that can be cached and then re-used if the RUN statement is unmodified

Whatever approach is best, my guess is that the Dockerfile code that handled the YAML files could do that.

I don't think so. Any code on the Dockerfile will be a RUN by itself. This RUN will be re-evaluated each time the command changes or the source YAML file changes, but I don't see any way to achieve the same caching as with many RUNs. But as mentioned this won't be much different from how it's composed on Canasta right now (with most of the extensions installed in a single RUN command)

so I keep thinking about a Docker base image as something like a "base class" that can be overridden, even though that is definitely not the case (as you point out)

It would be nice, but yes, unfortunately, image inheritance is mostly a filesystem inheritance

Another is to to turn Canasta into two Docker images - a base image containing only MediaWiki, and a 2nd image containing the extensions and skins

At some point, we considered this approach at Taqasta - to extract the extensions bundle into a separate image. This is a livable option. However, it complicates things a lot, creating extra dependency and version management needs. Noting that we were considering this solely for increasing build speed, not for extendability or inheritance

One option is to have environment variables that define the name of the YAML files to use, instead of just the default canasta-extensions.yaml and canasta-skins.yaml (or whatever they would be called)

That's an option. However, this probably has nothing to do with the inheritance - with this, you can take the original Cansata and simply build it supplying different ARGs or different YAML file contents. But you still need to build it all from scratch even if there is a single change in the list of the extensions
--
So far, I don't see any good options to allow other images inherited from Canasta to modify the list of extensions installed. It looks like the common approach is the best one so far, e.g., when you inherit your image from Canasta and do necessary updates like below:
FROM canasta
RUN rm -rf canasta-extensions/Something
RUN git clone ... canasta-extensions/SomethingNew
RUN sed .... composer.local.json
RUN composer update --no-dev
CMD ["/run-apache.sh"]

@vedmaka - thanks for this response. The whole issue with wanting to just override one extension in Canasta is pretty easily solvable, I think - if you allow the environment variables to set an array of YAML files for extensions and/or skins, instead of just a single YAML file, then an inheriting image could have a setting like:
EXTENSIONS_YAML=("canasta-extensions.yaml" "/src/nicewiki/nicewiki-extensions.yaml")

nicewiki-extensions.yaml could then hold just a few lines, like:
- AdminLinks:
    revision: abcde01........

For any duplicates, Canasta would use the information from the last listing encountered - letting anyone build a version of Canasta with just a set of overrides to the group of extensions and skins.
What about removing an extension or skin that was already listed? I suppose the YAML file could also contain lines like this:
- AdminLinks: # we don't want this extension

If there were no settings for a particular extension or skin, the code would simply skip over it. (That's what it should do even if there were no overriding capability, I would think.)
What do you think?
As for the caching stuff - I have a question: why is it necessary for you to reduce build times as much as possible? What is the harm if (to take an extreme example) setting up a wiki takes 20 minutes instead of 2 minutes? I assume you are not trying to generate thousands of wikis a day.

I still do not think this improves anything - the reason is that regardless of how the YAML files are composed, the inheriting image will have to run something to process the YAML files and install extensions accordingly to the YAML files.
Since the image is inherited from Canasta, the filesystem will already contain an extensions directory with all the extensions and their composer dependencies installed there, patches, etc. So if the inhering image runs something to process the YAMLs again, this something should be intelligent enough to take this situation into account ( or do rm -rf vendor && rm -rf extensions and start it all from scratch )
It does not look like a set of YAML files makes this any different from having a single YAML file. You still need to rebuild everything. I'd guess it even makes things more complicated because you need to have a canasta-extensions.yaml in place ( assuming what we're taking here is Docker inheritance, not GitHub forking )

As for the caching stuff - I have a question: why is it necessary for you to reduce build times as much as possible? What is the harm if (to take an extreme example) setting up a wiki takes 20 minutes instead of 2 minutes? I assume you are not trying to generate thousands of wikis a day.

The main reason is to speed up CI builds as much as possible, waiting for 20-30 minutes on each iteration is quite destructive for our development & delivery processes

@vedmaka - thank you for your answers, and your patience so far. There is a lot that I still need to learn about Docker, but this discussion is helping me quite a bit.
So - you are right that trying to have Canasta "child" images modify the original extension YAML probably would not work. But what about the option you suggested before, of having a child image go into the canasta-extensions/ and canasta-skins/ directories and make deletions and additions as necessary? That way (I think) the build process will remain speedy even if Canasta switches to a YAML approach - since the entire base image of Canasta will get cached as a single layer, even if the build process for Canasta itself is slow.
Is that correct? And if that seems like a reasonable approach, do you still have any objections to having Canasta itself load extensions and skins via YAML files?

I am happy to help!
Yes, the child image doing stuff it needs on the extensions and skins directories (and optionally running composer) seems to be the best way for this. Regardless of how the files initially occurred by the original image, this is the fastest option to make mods by the child image. And yes, the parent Canasta image will stay cached.
I have no objections to Canasta itself migrating to YAML, my only notice is that this will slow down builds, but I assume this is not super important for the Canasta workflow


Add NodeJS and Yarn requirements to build v1.2 from source

Fixes #2150
Note that the 1.2 build from source instructions are hidden for now, though. See https://github.com/cockroachdb/docs/issues/2155.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/1477a90afc21801b51041db3047790f979b4dadf/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/0f32d3b40aeadb401a373490410e0bf1baeebf4d/

@benesch, do we need to bump the Go version requirement as well?

@benesch, nevermind. I see it was called out in one the 1.2 alpha release notes: https://github.com/cockroachdb/cockroach/pull/18459

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/946d58b13e7049ab7994475e53697980ca950c07/