Decouple trial from Split::Helper

This closes #285
A decent amount of refactoring done here, but it should clean things up quite a bit. No changes were made to the helper API and all of the specs are passing.

Coverage decreased (-63.95%) when pulling 768128045d989310b2222c7ed71d057c1c1088c1 on asku:master into 43638df6dcd7711f42a4ea3cd61ade434d48b00a on andrew:master.

Coverage decreased (-63.95%) when pulling 768128045d989310b2222c7ed71d057c1c1088c1 on asku:master into 43638df6dcd7711f42a4ea3cd61ade434d48b00a on andrew:master.

Coverage decreased (-0.05%) when pulling 2bd078112f9c52d457bd438b7be652e9c9eeb080 on asku:master into 43638df6dcd7711f42a4ea3cd61ade434d48b00a on andrew:master.

Coverage decreased (-0.05%) when pulling 2bd078112f9c52d457bd438b7be652e9c9eeb080 on asku:master into 43638df6dcd7711f42a4ea3cd61ade434d48b00a on andrew:master.

An illustrated example of what this PR allows me to do. We have an experiment where we are split users to test whether or not they should receive a notification. This runs in a background job and sends notifications to users who are not actually logged in (it's the current user's friends).
ab_user    = Split::Persistence.adapter.new(nil, user.tracking_id)
experiment = Split::ExperimentCatalog.find(:friend_post_notification)
trial      = Split::Trial.new(user: ab_user, experiment: experiment)
send_notification if trial.choose!

This looks great @joshdover, thanks very much. I'll look at getting a new release out for this in a few days. :tada:

@joshdover I've released this as part of v1.1.0 :tada: https://github.com/andrew/split/releases/tag/v1.1.0


You'll need a new app to open this ms-xal-public-beta

After successfully building and starting the app I get the following when logging in.

Can you check if you have the latest changes? There was a hotfix committed yesterday.
In case it still happens then let me know and i will try to reproduce it on my side.

Yes, it seems to work with the hotfix. Sorry about that, after successfully building the stuff (xal-node) I forgot to do a pull. My bad again. Thanks!


Feature Request: rename

It would be handy to have a possibility to rename certain modules, containers, components, etc.
Doing it manually tends to produce human errors :)

There were definitely moments when I thought such feature would be useful. I suppose we can add
a command:
mantra rename [type] [original name] [new name]

For each types, we will need to change:

containers - rename container, component, test
component - rename component, test
collection - rename collection, change variables in /collections/index.js
method - rename method, change variables in /methods/index.js
module - rename the module name, and change variables in the entry file.

Changing variable names is kind of tricky. Currently we are using this function, but I have seen some edge cases. We need more thorough testing.
I think it is not an easy feature, but is worth implementing.

Let me know if you need help implementing it or testing it

