Add banner to highlight dockershim migration docs

This is a Feature Request

What would you like to be added
When there are good / good-enough docs for migration away from dockershim, add a banner that highlights these docs. Leave that banner in place until (maybe even after) the v1.24 release.
Why is this needed
We're removing dockershim from Kubernetes
Comments
/sig node
/kind feature
Will need steering committee signoff

/committee steering

Hi @kubernetes/steering-committee , just want to put this on your radar

@chris-short here's the PR that added a banner for KubeCon Europe 2021
https://github.com/kubernetes/website/pull/27844
and here's one for a banner for KubeCon NA 2021 and announcement for KubeCon China
https://github.com/kubernetes/website/pull/29192

is a months-long site-wide banner appropriate for this?

months-long

I hadn't imagined that the banner would be shown for months. It might be ready for over a month though. I suppose I started off pessimistic that the relevant docs would be ready well before the next release.
We could

add the banner with timings so that it's in place for a short time around the release - perhaps 3 days before the release and 7 days afterwards
have a PR ready to add a banner, and hold that PR pending a problematic social media reaction (unholding if we think it becomes important to direct all readers to our key page on the topic)

We don't have a mechanism to mark banners as seen. Maybe it'd be useful to add one.

Okay, so not a sitewide banner for months, check.
What should the banner say? Where should it link?
Found this in #31425, applicable here?
Warning: This page mentions Docker Engine. Docker Engine compatibility was deprecated as of Kubernetes 1.24. For more information see [Dockershim FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/)