This would be indeed very handy, though, its not completly trivial. Maybe we should start with renaming all files and imports (that's the easy part). Changing variable names is more tricky, as @sungwoncho  stated.

+1 for this. Renaming mantra-cli would be a great feature


Add new FAQ doc for setting environments

Add new FAQ doc that explains what environments are and how to configure them.
Screenshot of new doc

Awesome addition @thompiler! LGTM 🚀 🚢 :shipit: ship it!


Add Credential File to Auth Spec

Resolves #206
Signed-off-by: Shiwei Zhang<EMAIL_ADDRESS>

Closing as per https://github.com/notaryproject/notation/issues/206#issuecomment-1168096534


$slots elements are not rendered if it derived by computed prop

Vue.js version
2.0.0-rc.3
Reproduction Link
https://jsfiddle.net/ktsn/oc8g5dcm/6/
Steps to reproduce
Click "Add List" button.
What is Expected?
Both test1 and test2 components render the elements passed to $slots.
What is actually happening?
The test2 renders the elements but test1 is not.
Note that we can avoid this issue if adding cache: false option for the computed option.

The point is that $slots is not reactive (and it not meant to be as far as I know from Evan), so the computed prop will not re-evaluate when $slots change.
And I assume they change/get filled after the computed props have been evaluated initially.
I would call this expected behaviour.

Ah, I think it's true, thanks!
But should we provide an error (or warning) message when using such values in computed getters?
It could be large pit fall for users...

That kind of warning would be hard to implement because there may be scenarios where someone uses $slots inside a computed property for a good reason, and only wants it to update when another, reactive value changes.
So Vue would have to check weither only unreactive elements are used, which is not worth it in my opinion.
We should rather make it clear in the guide and API docs that computed properties only react to changes references to data, props and other computed properties.

Thanks for explaining, @LinusBorg!

I agree that implementing a warning probably isn't feasible and that we can make this more clear in the guide. I'll take care of it. 🙂 I think in any use case where one's tempted to use $slots in a computed property though, moving that data to one or more props (which are reactive) would be a better solution.

I ran into this problem and the solution to this one is simply using a getter method (i.e getSlots()) instead of hacks like adding a random property just so you can use a computed property and reference the said random property inside it.
Referencing OP's jsfiddle, instead of:

computed: {
  firstSlot() {
    return this.$slots.default
  }
}

do this:

methods: {
  getFirstSlot() {
    return this.$slots.default
  }
}

This solution applies to any other non-reactive properties and not only $slots

@xxRockOnxx thank you good sir you saved my day


Notifications should bundle multiple chapters from the same series

Right now it's easy to get 2 or 3 notifications for one series, when we probably only want 1

I no longer agree with this, closing


Code version release management

We work in an enterprise environment and would like to understand how the frontend and backend code versions are updated in case of future updates.
Moreover, the deploy.ps1 script is not idempotent and doesn't store the state of the infra, and it would be good to move this to Terraform and provide some sample pipelines to build, publish and consume app container images.

Lots of great feedback @jeevanions!
Right now, we're in the building phase of the Azure IPAM tool, attempting to rapidly get all of the core/key features into the platform. As such, releases are sporadic with functionality coming out as fast as we can code it. When we push new code to the main branch, we also push new container to our hosted registry with the updated builds. For users who have deployed the solution from our script (without the Private ACR), they can simply restart their App Service and the updated containers will be pulled down.
In the (hopefully near) future, we plan of having GitHub Actions and build pipelines for release management so that we can have a reliable schedule of when new releases are expected.
I hope that helps to answer your question, but please let me know if any additional detail is required here. Always happy to chat 1:1 live if that is more desirable. Thanks!

I totally love it hence these questions. I have demoed this to our client, and they are impressed. They have all the things needed out of the box.  We are planning to deploy it in a production environment and start using it. So we have to figure out how the control the release and updates, etc.
Thank you for your hard work.

Hi @jeevanions, I know it's been a really long time coming, but this ask has now been implemented as of #230.
You'll start seeing a versioned release with every PR merge back to main. Hope this aligns with your original ask, and please let me know if you have any follow-up questions or issues around this.
Have a great one!


Parmeterize number of recent posts.

Hello,
I think it would be nice to parameterize the number of recent posts to display in index.html instead of hardcoding to 3 in {{ range (first 3 $section) }}. Something like:
[params]
  recent_posts_number = 5

in config.toml to replace 3 in index.html.
Let me know if you would like me to submit a pull request for this.
Thanks,
David

Sure, that's a great idea. PR is welcome!

solved in #69


Dockerfile versioning

@phschiele following up from #274
Docker is supported for a couple of reasons:

As a worst case, if a user is really not able to get anything installed on their machine, running it in a docker container should work
Binder support. This serves the cookbook jupyter notebooks so people can try stuff in browser. I personally find it very useful if I want to run some very quick tests in response to a new issue (rather than opening my IDE, activating the venv, opening jupyter notebook etc).
Advanced users who are used to running everything from containers may find it useful.

I agree that using poetry in the dockerfile is the most consistent solution, but I wonder if that adds unnecessary overhead. People use docker containers as an alternative to virtualenvs, so it might be an unnecessary layer of complexity to have poetry inside.
I think the best compromise is to fix the dependency specification in requirements.txt (as we are discussing in #277) then leave docker as is.

@robertmartin8 The use cases you describe make total sense to me.
I agree that updating the requirements.txt will already be an improvement.
One reason why I particularly like poetry in combination with Docker is reproducibility. Note that with requirements.txt, the sub dependencies might change when running the same Dockerfile twice, which can lead to problems in edge cases.
Of course, poetry does not remove all such issues, but by locking all the sub dependencies, the risk is greatly reduced.
Additionally, I think as long as the Dockerfile is working reliably, most users would not really care if it is using requirements.txt or poetry under the hood.
If that sounds interesting to you, I can open a PR so you can try it for yourself.

as long as the Dockerfile is working reliably, most users would not really care if it is using requirements.txt or poetry under the hood.

Yeah this is probably right. If you've got time, a PR would be much appreciated!


add audio context example

A few things I noticed:

It felt like the audio speeding up/slowing down was happening more frequently (is it bad to use the DOM for video and just audioCb for audio?)
Sometimes the audio wouldn't play on click (the user gesture issue). This was only happening on Chrome, and it seems non-deterministic

These issues don't seem to impact https://threejs-example.hyperbeam.com/ @_@


Change sidebar width

Change sidebar width.

why?

The sidebar covered the content.
Before change:

After change:


Appstudio update test-component-pac-fbzv

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI/test-component-pac-fbzv-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
16 seconds
clone-repository

✅ Succeeded
39 seconds
sast-snyk-check

✅ Succeeded
1 minute
build-container

✅ Succeeded
11 seconds
deprecated-base-image-check

✅ Succeeded
4 minutes
clair-scan

✅ Succeeded
49 seconds
clamav-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
9 seconds
inspect-image

✅ Succeeded
12 seconds
show-sbom

✅ Succeeded
9 seconds
show-summary

Pipelines as Code CI/test-component-pac-fbzv-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
16 seconds
clone-repository

✅ Succeeded
39 seconds
sast-snyk-check

✅ Succeeded
1 minute
build-container

✅ Succeeded
4 minutes
clair-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
9 seconds
inspect-image

✅ Succeeded
11 seconds
deprecated-base-image-check

✅ Succeeded
49 seconds
clamav-scan

✅ Succeeded
12 seconds
show-sbom

✅ Succeeded
9 seconds
show-summary

Pipelines as Code CI/test-component-pac-fbzv-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
19 seconds
clone-repository

✅ Succeeded
55 seconds
sast-snyk-check

✅ Succeeded
28 seconds
build-container

✅ Succeeded
27 seconds
inspect-image

✅ Succeeded
39 seconds
clamav-scan

✅ Succeeded
25 seconds
deprecated-base-image-check

✅ Succeeded
10 seconds
clair-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
7 seconds
show-sbom

✅ Succeeded
7 seconds
show-summary


Possibility of dropping Ruby 1.8.6 support?

The Homebrew core no longer supports OS X 10.5, so we have little reason to keep our Ruby 1.8.6 compatibility patches around. I'd like to remove them, but I didn't want to commit it without giving fair warning to forks.
I already sent patches to Tigerbrew to move them to different files: https://github.com/mistydemeo/tigerbrew/commit/0695677444b9f90bb53f4a5122a59845a5713161, https://github.com/mistydemeo/tigerbrew/commit/826470a0771cadd07843ebaaa9c11ecf63647e52
What are your feelings about 1.8.6 support in Linuxbrew? Are there many users on distros that don't have a newer Ruby by default?

Also, we will likely be dropping 1.8.7 support soon after 10.11 is released, as that will mark three OS X releases that ship Ruby 2.0+, and we'd like to start taking advantage of it.

CentOS 5.10, the oldest distro that I make some effort to support, comes with Ruby 1.8.5, so it's already pooched. I don't feel too bad about dropping support for old versions of Ruby. It does make bootstrapping a system a little harder, because you have to install Ruby from source first. In any case, go right ahead. It'll be nice, I imagine, to drop the compatibility patches.

I've removed them upstream. Thanks!


Extending existing html elements

Hi, is it possible to extend existing elements like input, select ?

Unfortunately no. Even with web components, the method of accomplishing that is still being debated.

Consider wrapping them in a custom element or creating a custom attribute that attaches additional behavior to the built-in element. Something like this
<input type="checkbox" custom-checkbox> where custom-checkbox is your custom attribute that adds behavior to the input.

If I create custom element for example
how can I access these attributes in template to assign them to  ?


[stdlib][WIP] Migrate stdlib tests of Swift 3

PR to gather std lib tests that use Swift 3.

Some need switching from 3 to 4, with source tweaks
Some just need deleting because they were testing 3-only stuff
Some test multiple versions and need 3 removing

@swift-ci please test

Thanks for working on this!

Some of these changes are to explicitly check legacy support for users of -swift-version 3. Is your intention for us to not test this mode at all, or just to migrate stale tests?

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 41e05d41aad9a2b041519a88f0a4a19dfcb07d13

@swift-ci please test Linux platform

@swift-ci please test Linux platform

Build failed
Swift Test Linux Platform
Git Sha - 41e05d41aad9a2b041519a88f0a4a19dfcb07d13

@swift-ci please clean test linux platform

Build failed
Swift Test Linux Platform
Git Sha - 41e05d41aad9a2b041519a88f0a4a19dfcb07d13

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - f7ab8ca87135fe50f4f16357aca0af969772d96d

@swift-ci please test linux platform

Build failed
Swift Test OS X Platform
Git Sha - 387ca22eb7d4c2ef5423f0e63afeeb7091d0e545

@swift-ci please test Linux platform

Build failed
Swift Test Linux Platform
Git Sha - f5d938ada410a602ca424caf3daadf24cc25dac9

@swift-ci please test Linux platform

Finally™


a question about Radio Buttons instead of Checkboxes

Hi CU, your Finder is an excellent tool. I am hoping we can use it too to solve the same problem, will be glad to cite your tool on our pages.
I am wondering if you have investigated if it is possible to use RadioButtons in the criteria lists? I briefly scanned the Drupal docs, but I am not seeing specific support for Radio buttons, do you know if it would be possible? Checkboxes don't convey visually the mutually exclusiveness of some criteria. thanks.

We're using radio buttons in some fields and check boxes in other fields here: https://findwebhosting.web.illinois.edu/finder - It depends on which you select during the taxonomy creation process which effect you'll get. I was somewhat confused by why they were all displaying as checkboxes even when radio functionality was enabled, but haven't been able to figure out the origin there. But the functionality is available!

My apologies if this is really a simple question.
I have installed the module, created services, taxonomy, etc., but when I go to the finder module on my site, No services or questions show up?  Anything I should be looking for?  I created all the services as described.  One note, when I go into the Finder configuration page and change the default headings, etc...they don't seem to be appearing on the finder page either.  Almost like I am looking at the wrong finder page???
thanks for any help.
Steve


[UPLC] [Evaluation] Switched to the alternative builtin application machinery in the CEK machine

Don't look here yet.

(still not ready for review quite yet)
I've run benchmarks multiple times at this point and I'm not getting super consistent results across runs (but the results are fairly consistent within a single run), however the trend is clearly down.

Cool, thanks.

Should be ready for review.

It's got more unsafe stuff, and it means we need CekCarryingM again

Still less boilerplate, though. And we still have CkCarryingM in the CK machine.


Cannot access 'CollapsingToolbarScopeInstance': it is internal in 'me.onebone.toolbar'

IntelliJ IDEA imports me.onebone.toolbar.CollapsingToolbarScopeInstance.road and complains that it's internal when trying to use Modifier.road() or others
IntelliJ IDEA 2021.3 RC (Ultimate Edition)
Build #IU-213.5744.125, built on November 17, 2021
Runtime version: 11.0.13+7-b1751.19 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.15.4-arch1-1
GC: G1 Young Generation, G1 Old Generation
Memory: 4096M
Cores: 16
Kotlin: 213-1.5.10-release-949-IJ5744.125
Current Desktop: KDE
CollapsingToolbar v. 2.3.0

This library only targets Android platform for now, are you working with Android?

Yes I am. I can't import import me.onebone.toolbar.CollapsingToolbarScope.road

Not sure though, I think it is complaining because CollapsingToolbarScope is an interface.
By the way, you don't have to import the road extension function. It automatically resolves because CollapsingToolbarScope is passed as a context parameter in the toolbar lambda.

Ah, I understand now. I'm creating my own composables for an UI Kit in the app, and this is my first time working with Compose. I have made a nooby mistake: when you move a composable to another function, you have to inherit its scope, i.e.
@Composable // \/ -- scope here
fun CollapsingToolbarScope.CollapsingToolbar(
    modifier: Modifier = Modifier,
    image: Any? = null,
    title: String = stringResource(R.string.app_name),
    state: CollapsingToolbarState,
) {

For anyone lurking here after me - inherit the scope, and don't forget about Modifier first parameter to pass to your composable.


RAW Output

i need raw output sha1 like php does.
base64_encode(sha1('string',true));
trying using true , but result is same

You should probably go with another module.


Command runner with implemented classes

Signed-off-by: Petr "Stone" Hracek<EMAIL_ADDRESS>This pull request adds the possibility to execute actions in CLI or in Openshift.

[x] test covered / fixed

Tests are failing on https://github.com/packit-service/packit/blob/master/tests/unit/test_cli_utils.py#L72 and https://github.com/packit-service/packit/blob/master/tests/unit/test_cli_utils.py#L128 which I don't understand :(

Just tested this locally using the test I pushed to this PR and it passed.
There is still work which needs to be done (in a new PR, ideally):

remove the pod once done
sync the git repo to the sandbox

packit now import Sandcastle class and not OpenshiftDeployer class.

@TomasTomecek PTAL on it once more. Thanks.


perf: memo SidebarLinks

Details

Note: This PR is based on this PR https://github.com/Expensify/App/pull/11886

When clicking the + FAB on the start screen I felt that it took too long until the popup opens. I want the popup to open instantly. After some performance profiling, I've seen that when opening the popup the SidebarLinks unnecessarily rerender. I assume that fix also maybe helps in other places where it would rerender although it doesn't need to.
See a video before and after the change:

Before
After

Note: with this change I was able to witness that the FAB actually has an animation when pressing it 👀 😄 (before the frames were skipped)

(A performance comparison from debug mode):

Fixed Issues

$ GH_LINK
PROPOSAL: GH_LINK_ISSUE(COMMENT)
Tests

[x] Verify that no errors appear in the JS console

PR Review Checklist

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The reviewer will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps

[x] Verify that no errors appear in the JS console

Screenshots

Web

https://user-images.githubusercontent.com/16821682/196210965-0b3ced95-881d-4ff6-81ad-f955ca4d0ff5.mov
Mobile Web - Chrome

https://user-images.githubusercontent.com/16821682/196211036-a15b9c20-91e9-4f40-b71f-55b4b18324ed.mov
Mobile Web - Safari

Couldn't test due to this bug appearing: https://github.com/Expensify/App/issues/11677
Desktop

https://user-images.githubusercontent.com/16821682/196211116-a8a28f63-d64d-42d0-a406-e91638f65836.mov
iOS

https://user-images.githubusercontent.com/16821682/196211180-797b21d9-9dda-4fa9-b90f-8a162b62f58f.mov
Android

https://user-images.githubusercontent.com/16821682/196211256-eb67da25-e323-41fe-a1af-26fe312e35f2.mp4

@mountiny Hey, I was thinking about steps, but having a bit of a hard time coming up with some (I think it shouldn't cause any strange side effects, but totally agree its good to test that as much as possible!).  I am not too familiar yet with the app functionality and looking more at the app through the lens of performance profiling tools. Maybe there is someone who is more familiar with the SidebarLinks component and could come up with some suggestions?

Maybe there is someone who is more familiar with the SidebarLinks component and could come up with some suggestions?

Yeah I think general regression tests would be good, but in term of SidebarLinks specifically, @tgolen is the best at the moment I think.

Thanks for the context Tim

Also regarding the performance comparison, you said you had to use this PR as base https://github.com/Expensify/App/pull/11886/files, however, can you then quantify what is the performance gain of this particular change (with no effect of the base change)

Alright, thank you for explaining, will create issues now first from now on 💪!
Yeah, the performance results of the main branch VS base branch VS this branch:

will create a performance issue for both PRs soon!

@rushatgabhane yes you are right, it should definitely be done on release builds.
I just realised that the app's UI thread I release mode seems very busy and is oscillating between 20-35 FPS, thus the performance benefits in the release build aren't really measurable as that greater performance issue shadows them. (I have it on my todo to look into that)

@hannojg @rushatgabhane What is a state on this PR? Lets get it merged.

I am looking into refactoring it to make it cleaner. Will mark it as draft, and un-draft as soon as we are good again 😊

Yes, this would be really helpful. The tool name used for iOS, Android and Web would suffice

I am working already on some performance tools that we can use during development! These will also be available soon to everyone.

(lint test failing due to some weird error, can someone please retry it? 😅 )

Retried it, can you also updated the PR reviewer checklist?

Sorry, what do you mean by that exactly? 😅 I have ticked all boxes 🤔

It was probably old checklist or something, I copied in the new one and it passed now.

Resolved!

Gonna merge since Andrew and Tim both expressed they like the code above.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @mountiny in version: 1.2.22-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

Hey @hannojg. I'm not 100% sure about this, but it's possible this refactor introduced this regression where the FAB button is not being shown on Android. Would you mind taking a look?

Sure, will have a look tomorrow! (Today is national holiday in AT)

FYI as this regression blocks users from almost all features and blocks further deploys, I'm going to revert it.
@hannojg would you mind resubmitting a PR once this issue s resolved? Thanks!

Yes, please revert, will put out a new PR. Will make sure such a major regression won't happen again (also a bit confused as I thought I'd tested it also extensively on Android).
Will be first thing tmr morning

FYI, here's the follow-up PR.

🚀 Deployed to production by @Julesssss in version: 1.2.22-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Looks like devspace sync skip files

What happened?
When I try remove and create many files in project some files skipped. We have precompiled xsl in our project, so it's need:

delete already compiled xsl's
run xsltroc and get fresh xsl's
after this count local xsl files:
$ find xhh/xsl_precompiled/  | wc -l 1179
count pod xsl files:
# find xhh/xsl_precompiled/  | wc -l 78
How devspace is running:
devspace sync --local-path=... --container-path=... --upload-only -e '.git' -e 'python_venv' --verbose

Then if I restart devspace sync skipped files successfully synced.
What did you expect to happen instead?
number of files after sync in local dev  = number of files in pod
How can we reproduce the bug? (as minimally and precisely as possible)
need to delete and recreate many files in project directory in short time. I think it's possible using git, i.e. rm project files and then run git reset --hard
Local Environment:

DevSpace Version: 5.7.1
Operating System: linux Ubuntu 18.04
Deployment method: kubectl apply

Kubernetes Cluster:

Cloud Provider: bare-metal
Kubernetes Version: Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:18:23Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Anything else we need to know?

/kind bug

@amishurov thanks for reporting this issue! Do you think it might be possible to create a demo repo with which we can reproduce this issue?

@amishurov thanks for reporting this issue! Do you think it might be possible to create a demo repo with which we can reproduce this issue?

Hello, @FabianKramm
I've added demo repo https://github.com/amishurov/devspace_issue_1296
Howto reproduce bug using this repo:
1.git clone  git@github.com:amishurov/devspace_issue_1296.git
2. run yarn (I have 1.22.4). It will generates about 55к files
3. run devspace sync devspace sync --local-path=/home/user/devspace_issue_1296 --container-path=/home/user/devspace_issue_1296 --upload-only -e '.git' --verbose (initial sync will transfer all files to pod)
4. rm -rf node_modules && yarn
5. wait for sync again
6. count files on local file system and in pod:
find node_modules -type f | wc -l 57616
find node_modules -type f | wc -l
45666

Hello, @FabianKramm
I've added demo repo https://github.com/amishurov/devspace_issue_1296
Howto reproduce bug using this repo:
1.git clone  git@github.com:amishurov/devspace_issue_1296.git
2. run yarn (I have 1.22.4). It will generates about 55к files
3. run devspace sync devspace sync --local-path=/home/user/devspace_issue_1296 --container-path=/home/user/devspace_issue_1296 --upload-only -e '.git' --verbose (initial sync will transfer all files to pod)
4. rm -rf node_modules && yarn
5. wait for sync again
6. count files on local file system and in pod:
find node_modules -type f | wc -l 57616
find node_modules -type f | wc -l
45666

@amishurov thanks! I'll take a look and try to reproduce the issue on my machine.

@amishurov thanks! I'll take a look and try to reproduce the issue on my machine.

@amishurov I tested it and it seems like the internal file system event buffer is overflowing because of the huge amount of changes which results in missing files in the pod. I'll fix this for the next version.

@amishurov I tested it and it seems like the internal file system event buffer is overflowing because of the huge amount of changes which results in missing files in the pod. I'll fix this for the next version.

thanks for quick fix, I'll try to test it when release will be ready

thanks for quick fix, I'll try to test it when release will be ready

@amishurov we released v5.7.4, would be great if you could verify that it works. One note: since node_modules contains a lot of symlinks it is possible that the amount of files still differs since devspace does not preserve symlinks and instead resolves them and copies the files instead.

@amishurov we released v5.7.4, would be great if you could verify that it works. One note: since node_modules contains a lot of symlinks it is possible that the amount of files still differs since devspace does not preserve symlinks and instead resolves them and copies the files instead.

@FabianKramm I've tested new version, and get strange behavior. What i did:

initial sync via kubectl cp
rm -rf node_modules && yarn  on localhost
wait for sync
number of files in pod = number of files + number of symlinks on localhost exactly
sleep about 5 min ( had tea :))
repeat p.2-3
got only directories synced, 0 files in pod
restart devspace container
9 got result as in p.4
here is devspace sync log (skipped "Symlink found .." messages)

 [info]   Start syncing
[done] √ Sync started on /project <-> /home/hh/codebase/hh.sites.main (Pod: udev/frontik-865c9857bf-cpfh4)
# first time rm -rf node_modules
[info]   Upstream - Handling 94819 removes
[info]   Upstream - Successfully processed 94819 change(s)
[info]   Upstream - Handling 94 removes
[info]   Upstream - Upload 237000 create change(s) (Uncompressed ~9995077.74 KB)
[info]   Upstream - Successfully processed 237094 change(s)
# second time rm -rf node_modules
[info]   Upstream - Handling 94224 removes
[info]   Upstream - Successfully processed 94224 change(s)
[info]   Upstream - Upload 1981 create change(s) (Uncompressed ~20072.43 KB)
[info]   Upstream - Successfully processed 1981 change(s)
# only directories were synced
# restart devspace here
[info]   Using namespace 'udev'
[info]   Using kube context 'testing.hh.ru'
[info]   Start syncing
[done] √ Sync started on /project <-> /home/hh/codebase/hh.sites.main (Pod: udev/frontik-865c9857bf-cpfh4)
[info]   Upstream - Upload 50350 create change(s) (Uncompressed ~221838.23 KB)
[info]   Upstream - Successfully processed 50350 change(s)
[info]   Upstream - Upload 23490 create change(s) (Uncompressed ~198894.35 KB)
[info]   Upstream - Successfully processed 23490 change(s)

@FabianKramm I've tested new version, and get strange behavior. What i did:

initial sync via kubectl cp
rm -rf node_modules && yarn  on localhost
wait for sync
number of files in pod = number of files + number of symlinks on localhost exactly
sleep about 5 min ( had tea :))
repeat p.2-3
got only directories synced, 0 files in pod
restart devspace container
9 got result as in p.4
here is devspace sync log (skipped "Symlink found .." messages)

 [info]   Start syncing
[done] √ Sync started on /project <-> /home/hh/codebase/hh.sites.main (Pod: udev/frontik-865c9857bf-cpfh4)
# first time rm -rf node_modules
[info]   Upstream - Handling 94819 removes
[info]   Upstream - Successfully processed 94819 change(s)
[info]   Upstream - Handling 94 removes
[info]   Upstream - Upload 237000 create change(s) (Uncompressed ~9995077.74 KB)
[info]   Upstream - Successfully processed 237094 change(s)
# second time rm -rf node_modules
[info]   Upstream - Handling 94224 removes
[info]   Upstream - Successfully processed 94224 change(s)
[info]   Upstream - Upload 1981 create change(s) (Uncompressed ~20072.43 KB)
[info]   Upstream - Successfully processed 1981 change(s)
# only directories were synced
# restart devspace here
[info]   Using namespace 'udev'
[info]   Using kube context 'testing.hh.ru'
[info]   Start syncing
[done] √ Sync started on /project <-> /home/hh/codebase/hh.sites.main (Pod: udev/frontik-865c9857bf-cpfh4)
[info]   Upstream - Upload 50350 create change(s) (Uncompressed ~221838.23 KB)
[info]   Upstream - Successfully processed 50350 change(s)
[info]   Upstream - Upload 23490 create change(s) (Uncompressed ~198894.35 KB)
[info]   Upstream - Successfully processed 23490 change(s)

@amishurov thanks for the update! Thats strange, maybe thats another issue, I'll try to reproduce this problem

@amishurov thanks for the update! Thats strange, maybe thats another issue, I'll try to reproduce this problem

@amishurov I can somewhat reproduce it on linux as when this occurs (after only the folders get synced, for me even only the node_modules folder is synced) the inotify watcher itself seems to completely crash and not notice any events to the synced folders anymore afterwards. Is that the same behaviour for you as well? So basically if your create a file manually in those folders after this happens, does devspace sync that file into the container?

@amishurov I can somewhat reproduce it on linux as when this occurs (after only the folders get synced, for me even only the node_modules folder is synced) the inotify watcher itself seems to completely crash and not notice any events to the synced folders anymore afterwards. Is that the same behaviour for you as well? So basically if your create a file manually in those folders after this happens, does devspace sync that file into the container?

@FabianKramm tried to create file in watched folder and it wasn't synced

@FabianKramm tried to create file in watched folder and it wasn't synced

@amishurov after some investigation I found out that this new problem is indeed an issue of the underlying library that we use (https://github.com/rjeczalik/notify). I opened an issue there and come back to you as soon as there is any progress

@amishurov after some investigation I found out that this new problem is indeed an issue of the underlying library that we use (https://github.com/rjeczalik/notify). I opened an issue there and come back to you as soon as there is any progress

@amishurov this should be fixed with version v5.9.0

@FabianKramm  thank you! I'll check new version soon

Hello, @FabianKramm, I've just tested version 5.9.0 and looks like problem still reproduced.
I've tested new version according to my initial issue description, i.e. generated xsl files; than drop all; than generated new ones and waited for sync
and finally got only 15 files&dirs synced instead more than 1k.

Hello @FabianKramm
I've tested version 5.9.0 and got case when file did't sync. In our project we have multiple js files bundled by webpack. Also we have file with meta info about packed js budles. It is xml containing unique hashes i.e
<?xml version="1.0"?> <js-variables> <variable key="appEntryPoint" value="/webpackBuild/appEntryPoint.9a045712a3d479c28c5b.js"/> </js-variables> </xml>
When developer makes changes in source code this file also changes on the fly by gulp script tracking changes.
Finally, the problem is this file with meta info about bundles doesn't sync into pod. I think this behaviour is effect of many files changing in short time, due webpack working


'test_second_level': expected item missing in set

From: https://travis-ci.org/GoogleCloudPlatform/google-cloud-python/builds/158529136#L1386-L1393
======================================================================
FAIL: test_second_level (storage.TestStoragePseudoHierarchy)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/GoogleCloudPlatform/google-cloud-python/system_tests/storage.py", line 329, in test_second_level
    set(['parent/child/grand/', 'parent/child/other/']))
AssertionError: Items in the second set but not the first:
'parent/child/other/'

Indeed. I've been tracking this on the last 5 or so builds. storage seems to be under duress (or just has different performance characteristics than before)

I went at this in #2252, maybe the issue is with how the Iterator stores prefixes?

I'm going to close this. I'm fairly certain that it was caused by #2289. We can re-open if we see the issue come back.


Add cosign signature verification for plugin inventory image to ensure integrity of plugins

What this PR does / why we need it
This PR adds cosign signature verification functionality in CLI to ensure the plugins integrity downloaded and installed from the central repository
-Added signature verification of plugin inventory(DB) image to ensure the integrity of plugin downloaded and installed from the repository

Also embedded the default public key in the CLI required to verify the cosign signature
If the signature verification fails, CLI would show the warning message but would not throw error and users can choose to skip this validation by setting the environment variable TANZU_CLI_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_VERIFICATION_SKIP_LIST with the discovery image url. User can also choose to suppress signature verification failure warning by setting TANZU_CLI_SUPPRESS_SKIP_SIGNATURE_VERIFICATION_WARNING to true.

Which issue(s) this PR fixes

Fixes #107
Describe testing done for PR
Compiled  the CLI and plugins and published to repository:harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1
Later, tried to executing tanzu plugin search which would validate the plugin inventory image signature and throws Warning message to User.
❯ export PLUGIN_PUBLISH_REPOSITORY="harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1"
❯ make cross-build
build linux-amd64 CLI with version: v0.0.2-dev
build windows-amd64 CLI with version: v0.0.2-dev
build darwin-amd64 CLI with version: v0.0.2-dev
/Users/pkalle/projects/tanzu-cli/bin/builder plugin build \
		--path ./cmd/plugin \
		--binary-artifacts /Users/pkalle/projects/tanzu-cli/artifacts/plugins \
		--version v0.0.2-dev-25-ge4083254 \
		--ldflags "-X 'github.com/vmware-tanzu/tanzu-plugin-runtime/plugin/buildinfo.Date=2023-03-10' -X 'github.com/vmware-tanzu/tanzu-plugin-runtime/plugin/buildinfo.SHA=e4083254' -X 'github.com/vmware-tanzu/tanzu-plugin-runtime/plugin/buildinfo.Version=v0.0.2-dev-25-ge4083254'" \
		--os-arch linux_amd64 \
		--match "*"
...[snap]...

2023-03-10T14:29:07-08:00 [i] Saved plugin manifest at "/Users/pkalle/projects/tanzu-cli/artifacts/packages/plugin_manifest.yaml"
/Users/pkalle/projects/tanzu-cli/bin/builder plugin publish-package \
		--package-artifacts /Users/pkalle/projects/tanzu-cli/artifacts/packages \
		--publisher tzcli \
		--vendor vmware \
		--repository harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1

--[snap]----
2023-03-10T14:30:20-08:00 [i] Published plugin at 'harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/vmware/tzcli/windows/amd64/global/test:v0.0.2-dev-25-ge4083254'
/Users/pkalle/projects/tanzu-cli/bin/builder inventory init \
		--repository harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1 \
		--plugin-inventory-image-tag latest \
		--override
2023-03-10T14:30:20-08:00 [i] created database locally at: "/var/folders/fz/4qtr7ntn2wvd2ptvthc459y80000gq/T/plugin_inventory.db"
2023-03-10T14:30:20-08:00 [i] publishing database at: "harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest"
2023-03-10T14:30:22-08:00 [i] successfully published plugin inventory database
/Users/pkalle/projects/tanzu-cli/bin/builder inventory plugin insert \
		--repository harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1 \
		--plugin-inventory-image-tag latest \
		--publisher tzcli \
		--vendor vmware \
		--manifest /Users/pkalle/projects/tanzu-cli/artifacts/packages/plugin_manifest.yaml
2023-03-10T14:30:22-08:00 [i] Pulling plugin inventory database from: "harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest"

2023-03-10T14:30:49-08:00 [i] Publishing plugin inventory database
2023-03-10T14:30:51-08:00 [i] Successfully published plugin inventory database at: "harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest"

Plugin Search command failed(below) and also shows Fatal message that Signature verification failed as the plugin discovery image is not signed yet
❯ export TANZU_CLI_PRE_RELEASE_REPO_IMAGE=harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1
❯ ./artifacts/darwin/arm64/cli/core/v0.0.2-dev/tanzu-cli-darwin_arm64 plugin clean
[ok] successfully cleaned up all plugins

❯ ./bin/tanzu plugin search
[!] Unable to verify the plugins discovery image signature: failed validating the signature of the image harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest :no matching signatures:
[x] Fatal, plugins discovery image signature verification failed. The `tanzu` CLI can not ensure the integrity of the plugins to be installed. To ignore this validation please set the environment variable "TANZU_CLI_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_VERIFICATION_SKIP_LIST" to "harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest" .  This is NOT RECOMMENDED and could put your environment at risk!

You can skip the discovery image signature by setting the TANZU_CLI_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_VERIFICATION_SKIP_LIST to harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest
❯ export TANZU_CLI_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_VERIFICATION_SKIP_LIST=harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest
❯ ./bin/tanzu plugin search
[!] Skipping the plugins discovery image signature verification for "harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest"

  NAME                DESCRIPTION                           TARGET      VERSION                  STATUS         CONTEXT
  builder             Build Tanzu components                global      v0.0.2-dev-21-gb558a9df  not installed
  test                Test the CLI                          global      v0.0.2-dev-21-gb558a9df  not installed
  cluster             Kubernetes cluster operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  feature             Operate on features and featuregates  kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  kubernetes-release  Kubernetes release operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc

You can notice in the above log a warning message showing the discovery image signature verification is skipped. If user choose to skip this warning message, user has to set TANZU_CLI_SUPPRESS_SKIP_SIGNATURE_VERIFICATION_WARNING to true
❯ export TANZU_CLI_SUPPRESS_SKIP_SIGNATURE_VERIFICATION_WARNING=true
❯ ./bin/tanzu plugin search
  NAME                DESCRIPTION                           TARGET      VERSION                  STATUS         CONTEXT
  builder             Build Tanzu components                global      v0.0.2-dev-21-gb558a9df  not installed
  test                Test the CLI                          global      v0.0.2-dev-21-gb558a9df  not installed
  cluster             Kubernetes cluster operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  feature             Operate on features and featuregates  kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  kubernetes-release  Kubernetes release operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc

Signed the plugin inventory OCI Image with the private key using cosign
❯ cosign sign --key ~/co-sign/tanzu-cli-keys/cosign.key harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest
Enter password for private key:
WARNING: Image reference harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory:latest uses a tag, not a digest, to identify the image to sign.

This can lead you to sign a different image than the intended one. Please use a
digest (example.com/ubuntu@sha256:abc123...) rather than tag
(example.com/ubuntu:latest) for the input to cosign. The ability to refer to
images by tag will be removed in a future release.
Pushing signature to: harbor-repo.vmware.com/tanzu_cli/pkalle/test/v1/plugin-inventory

Now you can see  tanzu plugin search and tanzu plugin install command can be run without any failures
❯ ./bin/tanzu plugin search
  NAME                DESCRIPTION                           TARGET      VERSION                  STATUS         CONTEXT
  builder             Build Tanzu components                global      v0.0.2-dev-21-gb558a9df  not installed
  test                Test the CLI                          global      v0.0.2-dev-21-gb558a9df  not installed
  cluster             Kubernetes cluster operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  feature             Operate on features and featuregates  kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  kubernetes-release  Kubernetes release operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc

❯ ./bin/tanzu plugin install builder
[i] Installing plugin 'builder:v0.0.2-dev-21-gb558a9df' with target 'global'
[ok] successfully installed 'builder' plugin
❯ ./bin/tanzu plugin search
  NAME                DESCRIPTION                           TARGET      VERSION                  STATUS         CONTEXT
  builder             Build Tanzu components                global      v0.0.2-dev-21-gb558a9df  installed
  test                Test the CLI                          global      v0.0.2-dev-21-gb558a9df  not installed
  cluster             Kubernetes cluster operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  feature             Operate on features and featuregates  kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  kubernetes-release  Kubernetes release operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc

If the Tanzu CLI publickey is not valid anymore, users can export the env variableTANZU_CLI_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_PUBLIC_KEY_PATH to specify the latest valid public key. In the below logs, you can notice initially, the tanzu plugin search command fails as the key is invalid, but after the user specifies the new public key using the environment variable it doesn't show warning/errors and it is successful
❯ ./bin/tanzu plugin search
[!] Unable to verify the plugins discovery image signature: failed unmarshalling PEM encoded default public key: PEM decoding failed
[x] Fatal, plugins discovery image signature verification failed. The `tanzu` CLI can not ensure the integrity of the plugins to be installed. To ignore this validation please set the environment variable "TANZU_CLI_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_VERIFICATION_SKIP_LIST" to "harbor-repo.vmware.com/tanzu_cli/pkalle/plugins/plugin-inventory:latest" .  This is NOT RECOMMENDED and could put your environment at risk!

❯ export TANZU_CLI_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_PUBLIC_KEY_PATH=/Users/pkalle/co-sign/tanzu-cli-keys/cosign.pub
❯ ~/temp/tanzu_with_invalid_pubkey plugin search
  NAME                DESCRIPTION                           TARGET      VERSION                  STATUS         CONTEXT
  builder             Build Tanzu components                global      v0.0.2-dev-21-gb558a9df  installed
  test                Test the CLI                          global      v0.0.2-dev-21-gb558a9df  installed
  cluster             Kubernetes cluster operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  feature             Operate on features and featuregates  kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc
  kubernetes-release  Kubernetes release operations         kubernetes  v0.25.0-dev              not installed  tkg-aws-cc-capi115-upg-mc

Release note

Added cosign signature verification for plugin inventory image to ensure integrity of plugins

Additional information
NOTE: User can also skip the validation by exporting the environment variable: TANZU_CLI_SKIP_PLUGIN_DISCOVERY_IMAGE_SIGNATURE_VERIFICATION .
Some additional delay is observed for validating the image signature.( This shouldn't be an issue once we add caching for plugin DB image)
Special notes for your reviewer

I wasn't part of the security discussions, so I'm sorry if I'm suggesting something that was already discussed.

If the signature verification fails, CLI would show the warning message but would not throw error and users can choose to skip this validation by setting the environment variable SKIP_PLUGIN_METADATA_SIGNATURE_VERIFY

This approach implies that if a user tries to install a plugin from a hacked DB, a warning will be printed but the plugin will be installed. Part of installing a plugin is to run <plugin> info, which means the possibly hacked plugin will be run before the user has a chance to decide NOT to install it. I think the plugin install should fail unless the SKIP variable is set.

Very good point @marckhouzam. I am still thinking to have a prompt message in the oci_backed discovery and asking user whether to continue or else to panic (until the user sets environment variable SKIP_PLUGIN_METADATA_SIGNATURE_VERIFY to skip validation as it is a security issue). Do you think it would be fine or would it be an issue? I will  look into plugin install flow and see if it would be still an issue if we prompt/panic if the singature validation fails.
==

When will the real signing be done? Probably in the publishing pipeline that calls the builder plugin. Should we therefore update the builder plugin to sign the DB? The private key location would have to be specified through an env var or a flag I guess.

Yes, the real signing be done in publishing pipeline, but it would not be part of the builder plugin. In the publish pipeline, once the publishing is done and the DB OCI image is updated, there would be an extra step to sign the DB image with the private key as we cannot share the private key.

Also, can we work together to sign the local test central repo? That way we can use the full security feature while testing locally. We probably want to add the cosign command for each of the four DB images in hack/central-repo/upload-plugins.sh

Sure, we can work together. We might need to address the issue with respect to local registry certs configuration for cosign to work with local registry. This is something we can look into.

==
Finally, how can I test the use of PLUGIN_METADATA_SIGNATURE_CUSTOM_PUBLIC_KEY_PATH? I don't understand what the variable should be set to if I want to use a different key.

I updated the PR description with the steps to show how users can use the environment variable  PLUGIN_METADATA_SIGNATURE_CUSTOM_PUBLIC_KEY_PATH to use a different key

I feel better giving some context about how and when we are signing the db image

Please do create an issue/story for E2E tooling & test case implementation


Netdata issue

The software Netdata will be automatically installed even I didn't select it while installation. Besides, Netdata will also re-install after I manually removed it.
Lastly, is TLS1.3 only feature removed?

@eggydutch tls 1.3 is still there

fixed


update materialize to 0.100.1

Is this better? Added the babel pipe before materialize.js step to transpile the es6 to javascript (which stops the gulp error i mentioned)

Im closing this. It seems jquery 3 is required on the latest materialize which I assume breaks other things for now.


[AutoPR keyvault/data-plane] Updating Output Location for Keyvault - DataPlane

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/5955

Codecov Report

Merging #5228 into restapi_auto_keyvault/data-plane will increase coverage by 0.02%.
The diff coverage is n/a.

@@                         Coverage Diff                          @@
##           restapi_auto_keyvault/data-plane    #5228      +/-   ##
====================================================================
+ Coverage                             48.72%   48.74%   +0.02%
====================================================================
  Files                                  6927     6603     -324
  Lines                                194517   184959    -9558
====================================================================
- Hits                                  94770    90159    -4611
+ Misses                                99747    94800    -4947

Impacted Files
Coverage Δ

...mt/compute/v2019_03_01/models/image_os_disk_py3.py
35.71% <0%> (-64.29%)
:arrow_down:

...te/v2019_03_01/models/image_storage_profile_py3.py
50% <0%> (-50%)
:arrow_down:

...azure/mgmt/compute/v2019_03_01/models/image_py3.py
55.55% <0%> (-20.92%)
:arrow_down:

...ompute/v2019_03_01/operations/images_operations.py
14.37% <0%> (-18.57%)
:arrow_down:

...te/azure/mgmt/compute/compute_management_client.py
47.43% <0%> (-7.49%)
:arrow_down:

...ubs/azure/mgmt/notificationhubs/models/__init__.py
55% <0%> (-6.54%)
:arrow_down:

...vations/azure/mgmt/reservations/models/__init__.py
55.55% <0%> (-5.85%)
:arrow_down:

...rk/azure/mgmt/network/network_management_client.py
22.51% <0%> (-5.37%)
:arrow_down:

...7_07_01/models/orchestrator_version_profile_py3.py
50% <0%> (-3.85%)
:arrow_down:

...e/v2019_03_01/models/virtual_machine_update_py3.py
25% <0%> (-2.59%)
:arrow_down:

... and 370 more

Continue to review full report at Codecov.

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

Closing for manual update


HDFS-17138 RBF: We changed the hadoop.security.auth_to_local configur…

Description of PR
RBF: We changed the hadoop.security.auth_to_local configuration of one router, the other routers stopped working

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
18m  0s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
13m 34s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
35m 43s

trunk passed

+1 :green_heart:
compile
18m  9s

trunk passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
compile
16m 34s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
checkstyle
4m 37s

trunk passed

+1 :green_heart:
mvnsite
3m  8s

trunk passed

+1 :green_heart:
javadoc
2m 22s

trunk passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
2m 30s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
6m  3s

trunk passed

+1 :green_heart:
shadedclient
41m  0s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 26s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  4s

the patch passed

+1 :green_heart:
compile
17m 20s

the patch passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javac
17m 20s

the patch passed

+1 :green_heart:
compile
16m 26s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
javac
16m 26s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
4m 31s
/results-checkstyle-root.txt
root: The patch generated 3 new + 53 unchanged - 0 fixed = 56 total (was 53)

+1 :green_heart:
mvnsite
3m  4s

the patch passed

+1 :green_heart:
javadoc
2m 17s

the patch passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
2m 32s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
6m 15s

the patch passed

+1 :green_heart:
shadedclient
40m 56s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 51s

hadoop-common in the patch passed.

+1 :green_heart:
unit
230m  5s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
1m  7s

The patch does not generate ASF License warnings.

510m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5921

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 74605a0faec8 4.15.0-212-generic #223-Ubuntu SMP Tue May 23 13:09:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / dc0504ac98b9af96f257405b8717f4ea25e3f26b

Default Java
Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/1/testReport/

Max. process+thread count
2466 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

@goiri  Modified according to your suggestion, can you help to see what is wrong with the test case?

@Hexiaoqiao @goiri  Does this PR still need to be improved?

@Hexiaoqiao can you take a look?

This should be good to go.
Can you rebase to trigger a new build?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 48s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m  3s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
38m 15s

trunk passed

+1 :green_heart:
compile
18m 40s

trunk passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
17m 10s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
checkstyle
5m 24s

trunk passed

+1 :green_heart:
mvnsite
3m 12s

trunk passed

+1 :green_heart:
javadoc
2m 22s

trunk passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 37s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
7m 21s

trunk passed

+1 :green_heart:
shadedclient
41m 59s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 28s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  9s

the patch passed

+1 :green_heart:
compile
17m 59s

the patch passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
17m 59s

the patch passed

+1 :green_heart:
compile
17m 40s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
javac
17m 40s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m 42s

the patch passed

+1 :green_heart:
mvnsite
3m  7s

the patch passed

+1 :green_heart:
javadoc
2m 16s

the patch passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 34s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
6m 19s

the patch passed

+1 :green_heart:
shadedclient
41m 39s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
19m  7s

hadoop-common in the patch passed.

-1 :x:
unit
166m 55s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+0 :ok:
asflicense
1m  9s

ASF License check generated no output?

439m 39s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.balancer.TestBalancerRPCDelay

hadoop.hdfs.server.mover.TestMover

hadoop.hdfs.server.sps.TestExternalStoragePolicySatisfier

hadoop.hdfs.TestRollingUpgrade

hadoop.hdfs.server.balancer.TestBalancerWithEncryptedTransfer

hadoop.hdfs.server.balancer.TestBalancer

hadoop.hdfs.server.blockmanagement.TestSequentialBlockId

hadoop.hdfs.server.balancer.TestBalancerWithMultipleNameNodes

hadoop.hdfs.server.common.TestJspHelper

hadoop.hdfs.server.blockmanagement.TestBlocksWithNotEnoughRacks

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5921

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux bce36a6aab16 4.15.0-212-generic #223-Ubuntu SMP Tue May 23 13:09:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 797d58b754645123661dde18f5c9e5fae06e1a16

Default Java
Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/3/testReport/

Max. process+thread count
3135 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

I'm a little worried about the tests, those like TestRollingUpgrade seem fairly consistent but it might be because of something else. Can we double check?

I'm a little worried about the tests, those like TestRollingUpgrade seem fairly consistent but it might be because of something else. Can we double check?

ok ，I'll check.

window 10 environment, the test case runs successfully ，try to build again

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 46s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 39s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
36m  8s

trunk passed

+1 :green_heart:
compile
18m 13s

trunk passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
16m 34s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
checkstyle
4m 43s

trunk passed

+1 :green_heart:
mvnsite
3m  6s

trunk passed

+1 :green_heart:
javadoc
2m 22s

trunk passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 33s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
6m  2s

trunk passed

+1 :green_heart:
shadedclient
40m 38s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 26s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  6s

the patch passed

+1 :green_heart:
compile
17m 28s

the patch passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
17m 28s

the patch passed

+1 :green_heart:
compile
16m 33s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
javac
16m 33s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m 33s

the patch passed

+1 :green_heart:
mvnsite
3m  3s

the patch passed

+1 :green_heart:
javadoc
2m 18s

the patch passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 34s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
6m 16s

the patch passed

+1 :green_heart:
shadedclient
40m 45s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
19m 11s

hadoop-common in the patch passed.

-1 :x:
unit
239m 52s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
1m 12s

The patch does not generate ASF License warnings.

503m 58s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.datanode.TestDirectoryScanner

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5921

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 71cdb505207d 4.15.0-212-generic #223-Ubuntu SMP Tue May 23 13:09:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / f79870bcf9ca3fb22f6672689d28e810c7d68dbd

Default Java
Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/4/testReport/

Max. process+thread count
2326 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5921/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

Unfortunate that these tests are so flaky.
It'd be good to tackle TestDirectoryScanner.
I'll go ahead merging this as it is unrelated.


🔄🔐 refactor: auth; style: match OpenAI; feat: custom social login order

Summary
WIP
Change Type

[x] refactor

Testing
check if login, registration, social login and social registration works correctly
tested every possible .env variable settings
Checklist

[x] My code adheres to this project's style guidelines
[x] I have performed a self-review of my own code
[x] I have commented in any complex areas of my code
[x] I have made pertinent documentation changes
[x] My changes do not introduce new warnings
[x] I have written tests demonstrating that my changes are effective or that my feature works
[x] Local unit tests pass with my changes
[x] Any changes dependent on mine have been merged and published in downstream modules.

Is this still WIP?

Is this still WIP?

I only need to describe what I changed

Is this still WIP?

I only need to describe what I changed

Agreed, thanks for doing that!

thanks for doing this. can you resolve the conflict so I can merge?

thanks for doing this. can you resolve the conflict so I can merge?

done

going to refactor this a bit to use the new config file instead


Excerpts link to WP instead of Gatsby

The excerpt finishes with a "continue reading..." link which links to the WordPress URL and not the Gatsby URL.

Suggested adding this to the WordPress source plugin here: https://github.com/gatsbyjs/gatsby/issues/8782

We're filtering this out here:
https://github.com/GatsbyCentral/gatsby-starter-wordpress/blob/9c7ed161ed501fab8808bfb38e1da401087a9de0/src/components/PostList.js#L34-L38
Not sure how reliable this approach is. But I guess we can close this issue for now.


[move-stdlib] Port option tests to Move unit tests

This PR ports over the tests for the Option module to Move unit tests. It also removes some straggling vector tests in the functional tests, and replaces them with some additional unit tests for the Vector module.

/land


[Utils] analyze_code_size.py - Added more categories.

Added Metadata instantiation cache and Swift static function categories because they can take noticeable part of a binary.

@swift-ci Please test

This looks good to me! CC @aschwaighofer

@swift-ci Please smoke test


[BUG] --timeout flag to cmd run does not work for values above 10 seconds

Please describe the issue.
The --timeout flag to cmd run appears to take a max value of 10 seconds. Giving a value of say 15 seconds has no effect - the command still times out after 10 seconds. However it does work if the value is given less than 10, say 8 seconds.
Version Information
$ grlx version
CLI Version:
        Tag: v1.0.0
        Commit: c8745ea
        Arch: linux
        Compiler: go1.21.3
Farmer Version:
        Tag: v1.0.0
        Commit: c8745ea
        Arch: linux
        Compiler: go1.21.3

Does this bug exist on the tip of master?
Yes
Evidence
$ time -p grlx --target "*" cmd run --timeout 99  -- sleep 15
2024/03/07 12:19:56 Post "https://grlx-server-1.internal.vpc:5405/cmd/run": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
panic: Post "https://grlx-server-1.internal.vpc:5405/cmd/run": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

goroutine 1 [running]:
log.Panic({0xc000079a98?, 0x5?, 0xc000146400?})
        /usr/lib/go/src/log/log.go:432 +0x5a
github.com/gogrlx/grlx/cmd/grlx/cmd.glob..func6(0xc00011a100?, {0xc0001463f0?, 0x4?, 0xdf8b75?})
        /home/tai/code/foss/grlx/cmd/grlx/cmd/cmd.go:67 +0x35b
github.com/spf13/cobra.(*Command).execute(0x1533d20, {0xc000146380, 0x7, 0x7})
        /home/tai/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:987 +0xaa3
github.com/spf13/cobra.(*Command).ExecuteC(0x1535140)
        /home/tai/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115 +0x3ff
github.com/spf13/cobra.(*Command).Execute(...)
        /home/tai/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039
github.com/gogrlx/grlx/cmd/grlx/cmd.Execute({{0xdf93d1, 0x5}, {0xf66c10, 0x8}, {0xf66c00, 0x7}, {0xf665f8, 0x6}})
        /home/tai/code/foss/grlx/cmd/grlx/cmd/root.go:37 +0x97
main.main()
        /home/tai/code/foss/grlx/cmd/grlx/main.go:25 +0xce
real 10.01
user 0.00
sys 0.00

I suspect its because of this: https://github.com/gogrlx/grlx/blob/c7d1ee16cc38721585e4b751f9bdd08679171ab5/api/client/transport.go#L54
The go http client timeout is hardcoded to 10 seconds, so the low level http client timesout after 10 seconds.

Thank you for the bug report, and also for doing a bit of digging to determine the potential cause.
This worked in the past, so it's possible a go compiler version or module update of the stdlib broke somewhere along the way. I'll have to add a test case for ~15 seconds in the future alongside the fix to prevent future regressions.
I'll be able to start addressing this within the week. There was a related bug as well, which I haven't publicized just yet, regarding package upgrades.
Thank you!

Closed in #0e14d7
Released in v1.0.3


replaced let with var in _clone.js for consistency

We try to refrain from using const and let in favor of var, so I replaced some leftover let in _clone.js

Thanks @Berndy . There are a couple const in internal/_clone.js as well, would you mind replacing those? There is also a const here.

Whoops, apparently I did not search properly, all let and const should be gone now?

We try to refrain from using const and let in favor of var

What is the reason behind that preference?

What is the reason behind that preference?

Historically out of the box compatibility with es3. I believe the plan is to switch everything over to const/let after 1.0


Is there any book for Node-RED available??

Hi, thanks for raising an issue.
If you check out our contribution guidelines you'll see we prefer to handle this sort of thing on the mailing list, slack team or you could ask a question on Stack Overflow and tag it node-red. That way the whole Node-RED user community can help, rather than rely on the core development team.
Also, have you tried Google?
Thanks!


JupyterLab instructions are incomplete

I am planning to flesh this out to make it accessible to a newbie.

Hey @Madejski It looks like we're making the jump to jupyterlab at NCSA, so let's document that as part of PR #33. I'll make a start, renaming the notes file and adding pointers to the relevant LSST technote, and ping you when I am done.

Hey @drphilmarshall - that sounds good.  I think I know why we were getting the "raw" vs. "markdown" issues - I might have been running different versions of python at different times...  thanks for all your help earlier today!  --G

I think I resolved the problem of "Markdown" vs "Raw."  Thanks!  --Greg


Drop string value with invalid lang tag, rather than triggering error

A test case in the JSON-LD to RDF test suite, twf05 "Triples including invalid language tags are rejected", includes a language-tagged string with invalid language tag:
{
  "@id": "http://example.com/foo",
  "http://example.com/bar": {"@value": "bar", "@language": "a b"}
}

The test expects that the resulting value is dropped, resulting in an empty data set, but without error. I think this is consistent with the spec language for the expansion algorithm which only calls for the invalid language-tagged value error if the @value entry is not a string.
An alternative would be to keep the value with the invalid lang tag rather than dropping it or erroring. Then the RDF deserializaton deals with it elsewhere.

Seems good to me. Thanks :smile:


137 fixed Htlc updates after creation / update

General
Closes #137
I tryed to subscribe to blockchain updates to handle these updates automatically but did not manage to make it work correctly in this way - no update events were received in component.
Regarding this I added a callback, used in HtlcModal to notify parent component about changes made. It still had some issues, when got called right after operation completed, so I deferred it by 1s on forceUpdate.
General
Please make sure the following is done:

Pull request is onto develop
If you haven't already, have a look at

https://github.com/bitshares/bitshares-ui/blob/develop/CODE_OF_CONDUCT.md
https://github.com/bitshares/bitshares-ui/blob/develop/CONTRIBUTING.md

Code Preparation
Please review all your changes one last time before committing

[x] Check for unused code
[x] No unrelated changes are included
[x] None of the changed files are reformatting only
[x] Code is self explanatory or documented
[x] All written text is properly translated (english language)

Testing
The branch has been tested on the following browsers (desktop and mobile view)

[x] Chrome
[ ] Opera
[x] Firefox
[ ] Safari

User interface changes
Delete this section if there weren't any UI changes. Please make sure you tested your changes in all themes

[x] Dark
[ ] Light
[ ] Midnight

Please provide screenshots/licecap of your changes below

@VerevkinAlexander
The new update of the backend should deliver htlcs of a user within the full account. Please try https://github.com/bitshares/bitsharesjs/blob/554c9192139761fa833de80a560893940bd5bcaa/lib/chain/src/ChainStore.js#L921 and check if the return value directly contains HTLC. And if so, please add the htlc in the same way as https://github.com/bitshares/bitsharesjs/blob/554c9192139761fa833de80a560893940bd5bcaa/lib/chain/src/ChainStore.js#L1010 is added in https://github.com/blockchainprojects/bitsharesjs
Then use that in here.

@VerevkinAlexander
The new update of the backend should deliver htlcs of a user within the full account. Please try https://github.com/bitshares/bitsharesjs/blob/554c9192139761fa833de80a560893940bd5bcaa/lib/chain/src/ChainStore.js#L921 and check if the return value directly contains HTLC. And if so, please add the htlc in the same way as https://github.com/bitshares/bitsharesjs/blob/554c9192139761fa833de80a560893940bd5bcaa/lib/chain/src/ChainStore.js#L1010 is added in https://github.com/blockchainprojects/bitsharesjs
Then use that in here.

done

Dependency is https://github.com/blockchainprojects/bitsharesjs/pull/1

@VerevkinAlexander
What node have you connected to to test ChainStore.fetchFullAccount(accountId).get("htlcs");?

I tested it locally

I tested it locally

Did you ever see orders? What node did you connect to?
Your changes to bitsharesjs do not match what core provides, see https://github.com/bitshares/bitsharesjs/commit/e1384a52ab44f0a9d1f617c386403edd1ebd37b8

I tested it locally

Did you ever see orders? What node did you connect to?
Your changes to bitsharesjs do not match what core provides, see bitshares/bitsharesjs@e1384a5

Yes,  I saw orders and there is was only htlc variable, not form_htlcs or to_htlcs. I do not remember what node it was, but I'm sure on 200%, I`ve tested it with this variable!

@sschiessl-bcp should we do come thing with it or it can be closed?

This needs checking by me first

Time spent: 8 hours.

Forwarded.


New feature request: Support users to add executable script types in the yaml configuration file.

Summary
Currently, only the custom Parser interface is supported. If you want to add a new script type based on the executable script type supported by dagrs, you must rewrite the part of the execution script that dagrs has implemented, which is not convenient.
Background
When I use dagrs to write a build platform, I want to use the original function of dagrs to execute shell scripts, but I also want to support other types of scripts. At this time, I found that I can only rewrite the Parser interface, and dagrs has been implemented I have to rewrite the old function myself
Outcome
An interface that can be called by users to support filling new script types and their execution methods into dagrs

@QIUZHILEI @xyyy1420 ,
The parse_one(&self, id: &str, item: &Yaml) function in yaml_parser.rs currently supports only the sh and deno script types. Both types implement the Action trait:
pub trait Action {
    /// The specific behavior to be performed by the task.
    fn run(&self, input: Input, env: Arc<EnvVar>) -> Result<Output, RunningError>;
}

To enhance support for custom script types in the YAML, I propose modifying the parse_one function by adding an optional action: Option<Box<dyn Action>> parameter. The default value will be None, allowing for backward compatibility with existing code:
fn parse_one(&self, id: &str, item: &Yaml, action: Option<Box<dyn Action>>) -> Result<Task, ParsingError> {
    // ...
}

When an action is provided, the custom script type can replace the hardcoded sh and deno types. This approach enables users to extend the YAML parser with customized script types without modifying the existing implementation:
impl Action for CustomScriptType {
    fn run(&self, input: Input, env: Arc<EnvVar>) -> Result<Output, RunningError> {
        // Implement custom script execution logic here
    }
}

let custom_action: Box<dyn Action> = Box::new(CustomScriptType::new());
let result = yaml_parser.parse_one("task_id", &yaml_content, Some(custom_action));

By introducing the optional action parameter, users can extend the YAML parser's functionality to support custom script types more conveniently.


Add support for 'MessageType' and corresponding 'messageType' parameter

Add support for 'MessageType' and corresponding 'messageType' parameter in 'getMessages' method
See 'message_type' in https://quip.com/dev/automation/documentation#get-recent-messages

Awesome, looks great! I'll have a chance to validate this against the private API later this week. Thank you for contributing!

LGTM!


Make interactive a class to allow future customizations

This changes interactive from a function to a class to allow future customizations using subclassing. There are no user-visible changes at all.
For example, it should be possible to customize the way how abbreviations are converted to widgets.

👍 after in-person review of the PR.


多轮对话的历史消息对system提示词有干扰

首先感谢有你们开源的大模型。
我使用如下提示，做一个企业知识库。发现一个问题，当有历史对话的时候，模型输出会忽视系统提示中的内容。如果没有历史对话的时候，模型能够正确遵从系统提示词中的内容。不知道是不是提示的方法有问题，还是模型有特殊的系统提示标题（不是System）。
感谢！
You are a helpful, respectful and honest INTP-T AI Assistant named Buddy.
Always answer as helpfully and logically as possible, while being safe. Your answers should not include any harmful, political, religious, unethical, racist, sexist, toxic, dangerous, or illegal content. Please ensure that your responses are socially unbiased and positive in nature.
If a question does not make any sense, or is not factually coherent, explain why instead of answering something not correct. If you don't know the answer to a question, please don't share false information.
You can speak fluently in many languages, for example: English, Chinese.
You cannot access the internet, but you have vast knowledge, cutoff: 2021-09.
You are trained by OpenBuddy team, (https://openbuddy.ai, https://github.com/OpenBuddy/OpenBuddy), you are based on LLaMA and Falcon transformers model, not related to GPT or OpenAI.


Add ability to disable reload type (HTML/CSS/JS)

Supported by removing matchers. config.matchers.delete(:js).


restore pinpointing for CheckMaxTime

This can hopefully be handled in a generic event loop logic.
Note that without this the CheckMaxTime provides the same function and line number for all the call sites hence we can't tell which handler was slow.

Working on phone. Will get to it in a few hours.

Note that this can be encapsulated inside pubsub.Subscription; can set the time limits as part of the Subscription object and the ProcessChange itself can do the checks.
But for the time being let's keep this external to pubsub; note that we have some  non-subscription handlers such as timer-driven routines which we should also check for long runtimes.

@deitch @kalyan-nidumolu I've bit the bullet and moved the checks inside pubsub and removed the code which knew about nim being special. Please take a look.

I think I see what you did. You moved the actual time checking into ProcessChange() itself, since everything calls that? And then save the expected limits on each topic's subscription?
I don't love adding yet another 2 elements to Subscription as I am looking to restructure it, but that is more my problem. Overall, I like it. It eliminates a lot of boilerplate and moves the logic into one place.

I don't love adding yet another 2 elements to Subscription as I am looking to restructure it, but that is more my problem. Overall, I like it. It eliminates a lot of boilerplate and moves the logic into one place.

Yes, if we could have some form of global init of the pubsub module where each agent can provide arguments it would be less duplicate code. Perhaps we should introduce a pubsubContext which can be initialized; don't know how that will fit with your refactoring. So food for thought for now.