@chris-short what #31425 suggests a notice for specific pages.
This is about adding a banner (see https://github.com/kubernetes/website/pull/23183 for an example) that shows across every page of the site, during a defined period.
We might want to do either or both. This suggestion, the site-wide banner, is not yet triaged as accepted.

I'm thinking we might say “Want to know more about changes in Kubernetes v1.24 around integration with Docker Engine? Visit xxxx”. Something like that.

Yes, I good with the schedule and mechanics of making that happen.
I was more interested in the message itself. I still think the dockershim FAQ might be the best to send folks despite it having an outdated info warning on it now. Can we turn that off for that page?!?

@chris-short It looks like someone just put out an update of the blog: https://kubernetes.io/blog/2022/02/17/dockershim-faq/

That was me

Since I took on Issue #31425 I can work on this one as well.
/assign

I added PR #32805 to address this issue. I'm looking for feedback on wording, graphics and timeframe.

PR #32805 merged
/close

/reopen
We should prepare a banner update to go live on release day.

Done
/close


The envvars added in 7544 need an update after they have been tested

Referencing: Allow configuring storage registry with envvars
Just that this does not get forgotten because the comments are now "hard to find by merged":

Wondering what the defaults and possible values like driver or rule names could be...
@dragotin once you are familiar with the new envvars, could you improve the description in a follow-up PR?

GATEWAY_STORAGE_REGISTRY_CONFIG_JSON
Q: how does the json get assigned to the variable? Imho a reference to a file would do this.
See: USERS_LDAP_CACERT where we have a default path/file if not otherwise defined: If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/idm. Just my 2c.

Maybe to add the findings in this issue for a follow up PR to be created.
@kobergj @dragotin

Because GATEWAY_STORAGE_REGISTRY_RULES is new and an array, we need to add this to:
Defining and describing envvar allowing multiple values (array slice) is not clear


Running on a VPS

Any instructions on how to build/run/start this project on local/VPS (Linux)?

I'm not at my PC at the moment but with Node.js installed, you should be able to install dependencies with npm install, then start the server with node server.js.
I haven't worked on this project in a while but I'll get some setup instructions added to the readme soon.


Local code patch not formatted

Code patch file opened with file:// not formatted by ecdiff.
Service worker error:

Issue still exist. Tested v0.1.3.


HTEX "crash properly" behaviour

Many parts of Parsl and especially htex will result in end-user hangs because bad behaviour is "ignored" rather than "propagated towards the user". See #3404 and #3427. This comes from the original prototype-oriented implementation in which it is desirable to keep doing as much as possible rather than failing early on prototype-quality coding errors, giving as much work done for reporting the happy path, rather than providing a good user experience.
Six years after prototyping, and with a much more production-oriented user base, reporting errors to the user and failing cleanly rather than hanging are much more important. I would like to see Parsl and especially HTEX move to a more serious "fail and let a higher level supervisor do something with the failure" model, inspired by erlang/OTP's "let it crash" philosophy.
For example, if any thread dies in the interchange unexpectedly, the only sensible thing to do is for the interchange to exit (unless more subtle reasoning is applied to individual errors that are experienced, turning them into expected errors). And when the interchange exits, the only reasonable thing to do is for the high throughput executor to notice that and to pass that error up as all tasks failed. (contrast this to the current behaviour in #3404 where the command thread exiting turns into a permanent hang).
This issue is to give the above concept an issue number for cross-referencing in other PRs and issues, rather than being a target for a single fix.

As a result of adding the ManagerSelector feature to the HTEX in #3547, should the ManagerSelector fail to properly sort the manager list and return it to the interchange, the interchange will crash but will leave the rest of the program hanging. Documenting this behavior for future reference if more complex ManagerSelectors are introduced which could increase the chance of breakage.


default indentation is odd

zeroCol checked

 /*
 This code is a React hook that returns an object with the following properties.
  `connector`  A function that takes in props and returns a widget description.
  `props`  The props passed into the useRange() call.
 - generated by stenography autopilot [ 🚗👩✈ ]
 */
export function useRange(props: UseRangeProps) {
  return useConnector<RangeConnectorParams, RangeWidgetDescription>(
    connectRange,
    props
  );
}

(single space added)

without the zeroCol setting

       /*
       This code is a React Hook that returns an object with the following properties.
        `value`  The current value of the range widget.
        `setValue`  A function to change the value of the range widget.
        `widget`  An object containing information about how to render and style this component in JupyterLab.
       - generated by stenography autopilot [ 🚗👩✈ ]
       */
export function useRange(props: UseRangeProps) {
  return useConnector<RangeConnectorParams, RangeWidgetDescription>(
    connectRange,
    props
  );
}

zeroCol should be fixed! And in the 1.1.5 update I added a max comment width, which should lead to a better spacing UX


GSN wallet initialisation: Make the buy sell button active as soon as initialization is confirmed.

Not wait for the user to close the message

I'm no longer seeing the processing or confirmed states

Getting this error after trying to place the order. Not sure if the two are linked

@matt-bullock give this another test now on Kovan -- let me know if its working as expected.

@andrewdamelio need to wait for v2 to be up and running again

@andrewdamelio it's working ok on Local, does that mean it's good to close?

Closing this as it's working how it should


How is indexing/search performance on large corpus of documents?

E.g. a blog or documentation site?
Would it be possible perhaps to pre-index content at build time? If indexing is a bottleneck, then this could significantly help on slower devices e.g. old phones. Though perhaps just use the web-worker version.

That's a good question. I have used this lib and js-worker-search on corpuses of many documents, each containing a sentence or two of text (eg things like name, address, etc) but I haven't used either yet on corpuses with documents containing large amounts of text (eg blog posts).
I have thought a bit (but not much) about the idea of pre-built indexes. I've actually thought on it from the angle or persisting an index and then restoring it later. But I haven't had the time to really put much thought or effort into either. In general, I'm a fan of the idea.
The tricky part would be that some functionality (eg TF-IDF ranking) is coupled to the index implementation and so to pre-build it would require coupling with the implementation. This is why persisting an existing index is preferable (although you'd have to handle things like backwards incompatible upgrades).
Any chance you'd be interested in helping? 😄

Possibly! I really want to have docs sites built with Gatsby work completely offline so having search be handled locally (not with Algolia) is pretty compelling. I'll have to give this a go when I have a chance — I've used Lunr with ~2500 longish documents (journal entries) and while indexing takes a decent bit of time ~5-10 seconds, searches are quite quick.
This is something I'll be giving a lot of time in the near future but will be poking around hopefully soon!

Oooh...well, I've perf-measured this lib against Lunr and- last I checked- js-search was faster. js-worker-search is the same basic algorithm, but trimmed a bit further and moved to a web worker- so I think you'll find its performance even better. (I've built indexes of several tens of thousands of user/table/account objects with it before and didn't even notice a tiny hiccup, but again, these are different kinds of data.)
I would be interested in collaborating on the ability to persist-and-restore (and so pre-generate) these indexes. I'm a bit swamped for time at the moment though, with the new job and looking to move. But... maybe things will clear up a bit over the holidays. :)

Thinking a little more about this, I believe the way I would approach this would be to augment ISearchIndex with 2 additional methods: persist and restore. persist would return a representation of the index that could be stored somewhere (eg cookie, localStorage, on a server, whatever) and then restore would accept, as a parameter, that same object.
There's some potential trickiness here:

Detecting/handling version changes (eg data persisted with version X of js-search and later restored with version X+1).
Tokenizer and sanitizers pre-process the search data to help build an index. They also pre-process search terms to ensure they can be matched to the index in a reasonable way (eg if you lowercase your search documents you probably also want to lowercase your search terms- so the end result is case insensitive search). It's possible to persist data that was sanitized and tokenized one way and then to later restore it into an instance of js-search configured to sanitize/tokenize another way. I'm not sure if we'd want to guard against this or just warn via documentation. If we wanted to guard against it, we may actually need to move the persist and restore methods up to the top-level search object itself- essentially requiring it to take a snapshot of which tokenizers/sanitizers/index-strategies it was using. However this is tricky in the case of custom/user implementations. (How do I restore an implementation I don't know about?)

For discussion purposes: https://github.com/bvaughn/js-search/pull/17

Interesting to note that using JSON.stringify and JSON.parse to restore the index takes significantly longer than just rebuilding the index- at least with my initial tests. It's over 2x slower for TfIdfSearchIndex and a bit less than 2x slower for UnorderedSearchIndex.

Huh that is interesting. Perhaps this is just premature optimization on my
part :-)
On Wed, Nov 16, 2016 at 3:43 PM Brian Vaughn<EMAIL_ADDRESS>wrote:

Interesting to note that using JSON.stringify and JSON.parse to restore
the index takes significantly longer than just rebuilding the index- at
least with my initial tests. It's over 2x slower for TfIdfSearchIndex and
a bit less than 2x slower for UnorderedSearchIndex.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bvaughn/js-search/issues/16#issuecomment-261109173,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEVhwMW2VfxFfNJE5BDBrxPvlC9n2_4ks5q-5UDgaJpZM4Kx2J0
.

I think using web workers is probably a more promising route for addressing performance concerns 😁 I'm going to close this issue for now as I don't think I plan any further action currently. Happy to discuss it more though!


Option --file: Create (empty) files instead directories on initialization

Done in v0.2.0.
Also option --directory to force directory mode.


added GetAlias type definition

Added the type GetAlias(), which is used by KeyUtils.java (most likely in more places):
https://github.com/jmxtrans/jmxtrans/blob/712b24f4f9e162b8456a15eea87517b5fff9cb66/jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/naming/KeyUtils.java#L97-L106

:x: Build jmxtrans 368 failed (commit https://github.com/jmxtrans/jmxtrans/commit/1e7731307c by @)

:white_check_mark: Build jmxtrans 369 completed (commit https://github.com/jmxtrans/jmxtrans/commit/66c172d672 by @)


HBASE-27444 Add tool commands list_enabled_tables and list_disabled_tables

https://issues.apache.org/jira/browse/HBASE-27444

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+0 :ok:
prototool
0m  0s
prototool was not available.

+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 Compile Tests _

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

+1 :green_heart:
mvninstall
3m  9s
branch-2 passed

+1 :green_heart:
compile
4m 34s
branch-2 passed

+1 :green_heart:
checkstyle
1m 34s
branch-2 passed

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

+1 :green_heart:
spotbugs
5m 17s
branch-2 passed

_ Patch Compile Tests _

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

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

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

+1 :green_heart:
cc
4m 35s
the patch passed

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

-0 :warning:
checkstyle
0m 16s
hbase-client: The patch generated 1 new + 32 unchanged - 0 fixed = 33 total (was 32)

-0 :warning:
rubocop
0m 10s
The patch generated 18 new + 444 unchanged - 0 fixed = 462 total (was 444)

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

+1 :green_heart:
hadoopcheck
13m 14s
Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.4.

+1 :green_heart:
hbaseprotoc
1m 49s
the patch passed

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

+1 :green_heart:
spotbugs
5m 44s
the patch passed

_ Other Tests _

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

50m  5s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool rubocop

uname
Linux e13ec9f25ebc 5.4.0-1085-aws #92~18.04.1-Ubuntu SMP Wed Aug 31 17:21:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

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

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3 rubocop=1.37.1

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 52s
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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 56s
branch-2 passed

+1 :green_heart:
compile
2m  6s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 23s
branch-2 passed

_ Patch Compile Tests _

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

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

+1 :green_heart:
compile
2m  6s
the patch passed

+1 :green_heart:
javac
2m  6s
the patch passed

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 29s
hbase-protocol-shaded in the patch passed.

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

+1 :green_heart:
unit
193m 31s
hbase-server in the patch passed.

+1 :green_heart:
unit
6m 26s
hbase-thrift in the patch passed.

-1 :x:
unit
7m 36s
hbase-shell in the patch failed.

238m 33s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux f11e0ce0b0ea 5.4.0-1088-aws #96~18.04.1-Ubuntu SMP Mon Oct 17 02:57:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-shell.txt

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/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 30s
Docker mode activated.

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

_ Prechecks _

_ branch-2 Compile Tests _

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

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

+1 :green_heart:
compile
2m  4s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 21s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 28s
hbase-protocol-shaded in the patch passed.

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

+1 :green_heart:
unit
196m 32s
hbase-server in the patch passed.

+1 :green_heart:
unit
6m 53s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
9m 36s
hbase-shell in the patch passed.

241m 19s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 2407ddca133a 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Temurin-1.8.0_352-b08

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/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 51s
Docker mode activated.

_ Prechecks _

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

+0 :ok:
prototool
0m  1s
prototool was not available.

+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 Compile Tests _

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

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

+1 :green_heart:
compile
4m 16s
branch-2 passed

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

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

+1 :green_heart:
spotbugs
4m 40s
branch-2 passed

_ Patch Compile Tests _

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

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

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

+1 :green_heart:
cc
4m 17s
the patch passed

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

-0 :warning:
checkstyle
0m 14s
hbase-client: The patch generated 1 new + 32 unchanged - 0 fixed = 33 total (was 32)

-0 :warning:
rubocop
0m  9s
The patch generated 18 new + 444 unchanged - 0 fixed = 462 total (was 444)

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

+1 :green_heart:
hadoopcheck
12m 32s
Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.4.

+1 :green_heart:
hbaseprotoc
1m 36s
the patch passed

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

+1 :green_heart:
spotbugs
5m 16s
the patch passed

_ Other Tests _

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

45m 58s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool rubocop

uname
Linux d172944c271f 5.4.0-1085-aws #92~18.04.1-Ubuntu SMP Wed Aug 31 17:21:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

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

rubocop
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/2/artifact/yetus-general-check/output/diff-patch-rubocop.txt

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3 rubocop=1.37.1

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 27s
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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m  8s
branch-2 passed

+1 :green_heart:
compile
2m  0s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 20s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 27s
hbase-protocol-shaded in the patch passed.

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

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

+1 :green_heart:
unit
6m 49s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
9m 37s
hbase-shell in the patch passed.

240m 18s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 2bfbb49b951a 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Temurin-1.8.0_352-b08

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/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 50s
Docker mode activated.

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

_ Prechecks _

_ branch-2 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 36s
branch-2 passed

+1 :green_heart:
compile
2m  3s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 19s
branch-2 passed

_ Patch Compile Tests _

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

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

+1 :green_heart:
compile
2m  6s
the patch passed

+1 :green_heart:
javac
2m  6s
the patch passed

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 31s
hbase-protocol-shaded in the patch passed.

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

+1 :green_heart:
unit
202m  3s
hbase-server in the patch passed.

+1 :green_heart:
unit
6m 45s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m 36s
hbase-shell in the patch passed.

246m 24s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux d6839ac9632d 5.4.0-1088-aws #96~18.04.1-Ubuntu SMP Mon Oct 17 02:57:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/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.

Please fix the checkstyle issue?

Please fix the checkstyle issue?

OK, sir, I will solve the checkstyle issue with a new commit.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+0 :ok:
prototool
0m  0s
prototool was not available.

+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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 48s
branch-2 passed

+1 :green_heart:
compile
4m 17s
branch-2 passed

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

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

+1 :green_heart:
spotbugs
4m 38s
branch-2 passed

_ Patch Compile Tests _

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

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

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

+1 :green_heart:
cc
4m 18s
the patch passed

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

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

-0 :warning:
rubocop
0m 14s
The patch generated 4 new + 444 unchanged - 0 fixed = 448 total (was 444)

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

+1 :green_heart:
hadoopcheck
12m 45s
Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.4.

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

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

+1 :green_heart:
spotbugs
5m 11s
the patch passed

_ Other Tests _

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

46m 47s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool rubocop

uname
Linux 4618daf0c075 5.4.0-1085-aws #92~18.04.1-Ubuntu SMP Wed Aug 31 17:21:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

rubocop
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/3/artifact/yetus-general-check/output/diff-patch-rubocop.txt

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3 rubocop=1.37.1

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

This message was automatically generated.

Is it possible to also fix the remaining rubocop issues?

Is it possible to also fix the remaining rubocop issues?

@Apache9 sir, One of the rubocop issues is "[Correctable] Style/FrozenStringLiteralComment: Missing frozen string literal comment", do we have a unified solution for this.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 48s
branch-2 passed

+1 :green_heart:
compile
2m  7s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 22s
branch-2 passed

_ Patch Compile Tests _

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

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

+1 :green_heart:
compile
2m  6s
the patch passed

+1 :green_heart:
javac
2m  6s
the patch passed

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 30s
hbase-protocol-shaded in the patch passed.

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

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

+1 :green_heart:
unit
6m 33s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m 39s
hbase-shell in the patch passed.

239m 33s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 68ef020bf49c 5.4.0-1088-aws #96~18.04.1-Ubuntu SMP Mon Oct 17 02:57:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/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 28s
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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 13s
branch-2 passed

+1 :green_heart:
compile
2m  1s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 22s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 26s
hbase-protocol-shaded in the patch passed.

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

+1 :green_heart:
unit
196m 15s
hbase-server in the patch passed.

+1 :green_heart:
unit
6m 53s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
9m 36s
hbase-shell in the patch passed.

240m 21s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 20b0861b20f4 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Temurin-1.8.0_352-b08

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/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.

I added the following content to the .rubocop.yml file to solve the rubocop issue:
"Style/FrozenStringLiteralComment:
Enabled: false"

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+0 :ok:
prototool
0m  0s
prototool was not available.

+0 :ok:
yamllint
0m  0s
yamllint was not available.

+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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 41s
branch-2 passed

+1 :green_heart:
compile
4m 47s
branch-2 passed

+1 :green_heart:
checkstyle
1m 10s
branch-2 passed

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

+1 :green_heart:
spotbugs
11m 11s
branch-2 passed

_ Patch Compile Tests _

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

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

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

+1 :green_heart:
cc
4m 44s
the patch passed

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

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

-0 :warning:
rubocop
0m 10s
The patch generated 1 new + 442 unchanged - 2 fixed = 443 total (was 444)

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

+1 :green_heart:
hadoopcheck
12m 53s
Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.4.

+1 :green_heart:
hbaseprotoc
3m 45s
the patch passed

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

+1 :green_heart:
spotbugs
11m 50s
the patch passed

_ Other Tests _

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

63m  3s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool rubocop yamllint

uname
Linux 15bdc5c328c5 5.4.0-1085-aws #92~18.04.1-Ubuntu SMP Wed Aug 31 17:21:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

rubocop
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/4/artifact/yetus-general-check/output/diff-patch-rubocop.txt

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell . U: .

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3 rubocop=1.37.1

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
1m 16s
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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 50s
branch-2 passed

+1 :green_heart:
compile
1m 53s
branch-2 passed

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

+1 :green_heart:
javadoc
3m 32s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

+1 :green_heart:
javadoc
3m 26s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
255m  7s
root in the patch passed.

287m 58s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 6fcf2f4478f2 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Eclipse Adoptium-11.0.17+8

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/4/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 27s
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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m  5s
branch-2 passed

+1 :green_heart:
compile
1m 31s
branch-2 passed

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

+1 :green_heart:
javadoc
2m 42s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

+1 :green_heart:
javadoc
2m 45s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
315m 15s
root in the patch passed.

342m 54s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 880bbe63cb10 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 71826de852

Default Java
Temurin-1.8.0_352-b08

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/4/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.

The above solution seems to be not working well. I'm looking at how to solve it.

Ah, let's not add the ignore file? I think we can merge the PR first, without fixing all the rubocop issues. Just align the shell code with master branch as much as possible is enough.
Thanks.

Ah, let's not add the ignore file? I think we can merge the PR first, without fixing all the rubocop issues. Just align the shell code with master branch as much as possible is enough.
Thanks.

@Apache9 OK, sir.  I have a new commit, please wait for the UT execution to complete.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+0 :ok:
prototool
0m  0s
prototool was not available.

+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 Compile Tests _

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

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

+1 :green_heart:
compile
4m 38s
branch-2 passed

+1 :green_heart:
checkstyle
1m 29s
branch-2 passed

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

+1 :green_heart:
spotbugs
5m 12s
branch-2 passed

_ Patch Compile Tests _

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

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

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

+1 :green_heart:
cc
4m 33s
the patch passed

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

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

-0 :warning:
rubocop
0m 21s
The patch generated 4 new + 444 unchanged - 0 fixed = 448 total (was 444)

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

+1 :green_heart:
hadoopcheck
12m 51s
Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.4.

+1 :green_heart:
hbaseprotoc
1m 36s
the patch passed

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

+1 :green_heart:
spotbugs
5m 13s
the patch passed

_ Other Tests _

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

49m  5s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool rubocop

uname
Linux f1b17868ffa8 5.4.0-1085-aws #92~18.04.1-Ubuntu SMP Wed Aug 31 17:21:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / ad8d38b61f

Default Java
Eclipse Adoptium-11.0.17+8

rubocop
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/5/artifact/yetus-general-check/output/diff-patch-rubocop.txt

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3 rubocop=1.37.1

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 25s
Docker mode activated.

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

_ Prechecks _

_ branch-2 Compile Tests _

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

+1 :green_heart:
mvninstall
2m  9s
branch-2 passed

+1 :green_heart:
compile
1m 59s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 21s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 26s
hbase-protocol-shaded in the patch passed.

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

+1 :green_heart:
unit
195m 32s
hbase-server in the patch passed.

+1 :green_heart:
unit
6m 53s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
9m 35s
hbase-shell in the patch passed.

239m 36s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 69e6a24cfe4a 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / ad8d38b61f

Default Java
Temurin-1.8.0_352-b08

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/5/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.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 15s
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 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 45s
branch-2 passed

+1 :green_heart:
compile
2m 21s
branch-2 passed

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

+1 :green_heart:
javadoc
1m 36s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

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

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

-1 :x:
unit
208m 37s
hbase-server in the patch failed.

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

+1 :green_heart:
unit
7m 52s
hbase-shell in the patch passed.

256m 29s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 993dfd4cc156 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / ad8d38b61f

Default Java
Eclipse Adoptium-11.0.17+8

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/5/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4880/5/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.


Prompt testing

Proposal
I would love to be able to add prompt test data and expected results for each prompt commit version. A lot of value in the ability to run that on a regular basis along with my other tests.
Use-Case
No response
Is this a feature you are interested in implementing yourself?
No

Hi @ericflecher, really appreciate your involvement and issues. It really helps.
I can clearly see the value in automated tests. The question is, what exactly do we want to test? The nature of the AI models is that the response might change from time to time.
I can think of the ability to define a strict JSON response schema (e.g. this field should be a number, this field should be a string, and so on) and validate it. Would that be useful?
Can you try to think of a concrete example?

@arielweinberger "The nature of the AI models is that the response might change from time to time.", yes, unless you construct the prompt the way that it should return always the same and so with the extremely low probability it will be possible to return something different.
Of course, OpenAI (and some other companies) did not guarantee that, but sending simple requests like:
What was the capital of France in 2022?
Please answer just a city name, capitalized, and don't add anything else.
One world, please!

Will return "Paris" with a probability of 100% minus infinitesimal ;)
So I think such prompts can easily be used in basic tests (but I could be wrong haha)

I've been struck pretty hard in one of my AI powered product when giving perfectly accurate instructions with 0 temperature.
An example is "return the following text's language in ISO-639-2 format".
I'd get a different format sometimes.
I think this highlights the relevance of this testing feature, so we'll add it to our roadmap.

The approach we came up with is kinda two step which includes a special proxy.
Maybe pezzo can stand in for that proxy.
What we do at the moment when we run our unit tests is that we run them ONCE against real LLM through a special proxy. That proxy hashes all parameters and prompt and what it's exactly the same parameters and prompts it won't call url and instead return value from the proxy.
Proxy also helps to speed up our integration tests and avoid paying openai every time we push a commit.
When we change either parameters or prompt itself proxy will call real LLM and tests will be able to verify that the changes didn't break anything.


Typo "@job_name"→"@job_name"

Bold with escape characters
https://docs.microsoft.com/sr-latn-RS/sql/relational-databases/replication/publish/create-a-publication?view=sql-server-2014

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Typo: Github should be GitHub

Product and Version [VS/VSCode]: VSCode 1.45.0
OS Version [macOS/Windows]: macOS Catalina
Live Share Extension Version: 1.0.2106
Target Platform or Language [e.g. Node.js]:
Steps to Reproduce / Scenario:

Click the Live Share button on the status bar of VS Code

Fixed. Thank you.


Search button to be added to the grant list page

Add ability to search for a specific grant on the list page.

Completed.  👍


[2023b] Fix naming for R Studio Server

Description
Cherry-pick from main branch.
https://github.com/opendatahub-io/notebooks/pull/407#issuecomment-1935367373

Merging as this is cherry-pick.


Upload multipart/form-data request body: None

Trying to upload an image to a server where a payara instance is running.
func upload(image: UIImage, guid: String, completionHandler: @escaping (String) -> Void) {
        let userDefaults = UserDefaults.standard
        let accessToken = userDefaults.string(forKey: "access_token") ?? ""

        let parameters = ["name": "bild", "Content-Type": "image/png"]

        let url = URL(string: "http://<<<upload-url>>>")!

        let imgData = image.pngData()!
        AF.upload(multipartFormData: { multiPart in
            multiPart.append(Data("one".utf8), withName: "one")
            multiPart.append(imgData, withName: "file", fileName: "file.png", mimeType: "image/png")
            for (key, value) in parameters {
                multiPart.append(value.data(using: String.Encoding.utf8)!, withName: key)
            }
        }, to: url, method: .post, interceptor: AFRequestInterceptor(accessToken: accessToken))
        .uploadProgress(queue: .main, closure: { progress in
            //Current upload progress of file
            print("Upload Progress: \(progress.fractionCompleted)")
        })
        .response(completionHandler: { response in
            debugPrint(response)
        })

        completionHandler("return")
    }

Request:
[Request]: POST <url>
    [Headers]:
        Authorization: xxx
        Content-Type: multipart/form-data; boundary=alamofire.boundary.ca7b646417cec685
    [Body]: None

Alamofire version: 5.4.1
Xcode version: 12.3
Swift version: 5.x
Platform(s) running Alamofire: iOS
macOS version running Xcode: 11.1

Uploads don't use the URLRequest body for their Data, it's directly streamed from memory or disk. We could enhance the  debug description to show whether there's a stream attached to the URLRequest, but really you want to use a network inspector or proxy to see what's really going over the network.

Uploads don't use the URLRequest body for their Data, it's directly streamed from memory or disk. We could enhance the  debug description to show whether there's a stream attached to the URLRequest, but really you want to use a network inspector or proxy to see what's really going over the network.


CUDOS cur_new.json missing resource_tags_user_project

I believe we may be missing some resource_tags_user_* tags from the cudos_cur dataset creation. Looks like at least resource_tags_user_project is missing from the json in  aws-cudos-framework-deployment/cudos/dataset-templates/cur_new.json
I believe this may cause issues when customers attempt to populate the Tagsplorer portion of the dashbaord if they are looking for 'project' tag

after investigating further, perhaps what is really needed is a way to query the user created tags and populate the cur_new.json file with all customer created tags to ensure they are all included in the QuickSight dashboards.

Tag fields are populated by Glue crawler to Athena table. To get them appear in cudos_cur dataset the only thing is needed is to open dataset in QuickSight and save it. Once done all tag fields will be available in analysis to be used in Tagsplorer


Consider renaming vsync in AnimationController to tickerProvider

From the Animation API UX study, developers had trouble understanding what vsync meant and how it was related to TickerProvider, when they were defining an AnimationController object. It would be clearer to rename the vsync property to tickerProvider, so Flutter only introduces one new concept instead of two to developers new to the animations API.

@Hixie, is this something we can consider?

Yeah, totally.

+1

This would be a good thing to add to https://github.com/flutter/flutter/issues/24722

@Hixie I added this issue to #24722.


compile is obsolete and needs to be replaced

compile ('com.microsoft.identity.client:msal:0.1.+') {
exclude group: 'com.android.support', module: 'appcompat-v7'
}
compile 'com.android.volley:volley:1.0.0'

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: aecf9610-b6e2-75fc-a674-869d9b95702c
Version Independent ID: 360def71-eacf-185b-4f6d-41e60e57e610
Content: Azure Active Directory v2.0 Android getting started
Content Source: articles/active-directory/develop/tutorial-v2-android.md
Service: active-directory
Sub-service: develop
GitHub Login: @danieldobalian
Microsoft Alias: dadobali

@mahoekst
Thanks for your feedback! We will investigate and update as appropriate.

@danieldobalian
Daniel, could you kindly verify the customer's suggestion ?

Please assign to @CelesteDG so she can triage appropriately.

Thank you very much for the feedback, @mahoekst
We retested and updated the tutorial in July and the latest and greatest is what we’ve got live now. Thank you.
#please-close


Added MySQL Shell 8.0.28

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.0 schema?

Could not validate and test mainfest locally.
Microsoft Reviewers: Open in CodeFlow

This package has a dependency -
MSI (s) (0C:30) [09:24:50:801]: Product: MySQL Shell 8.0.28 -- This application requires Visual Studio 2019 Redistributable. Please install the Redistributable then run this installer again.

This application requires Visual Studio 2019 Redistributable. Please install the Redistributable then run this installer again.

@denelon - Blocking-Issue; Dependencies

Ok that explains why I can't find any documentation about dependencies. A package manager that isn't able to resolve dependencies?

Ok that explains why I can't find any documentation about dependencies. A package manager that isn't able to resolve dependencies?

Winget is still quite new in the realm of software and dependencies are a surprisingly complex topic. Between dependencies on windows features, specific libraries, program dependencies, dependencies that require a specific architecture, one-of-many dependencies, group policy requirements, there is a lot to consider. Especially given that the solution needs to be well planned to cover a majority of scenarios, it makes it even more complex.
As Levvie mentioned, it has been in experimental features and you can add it to the manifest so that once the support for dependencies is finalized then it can be merged

I didn't wanted to start a fight. And we all know thats Windows' software installation routines are fubar, hopefully the software will fix this.

I didn't wanted to start a fight.

Apologies if I came off harsh. I like to give as much background into issues as possible so that everyone understands the full picture.

And we all know thats Windows' software installation routines are fubar

I think that is an understatement. In making things easy for everyone in the past, it has made it more difficult now

hopefully the software will fix this.

I’m sure it will. It seems that a lot of things planned for the 1.4 client release will help a lot

// Edit: does it make sense to add those fields to the yaml files or is it better to wait?

Its up to you. There isn’t a set timeline of when the support will be enabled in the validation pipelines. I would personally add it now just so that it isn’t something that has to be worried about later, but it really doesn’t make a difference if its now or later

Thanks. I'll wait till this feature is available to everyone and documentation is ready.

Since we now have support for dependencies I'll close this PR and will re-submit it with a newer version of the MySQL Shell.
Btw: I hope Microsoft will invest more resource in Winget, as this is the best thing what happend to Windows ever.


zstd: Add zstd_cli cc_binary

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (zstd) have been updated in this PR. Please review the changes.

This should be the minimal changes to allow building the zstd binary.
However I'd like to have our BUILD.bazel files follow the zstd upstream BUCK files in structure so we don't deviate too much (say, @zstd//programs:zstd instead of @zstd//:zstd_cli), at the cost of bumping the compatibility level. Thoughts?
cc @jondo2010 @lalten as you contributed previous versions

Bumping the compatibility level could be quite disruptive to users of the library. Could you leave an alias in place instead?

I'm fine with aliasing

the diff of the BUILD is
3c3
< index 00000000..7fca1671
---
> index 00000000..f0a5da7e
6c6
< @@ -0,0 +1,127 @@
---
> @@ -0,0 +1,148 @@
73a74,94
> +)
> +
> +cc_binary(
> +    name = "zstd_cli",
> +    srcs = glob(
> +        include = [
> +            "programs/*.c",
> +            "programs/*.h",
> +        ],
> +        exclude = [
> +            "programs/datagen.c",
> +            "programs/datagen.h",
> +            "programs/platform.h",
> +            "programs/util.h",
> +        ],
> +    ),
> +    deps = [
> +        ":datagen",
> +        ":util",
> +        ":zstd",
> +    ],

It really is a shortcoming of the separate version dirs in the BCR that you can't easily see what's changed between versions :(

Why do you need to bump the compatibility level to add @zstd//programs:zstd if you keep @zstd//:zstd` the same? One easy way would be to just patch in a separate BUILD in the programs dir

https://github.com/bazelbuild/bazel-central-registry/pull/1730#issuecomment-2031266163 If you mean only create the @zstd//programs:zstd in @zstd//programs and keep the rest as-is, the asymmetry of @zstd//:datagen_cli  and @zstd//programs:zstd bugs me a bit. If you mean following upstream BUCK files, move everything to sub-packages and leave top level aliases, then yeah I agree it should work.
So far it seems like bumping the compatibility level causes more trouble then it's worth (maintenance, hiding @zstd//:*_sources filegroups, etc), so I'll stop pursuing bumping.

@fmeum could you help review this PR at its current state (no structure or any compatibility level changes)? Thanks!


Fix for HHH-4235

This issue is from 2010 and remains unfixed (https://hibernate.atlassian.net/projects/HHH/issues/HHH-4235)
PS: Please backport to 5.4.X? :)

Thanks, will it be back-ported to 5.4?

thanks to you for the fix, I pushed it on master branch so it will be part of the next 5.4.7 release


[Feature Request]: Adding multilanguage in admin panel

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
I will implement the multi language functionality in admin panel so that in future or in current if the admin changes other admin can manage the dashboard without having any language barriers.
So, i will implement this feature similar to that of style share app.
Use Case
Multi Language
Benefits
removing Language barrier
Add ScreenShots

Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@VaibhavArora314 I will implement this feature when the all admin features are completed. so, that again and again language will not change and the result will be at the end and completed.

But in future if admin changes in that scenario !

But in future if admin changes in that scenario !

ok, sure


Coin Change [C++]

This issue is about Coin Change [C++] (https://www.geeksforgeeks.org/understanding-the-coin-change-problem-with-dynamic-programming/).

[x] Issue Title is in form Algo/DS Name [Language].
[x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
[x] This Algo/DS is worth adding to this repository.
[x] Assign this issue to me (I want to work on this).

[x] I ensure that I am not already assigned to 2 or more issues.

[x] I will send my PR only after I'm assigned to this issue by any maintainer.
[x] I understand that I will be unassigned from this issue if I fail to send a PR for this within a week.

@iiitv/project-maintainers I want to work on this issue

@darshanhande11 don't add geeks-for-geeks or any other links instead add the link where the algorithm will be updated or added in the algos repository

@yashshah2820 Sir, I have updated the link. Is the link correct now?

we already have a code implemented in C, having a CPP code will not make much difference, you work on other issues 😄

okay sir.


Fix documentation of _get_temperature_from_buffer

Fix incorrect numbers in the function documenting _get_temperature_from_buffer and removes a superfluous "=" sign.

The extra = is supposed to be a - not an =

Woops, you are right, I'll update this PR. In my library I moved the -46.85 part to the end of the formula since it feels more natural for me.


clarify Apache Maven vs individuals

Clarification of Apache Maven in a few places.
I tried to clarify that individuals involved in this project will work as normal Apache Maven contributors
One remaining TODO to me is clarifying that funding is done for individuals (which ones?), not for the Apache project itself

Guess something like "this project will found companies to let them involve Apache Maven contributors to work on Apache Maven" is closer to the reality since ultimately there is always a company hat between this and contributors?

@hboutemy @rmannibucau I suggested some changes that focus on funding of project contribution. I dislike to speak about funding of individuals (or companies). While they will get the money it could be read in a negative way. Hope you like my suggestions.

One remaining TODO to me is clarifying that funding is done for individuals (which ones?), not for the Apache project itself

Totally fine for me to add that information.
Suggestion to add the following to the end of the file:
Relation to The Apache Software Foundation
Support&Care for Apache Maven is not related in any way to The Apache Software Foundation. This means that all resources that are managed by Support&Care for Apache Maven are not resources of The Apache Software Foundation or resources that are managed by The Apache Software Foundation.
On the other hand, the Support&Care for Apache Maven initiative would not be possible without the support of The Apache Software Foundation. Based on that, one of our main concerns is to never act against any decisions of The Apache Software Foundation.
Trademark
Apache™ and Apache Maven™ are trademarks of The Apache Software Foundation.

IMHO, we can merge this PR and continue the improvements: step by step

IMHO, we can merge this PR and continue the improvements: step by step

LGTM, leaving the final decision to @hendrikebbers.


selinux: allow cert_t:dir search

I saw this AVC denial when I tried setting up a cluster in enforcing
mode. It caused Ansible to fail to authenticate to the cluster nodes.

@b-ranto

Everything else worked ok in enforcing, and the cluster came up to HEALTH_OK

lgtm

I'll tag/release v1.0.14 with this change


feat(oxc_parser): Parse modifiers before declaration

Addresses #66, now we can correctly parse typescript declarations with modifiers like protected class {}. Also modifiers are given their own AST node so that we could give out more informative diagnostics like modifier public cannot appear in an index signature in the future.

One small comment and we will be good to go.

@YangchenYe323 Can you take a look at how TypeScript parses these and then make a decision? Things get super complicated when we start looking at error recoveries so let's not rush it.

@Boshen I took another look and decided to replace all declare, abstract fields in the AST nodes with a unified modifier property once and for all, since they are typescript-only properties anyway.
One exception is the r#async property of a function. Since javascript functions are handled separately and doesn't have the concept of modifiers, I kept that property. For typescript parsed functions, r#async is guaranteed to be consistent with its modifiers.
I feel good about the AST modification this time. The parser is modified to ensure that typescript export declarations are handled separately from javascript ones. The following code:
export class A {}

is parsed by tsc to a ClassDeclaration with a modifier export. Babel parses it to an ExportNamedDeclaration. I preserved this behavior in oxc.

The code is good, but I don't really like how TypeScript just throw everything together ... How is the readers (beginners like us) of the AST going to know which modifier is valid or not without search through the TypeScript docs?

Maybe comment heavily on what's valid?
Eventually there will be a linter rule that checks for TypeScript syntax errors, I don't want people to dig through the TypeScript docs to find out what is valid or not 🥲

nitpick: use /// triple slash for doc comment

@YangchenYe323 Last question,

The following code:
export class A {}

is parsed by tsc to a ClassDeclaration with a modifier export. Babel parses it to an ExportNamedDeclaration. I preserved this behavior in oxc.

I just looked at the code, we need to keep ExportNamedDeclaration, our AST is still 98% estree, not TypeScript's AST.
We need ExportNamedDeclaration because we need to visit ModuleDeclaration -> ExportNamedDeclaration in the correct order.
ModuleDeclaration is always top level, it is used for a few things, e.g.

determine if the current script is a module (see babel unambiguous mode)
build up a ModuleRecord for import / export semantics (This is part of the ecma spec)

@YangchenYe323 Last question,

The following code:
export class A {}

is parsed by tsc to a ClassDeclaration with a modifier export. Babel parses it to an ExportNamedDeclaration. I preserved this behavior in oxc.

I just looked at the code, we need to keep ExportNamedDeclaration, our AST is still 98% estree, not TypeScript's AST.
We need ExportNamedDeclaration because we need to visit ModuleDeclaration -> ExportNamedDeclaration in the correct order.
ModuleDeclaration is always top level, it is used for a few things, e.g.

determine if the current script is a module (see babel unambiguous mode)
build up a ModuleRecord for import / export semantics (This is part of the ecma spec)

Do we need to keep ExportNamedDeclaration in .ts files, too? Javascript is still parsed in the old way.

Let's align with estree, not ts's AST.

Fixed. Would you like to take another look?

Amazing work! Thank you for bearing with me.

Parser Benchmark Results - ubuntu-latest
group                    main                                   pr
-----                    ----                                   --
parser/babylon.max.js    1.00    120.4±1.64ms    85.7 MB/sec    1.01    121.4±1.43ms    85.1 MB/sec
parser/d3.js             1.00     [14](https://github.com/Boshen/oxc/actions/runs/4310880831/jobs/7519743826#step:11:15).6±0.[17](https://github.com/Boshen/oxc/actions/runs/4310880831/jobs/7519743826#step:11:18)ms    37.4 MB/sec    1.01     14.8±0.26ms    37.0 MB/sec
parser/lodash.js         1.00      4.1±0.05ms   123.9 MB/sec    1.01      4.2±0.07ms   122.7 MB/sec
parser/pdf.js            1.00      8.3±0.03ms    48.4 MB/sec    1.00      8.3±0.05ms    48.3 MB/sec
parser/typescript.js     1.00    1[20](https://github.com/Boshen/oxc/actions/runs/4310880831/jobs/7519743826#step:11:21).6±0.26ms    79.8 MB/sec    1.01    1[21](https://github.com/Boshen/oxc/actions/runs/4310880831/jobs/7519743826#step:11:22).6±0.39ms    79.1 MB/sec

Benchmark results for future reference.


rulesheet middleware skips empty @keyframes

serialize(compile('@keyframes test-animation {}'), middleware([
  stringify,
  rulesheet((rule) => {
    console.log(rule);
  })
]));

Expected behavior: @keyframes test-animation {} is logged in console. Current behavior: nothing is logged.
Use case: Material-UI uses empty animations to detect autofill in text fields (see the issue in Material-UI).

@thysultan I'm slightly on the fence here but I'm leaning towards being in favor of handling this in Stylis. I feel like the main reason why we don't inject empty rules is that we always end up with a slot for rules in the output, even if there are no rules for this particular level of nesting. This happens because we don't lookahead to check if there are any rules ahead of us (doing that would be obviously bad) nor we don't want to track if the slot has been already created or not - it's always created roughly when { gets encountered and this simplifies the code that follows that.
This makes sense for regular rules but @keyframes are conceptually different - they are always "top-level" rules, so if one writes a definition for them then it might act as a clear signal that the output for it should be produced.


Allow variable substitution in extension, workplace, and other settings files.

I work on Windows and we usually have at least two windows repos on our dev machines that have their own set of build settings. I like to create workplaces for parts of the code that I work on often or I am working on in that moment. It would be nice to not have to create workplace files for each repo and each build flavor that I use. e.g. in my .code-workplace file (... is just committing part of the path):
"folders": [
{
"path": "${env:SDXROOT}/onecoreuap/.../lib"
},
{
"path": "${env:SDXROOT}/.../winrt"
}
],
...
"C_Cpp.default.includePath": [
"${workspaceFolder}",
"${env:SDXROOT}/...",
"${env:SDXROOT}/.../published/winrt",
"${env:SDXROOT}/onecoreuap/.../inc",
"${env:OBJECT_ROOT}/onecore/.../${env:O}",
"${env:SDXROOT}/onecore/published/inc"
],
This way vscode would be configured based on what build window and repo I opened it in.
Thanks!

@irvinec Are you looking for variable substitution for folders section or in other sections too? For me, from Description it looks to me only for folders?


Failing to build

I am running dotnet run and  dotnet publish -c Release -r win-x64 --self-contained -f netcoreapp3.1 -o bin\publish\net3.1-win-x64-release in PatreonDownloader.App directory in powershell. None of the commands create the bin directory.

I can't help you unless you post a build log.

Hi, sorry about that. please see attached for piped output from cmd for the following commands: dotnet run, dotnet build and  dotnet publish -c Release -r win-x64 --self-contained -f netcoreapp3.1 -o bin\publish\net3.1-win-x64-release
dotnetrun.txt
dotnetbuild.txt
dotnetpublish.txt

It looks like you don't have .NET Core 3.1 SDK installed

I do, according to the --list-sdks and --list-runtimes parameters.
PS C:\Users\ant72\Downloads\PatreonDownloader-dev\PatreonDownloader.App> dotnet --list-runtimes
Microsoft.AspNetCore.All 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
PS C:\Users\ant72\Downloads\PatreonDownloader-dev\PatreonDownloader.App> dotnet --list-sdks
3.1.402 [C:\Program Files\dotnet\sdk]

Honestly, I'm not sure what is going on. For some reason it tries to use .NET framework packages instead of .NET Core. Try running dotnet restore before running other commands. Also make sure nuget is working correctly on your computer.

How would I go about making sure nuget is working correctly?


Add gribi feature textproto

Pull Request Functional Test Report for #1772 / e745c5d99b70749a53cad589699d8e0790e10f9f
No tests identified for validation.
Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 47.739%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1341

Relevant Lines:
2809

💛  - Coveralls

@xw-g
It appears that this PR is failing the Validate OpenConfig Paths check. The error seems to be:
file: /home/runner/work/featureprofiles/featureprofiles/feature/gribi/feature.textproto
line 36: missing from YANG "/network-instances/network-instance/afts/next-hop-groups/next-hop-group/next-hops/next-hop/state/id"
line 63: missing from YANG "/network-instances/network-instance/afts/next-hops/next-hop/state/ip-in-ip/state/src-ip"
line 66: missing from YANG "/network-instances/network-instance/afts/next-hops/next-hop/state/ip-in-ip/state/dst-ip"


[Model Request] 3 bit, 7B Luna-AI-Llama2-Uncensored-GGML

⚙  Request New Models

Link to an existing implementation (e.g. Hugging Face/Github): https://huggingface.co/TheBloke/Luna-AI-Llama2-Uncensored-GGML
Is this model architecture supported by MLC-LLM? (the list of supported models) Yes

Additional context
Hi,
I've tried running this model on my iPhone 13 Pro Max, but it crashes instantly:
https://huggingface.co/mlc-ai/mlc-chat-llama2-7b-chat-uncensored-q4f16_1
However, this one runs really well:
https://huggingface.co/mlc-ai/mlc-chat-Llama-2-7b-chat-hf-q3f16_1
I think 7b-chat-uncensored would work as well if it were quantized at 3 bits instead of 4. Would you be able to add it to your HuggingFace space?
I'm also open to doing this myself but the last time I tried, quantization did not work on my M1 MacBook using llama.cpp.

I compiled it for you, just add this URL to download the model and it should work:
https://huggingface.co/acalatrava/mlc-chat-luna-ai-llama2-7b-chat-uncensored-q3f16_1
#692

@acalatrava Thank you!
Unfortunately, it crashes instantly on load for me.
I don't know how to debug this since I don't see any error message. I'm guessing it's OOM, but the "censored" model ran fine so I'm not sure what it is...

My bad... The problem is that the public MLC-LLM iPhone app does not have the library for this model, so when you load this model it will crash because it won't find the library for it. Every time you create a model you have to package the app with the library for that model. If you have a Mac you should be able to compile the app and install it by following the instructions on the docs.

@acalatrava This worked, thank you! 🙌

Great! It seems that I should read the docs too since it’s explained here https://mlc.ai/mlc-llm/docs/get_started/mlc_chat_config.html#configure-mlc-chat-json 😅

Great model! Thank you!

Hi @acalatrava
can you please make a q4f16_1 version of luna-ai-llama2-7b-chat-uncensored?
i want to use it on an Android phone and the app does not support 3bits quantization unlike the IOS app.


copy_data should be a member function of Datatype

Datatype handles destroy_data, but not copy_data.
It should and this should be used in Reference_expression::copy_value for example.

In GitLab by @ksiero on Feb 3, 2022, 14:10
Will help, the Expression should use it also

@ksiero , I believe !418 solves this, doesn't it?


Unable to connect through RDP: Connection reset by peer

Operating system
Fedora Linux 40 (Workstation Edition)
Description
When connecting to docker container (through localhost:3389, localhost:8006) with RDP protocol using Remmina, Gnome Connections, and freerdp, it says [12:11:26:983] [6325:000018ba] [ERROR][com.freerdp.core.transport] - [transport_read_layer]: BIO_read returned a system error 104: Connection reset by peer
Docker compose
# For documentation, FAQ, additional configuration options and technical help, visit: https://github.com/dockur/windows

name: "winapps" # Docker Compose Project Name.
volumes:
  # Create Volume 'data'.
  # Located @ '/var/lib/docker/volumes/winapps_data/_data' (Docker).
  # Located @ '/var/lib/containers/storage/volumes/winapps_data/_data' or '~/.local/share/containers/storage/volumes/winapps_data/_data' (Podman).
  data:
services:
  windows:
    image: dockurr/windows # https://hub.docker.com/r/dockurr/windows
    container_name: WinApps # Created Docker VM Name.
    environment:
      # Version of Windows to configure. For valid options, visit:
      # https://github.com/dockur/windows?tab=readme-ov-file#how-do-i-select-the-windows-version
      # https://github.com/dockur/windows?tab=readme-ov-file#how-do-i-install-a-custom-image
      BOOT_MODE: "windows_plain"
      VERSION: "tiny11"
      RAM_SIZE: "4G" # RAM allocated to the Windows VM.
      CPU_CORES: "4" # CPU cores allocated to the Windows VM.
      DISK_SIZE: "40" # Size of the primary hard disk.
      DISK_FMT: "qcow2"
      #DISK2_SIZE: "32G" # Uncomment to add an additional hard disk to the Windows VM. Ensure it is mounted as a volume below.
      #USERNAME: "Docker" # Uncomment to set a custom Windows username. The default is 'Docker'.
      #PASSWORD: "" # Uncomment to set a password for the Windows user. There is no default password.
      HOME: "${HOME}" # Set path to Linux user home folder.
    privileged: true # Grant the Windows VM extended privileges.
    ports:
      - 8006:8006 # Map '8006' on Linux host to '8006' on Windows VM --> For VNC Web Interface @ http://<IP_ADDRESS>:8006.
      - 3389:3389/tcp # Map '3389' on Linux host to '3389' on Windows VM --> For Remote Desktop Protocol (RDP).
      - 3389:3389/udp # Map '3389' on Linux host to '3389' on Windows VM --> For Remote Desktop Protocol (RDP).
    stop_grace_period: 120s # Wait 120 seconds before sending SIGTERM when attempting to shut down the Windows VM.
    restart: on-failure # Restart the Windows VM if the exit code indicates an error.
    volumes:
      - data:/storage # Mount volume 'data' to use as Windows 'C:' drive.
      - ${HOME}:/shared # Mount Linux user home directory @ '\\host.lan\Data'.
    devices:
      - /dev/kvm # Enable KVM.

Docker log
❯ Starting Windows for Docker v3.12...
❯ For support visit https://github.com/dockur/windows
❯ CPU: 11th Gen Intel Core TM i5 1135G7 | RAM: 13/16 GB | DISK: 74 GB (btrfs) | HOST: 6.9.11-200.fc40.x86_64...
❯ Detected that the version was changed, but ignoring this because Windows is already installed.
❯ Please start with an empty /storage folder, if you want to install a different version of Windows.
❯ Booting Windows using QEMU v8.2.4...
3h3h3hBdsDxe: loading Boot0004 "Windows Boot Manager" from HD(1,GPT,96D84048-43BD-4EDA-9D81-08A156209F4C,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0004 "Windows Boot Manager" from HD(1,GPT,96D84048-43BD-4EDA-9D81-08A156209F4C,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
❯ Windows started succesfully, visit http://localhost:8006/ to view the screen...
Screenshots (optional)
No response

I get a (likely) similar issue when I try to connect via rdp to a podman created instance.
https://github.com/dockur/windows/issues/616#issuecomment-2258929693

Maybe you need to try mstsc that is built-in (windows)

Try a different RDP client
Like Remmina (install with sudo apt install remmina)

Try a different RDP client Like Remmina (install with sudo apt install remmina)

That in fact, did not help.
https://github.com/user-attachments/assets/0d3df9ab-0f96-4cee-9011-949e89918cf8

Try a different RDP client Like Remmina (install with sudo apt install remmina)

I'm on a silverblue based system (bazzite) so I don't have apt.  But I did the ostree method for overlaying remmina and tried that as well as the flatpak of remmina, neither method worked on linux, though my Macbook and Android phone can connect to the windows container via rdp.

Ran into this issue as well using podman, will see if docker does not have this issue, I've tried Remmina, xfreerdp (version 2 and 3), and also tried to run netexec rdp.
I saw this :
RDP         <IP_ADDRESS>       3389   <IP_ADDRESS>        [*] Probably old, doesn't not support HYBRID or HYBRID_EX ({nla})

I'm also affected by this.

Try connecting to the vnc or rdp from a different machine on your meteor by using the machine ip an the router

That seems to work @Moon1moon but only in the shell spawned from
podman unshare --rootless-netns

Then inside that shell, you can connect using xfreerdp and it does work with podman.
I had to specify (under NixOS with a shell managed by Home-Manager, else it was failing to enter the new shell)
SHELL=/bin/sh podman unshare --rootless-netns

with the following error :
Error: fork/exec /run/current-system/sw/bin/zsh: no such file or directory

The issue appears to be related to /dev/tun. using a podman run command without passing in the /dev/tun device or using --privileged causes the container to fall back to user mode networking, you will get the following error:
❯ Warning: falling back to usermode networking! Performance will be bad and port mapping will not work.
if you get this error you can now connect via RDP.
if you use --privileged and the /dev/tun device is used then you wont get this error and RDP will not work (connection refused). noVNC on port 8006 still works though.


Initial release plans for cosign

I reeallly want to try to sign the first release of cosign, with cosign, if we can figure out a way that makes sense.
I think we'll have to do it manually, since we won't have a signed release to use in automation yet though. Thankfully we can skip some of the issues with reproducible builds.
Here's a rough plan:
The trick is that we can use Go to build a reproducible binary.

Setup github actions to build and publish a cosign binary on each commit to main

cosign builds should be reproducible, with some care.
We'll make these build logs public, showing the sha of each binary we build.

One or more of us will generate keys specific to this initial release.

The more the merrier!
We can commit these public keys to a file here in the repo.

We can pick a commit to tag our initial release at.

We'll have several of us build our own versions of cosign from it, and check the SHAs against the ones from the GitHub action. We can publish those in an issue.

If they match, we can tag the release. We'll then sign the first binaries and git tag (v0.1.0)!

We'll publish the signatures in Rekor and in the GitHub release.

The keys to verify the release will be included in the git repo at the matching commit!

After this, we can change our automation to use it's own public/private key-pair (also stored in this repo), and the last signed cosign binary release (v0.1.0) in CI to sign continuous builds. Signatures can get published to Rekor, the build log, and wherever we host the binaries.
Actual tagged releases will also be signed by the automation, and one or more maintainers. We'll sign the git commits as well as the resulting binaries. These can get published to the GitHub release. These public keys (and their mapping to maintainers) will also be stored in the repo.
We can write a verification script to help people verify.

Setup github actions to build and publish a cosign binary on each commit to main

Won't this make the repo quite difficult for new contributors trying to clone? Since we wouldn't want to rewrite the history in the future in a project like this, I think this is something to avoid?

Won't this make the repo quite difficult for new contributors trying to clone? Since we wouldn't want to rewrite the history in the future in a project like this, I think this is something to avoid?

Sorry! I think that wasn't clear. How about: "publish a binary to  after each commit to main"?
Not things back into main :) I mean we should publish CI builds somewhere (GCS, Github artifacts) after each build.

All done here! Release 2 coming soon :)


Platform: create Confirmation of funds IDM intent object

Description
IDM needs to manage consent objects to support the Confirmation of funds consent journey.

Object: fundsConfirmationIntent

{
"OBIntentObjectType": "OBFundsConfirmationConsentResponse1",
"OBIntentObject": {OBFundsConfirmationConsentResponse1}
}

Tasks

[ ] The specification of the managed object represents the OBFundsConfirmationConsentResponse1 object in the OB Specifications here
[ ] Define the custom object json object in here
[ ] Check that the configurator has deployed the new managed object to IDM.

Acceptance criteria

[ ] The IDM intent object has been defined in the initialiser.
[ ] The IDM intent object is created properly in IDM with all expected fields.

Now the consents are stored in MongoDB and we not need any more IDM objects for this kind of Consent.


add dismissOnTap to options

basically this option use for confirmation toast or something like that.

@hossinasaadi Thank you for your contribution! Very useful addition. 👍


Sort bags wrong sort order

tDF sorting sorts the bag in a weird way.
Sorting the bag with tDF:

Sorting the bag with Cleanup:

Tested, I can confirm it's fixed.


Oracledb CLOB not working on .returning()

Environment
Knex version: 0.21.4
Database + version: Oracle 12C
OS: Windows 10 x64
If issue is about oracledb support, tag @atiertant.
Bug

Explain what kind of behaviour you are getting and how you think it should do
I'm running a simple insert with a returning, the table has a CLOB column, and while a select returns the CLOB field normally,     the returning function just gives me the error that the OUT binds is too small. If I remove the returning, works fine, if I call a select right before the insert, works fine too...
My Knex has the configuration fetchAsString for the CLOB columns.

Error message
NJS-016: buffer is too small for OUT binds

Reduced test code, for example in https://npm.runkit.com/knex or if it needs real
database connection to MySQL or PostgreSQL, then single file example which initializes
needed data and demonstrates the problem.
     ` knex.returning(['id', 'clob_column']).insert(values) .into('table');`

No solution for this issue? I'm having the same problem with an Oracle DB and .returning clause.
Trying to get a text back and same error NJS-016: buffer is too small for OUT binds .


correct shot loop

Description

Bracket error corrected in short version of SOBR extent query
Related Issue

Motivation and Context

Need this short version later in repository detail section to get the name of the parent SOBR
How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.

Thanks, I did the test in my home lab and now it works fine.


chore: update Harbor for prometheus growth project

Summary
Updating existing Harbor quickstart dashboard and adding new alert definitions for the Prometheus Growth project.
PR will be in draft until public docs are available to update in the config.yml and dashboard.json.

Pre merge checklist

[x] Did you check you NRQL syntax? - Does it work?
[x] Did you include an InstallPlan and Documentation reference?
[ ] Are all documentation links publically accessible?
[x] Did you check your descriptive content for voice and tone?
[x] Did you check your descriptive content for spelling and grammar errors?

Dashboards

[x] Does the PR contain a screenshot for each of your dashboards?
[x] Do your screenshots show data?
[x] Has the sanitization script been run on each dashboard?

Alerts

[x] Did you check that your alerts actually work?

PR is still pending active docs link, please don't kill me Mr or Ms Bot 🙏

Hello, We are no longer accepting install plans as a part of the quickstart schema. We are instead moving to use data sources. You can either refer to an already existing data source in this repository or make your own community data source.
If this applies to your PR, please make the proper update to your quickstart's config to reference only data sources.

This has been excluded from the mandatory data source migration so it can be merged with install plans if it has any.