Nodetool task does not always work as intended

Description
After the latest upgrade to NodeJS 18 being the default, we have started seeing an issue.
We use the NodeTool task to install NodeJS 14.x, which has been working just fine up until now.
For the past few days, we have seen that it, only sometimes, installs the 14.x version, but then, right after that, it keeps using the 18.x version, which makes it fail.
Once it fails, we normally just clock rerun failed jobs, and then it works fine.
So it is not every time it fails - my guess is that not all the hosted agents has been upgraded to the latest image, so it might be lucky that the rerun uses an agent with the old image.
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[X] Windows Server 2019
[X] Windows Server 2022

Image version and build link
Windows 2019 20230214.1
Is it regression?
Windows 2019 20230129.2
Expected behavior
Once the NodeTool task has been run, it should always that version going forward.
Actual behavior
Randomly, it keeps using the Nodejs 18.x version, even when another version has been installed with the NodeTool task.
Repro steps
1: Create a pipeline with the NodeTool task and have it install the version 14.x
2: Run a command to check which nodejs version is being used.
3: Run the pipeline multiple times (might talk several rund for it to trigger) - eventually, it will use the 18.x version instead of the installed version.

Output of the NodeTool task:

2023-02-21T13:37:00.3616065Z ##[section]Starting: Install NPM version 14.18.x
2023-02-21T13:37:00.3772002Z ==============================================================================
2023-02-21T13:37:00.3772251Z Task         : Node.js tool installer
2023-02-21T13:37:00.3772395Z Description  : Finds or downloads and caches the specified version spec of Node.js and adds it to the PATH
2023-02-21T13:37:00.3772659Z Version      : 0.213.0
2023-02-21T13:37:00.3772784Z Author       : Microsoft Corporation
2023-02-21T13:37:00.3772932Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/tool/node-js
2023-02-21T13:37:00.3773132Z ==============================================================================
2023-02-21T13:37:01.4324253Z Downloading: https://nodejs.org/dist/v14.18.3/node-v14.18.3-win-x64.7z
2023-02-21T13:39:37.6345298Z ##[section]Finishing: Install NPM version 14.18.x

Output of the npm command run afterwards:

2023-02-21T13:41:07.4746696Z ##[section]Starting: Build frontend
2023-02-21T13:41:07.4867499Z ==============================================================================
2023-02-21T13:41:07.4867756Z Task         : npm
2023-02-21T13:41:07.4867871Z Description  : Install and publish npm packages, or run an npm command. Supports npmjs.com and authenticated registries like Azure Artifacts.
2023-02-21T13:41:07.4868176Z Version      : 1.215.1
2023-02-21T13:41:07.4868316Z Author       : Microsoft Corporation
2023-02-21T13:41:07.4868461Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/package/npm
2023-02-21T13:41:07.4868659Z ==============================================================================
2023-02-21T13:41:08.7216157Z [command]C:\Windows\system32\cmd.exe /D /S /C ""C:\Program Files\nodejs\npm.cmd" --version"
2023-02-21T13:41:11.4428953Z 9.3.1
2023-02-21T13:41:14.2623651Z [command]C:\Windows\system32\cmd.exe /D /S /C ""C:\Program Files\nodejs\npm.cmd" config list"
2023-02-21T13:41:15.5557817Z ; "builtin" config from C:\Program Files\nodejs\node_modules\npm\npmrc
2023-02-21T13:41:15.5559034Z
2023-02-21T13:41:15.5559426Z ; prefix = "C:\Users\VssAdministrator\AppData\Roaming\npm" ; overridden by env
2023-02-21T13:41:15.5559641Z
2023-02-21T13:41:15.5559977Z ; "global" config from C:\npm\prefix\etc\npmrc
2023-02-21T13:41:15.5560206Z
2023-02-21T13:41:15.5560603Z cache = "C:\npm\cache"
2023-02-21T13:41:15.5560794Z
2023-02-21T13:41:15.5561723Z ; "env" config from environment
2023-02-21T13:41:15.5562012Z
2023-02-21T13:41:15.5562459Z prefix = "C:\npm\prefix"
2023-02-21T13:41:15.5562970Z userconfig = "D:\a\1\npm\14591.npmrc"
2023-02-21T13:41:15.5563251Z
2023-02-21T13:41:15.5563764Z ; node bin location = C:\Program Files\nodejs\node.exe
2023-02-21T13:41:15.5564347Z ; node version = v18.14.0
2023-02-21T13:41:15.5564900Z ; npm local prefix = D:\a\1\s\frontline
2023-02-21T13:41:15.5565442Z ; npm version = 9.3.1
2023-02-21T13:41:15.5565969Z ; cwd = D:\a\1\s\frontline
2023-02-21T13:41:15.5566541Z ; HOME = C:\Users\VssAdministrator
2023-02-21T13:41:15.5567169Z ; Run npm config ls -l to show all defaults.
2023-02-21T13:41:15.5571306Z [command]C:\Windows\system32\cmd.exe /D /S /C ""C:\Program Files\nodejs\npm.cmd" run build"
2023-02-21T13:41:22.5865298Z
2023-02-21T13:41:22.5866341Z node:internal/crypto/hash:71
2023-02-21T13:41:22.5866817Z > build
2023-02-21T13:41:22.5867361Z > npm run clean && cross-env NODE_ENV=production webpack --mode production
2023-02-21T13:41:22.5867674Z
2023-02-21T13:41:22.5867802Z
2023-02-21T13:41:22.5868160Z > clean
2023-02-21T13:41:22.5868840Z > rimraf dist && rimraf ../docker/deploy/pro-rendering/wwwroot/frontend && rimraf ../docker/deploy/med-rendering/wwwroot/frontend
2023-02-21T13:41:22.5869276Z
2023-02-21T13:41:22.5869766Z   this[kHandle] = new _Hash(algorithm, xofLen);
2023-02-21T13:41:22.5870226Z                   ^
2023-02-21T13:41:22.5870376Z
2023-02-21T13:41:22.5870872Z Error: error:0308010C:digital envelope routines::unsupported
2023-02-21T13:41:22.5871411Z     at new Hash (node:internal/crypto/hash:71:19)
2023-02-21T13:41:22.5871803Z     at Object.createHash (node:crypto:133:10)
2023-02-21T13:41:22.5872286Z     at module.exports (D:\a\1\s\frontline\node_modules\webpack\lib\util\createHash.js:135:53)
2023-02-21T13:41:22.5872863Z     at NormalModule._initBuildHash (D:\a\1\s\frontline\node_modules\webpack\lib\NormalModule.js:417:16)
2023-02-21T13:41:22.5873659Z     at D:\a\1\s\frontline\node_modules\webpack\lib\NormalModule.js:452:10
2023-02-21T13:41:22.5874466Z     at D:\a\1\s\frontline\node_modules\webpack\lib\NormalModule.js:323:13
2023-02-21T13:41:22.5875301Z     at D:\a\1\s\frontline\node_modules\loader-runner\lib\LoaderRunner.js:367:11
2023-02-21T13:41:22.5876128Z     at D:\a\1\s\frontline\node_modules\loader-runner\lib\LoaderRunner.js:233:18
2023-02-21T13:41:22.5877017Z     at context.callback (D:\a\1\s\frontline\node_modules\loader-runner\lib\LoaderRunner.js:111:13)
2023-02-21T13:41:22.5877938Z     at D:\a\1\s\frontline\node_modules@akqa-frontline\js-config-webpack-plugin\node_modules\babel-loader\lib\index.js:55:103 {
2023-02-21T13:41:22.5880847Z   opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
2023-02-21T13:41:22.5881596Z   library: 'digital envelope routines',
2023-02-21T13:41:22.5882102Z   reason: 'unsupported',
2023-02-21T13:41:22.5882576Z   code: 'ERR_OSSL_EVP_UNSUPPORTED'
2023-02-21T13:41:22.5882998Z }
2023-02-21T13:41:22.5883089Z
2023-02-21T13:41:22.5883327Z Node.js v18.14.0
2023-02-21T13:41:22.6390972Z ##[warning]Couldn't find a debug log in the cache or working directory
2023-02-21T13:41:22.6408061Z ##[error]Error: Npm failed with return code: 1
2023-02-21T13:41:22.6429495Z ##[section]Finishing: Build frontend

As you can see, it uses the 18.x, even though 14.x has just been installed

Hello! This repository contains the image specs for hosted runners, please report AzDo tasks issues to https://github.com/microsoft/azure-pipelines-tasks

@mikhailkoliada also when this clearly is an issue with the latest image from in here?


Change EXIT_PROCESSOR_SLA_MARGIN to EXIT_PROCESSOR_SLA_SECONDS

#1399
Overview
This unifies sla_margin to hold values in seconds instead of the number of blocks and renames EXIT_PROCESSOR_SLA_MARGIN to EXIT_PROCESSOR_SLA_SECONDS
EXIT_PROCESSOR_SLA_MARGIN_FORCED hasn't been renamed
Changes

Updated to the new name
Changed logic to work with seconds
Modified Tests
EXIT_PROCESSOR_SLA_MARGIN_FORCED is unchanged till now

Coverage remained the same at ?% when pulling db4f1a226121a2651d98db97c73957127928c0a5 on souradeep/margin_to_seconds into 8189b812b4b3cf9256111bd812235fb342a6fd50 on master.

Also, could you add this change to https://github.com/omisego/elixir-omg/blob/master/CHANGELOG.md under the Unreleased header?

@souradeep-das Is this ready for another review?

Also @pnowosie asking for a re-review to confirm the latest changes. Thanks :bow:

Adding upgrade path required label so we can collect them up and inform infra/users easily of manual upgrade tasks needed.

@unnawut do we need to update any env vars?

@unnawut do we need to update any env vars?

Yeah the ones you have in the infra PR should suffice

Hey @InoMurko! Thanks for the review :bow:
So, eth_timestamp_now is mostly storing the timestamp ( eth_height_now ) replacing eth_height_now we had previously.
Previously we had -

late_invalid_exits =
      Enum.filter(invalid_exits, fn {_, %ExitInfo{eth_height: eth_height}} ->
        eth_height + sla_margin <= eth_height_now

Since, we added the exit timestamp already, using it for the check and checking with timestamp(eth_height_now)

late_invalid_exits =
       Enum.filter(invalid_exits, fn {_, %ExitInfo{block_timestamp: block_timestamp}} ->
        block_timestamp + sla_seconds <= eth_timestamp_now

assigning the actual timestamp of the block here,
https://github.com/omgnetwork/elixir-omg/pull/1491/files#diff-f1ce1871bf4b96d60bda0fbd02e3891cR632
For the tests,
trying for the exit_timestamp to be similar (in value) to the exit_height, mostly fixing the value of the exit_timestamp for the tests to constant like we do for eth_height.
And then passing values for eth_timestamp_now as the number of seconds that is ++ from the block_timestamp (exit_timestamp)
https://github.com/omgnetwork/elixir-omg/pull/1491/files#diff-feeb2e7cdff5093e568214f358154985R46
Should eth_timestamp_now be renamed for clarity?

Do we need a successive change for the change in API endpoint? @InoMurko @unnawut @T-Dnzt


Bugfix, filter defaults and readme changes.

Fixes a bug where filters weren't being passed to RPC correctly.
Changes default to no filters (meaning no logs) rather than defaulting to a filter that includes all logs.
Updates readme with full example.

Rebasing now...

Edited the callback-style examples in README (hopefully I didn't botch the types...).  Otherwise looks good, merging.


fix: Ensure app-dir is appended to path during autodiscovery.

Pull Request Checklist

[ ] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR

Description

This PR fixes a bug which caused the --app-dir option to the litestar CLI to not be propagated during autodiscovery.

Close Issue(s)

Fixes #2266

Notes
I am unclear what kind of tests should be written for this, since the existing test should capture it, yet I'm not sure why it doesn't.

I've added another test, however that test also passes without having to pass app_dir in https://github.com/litestar-org/litestar/blob/c36dba249337062266fe2175a256ed7de099fa0e/litestar/cli/main.py#L53
@cofin
Is this line only used for testing?
https://github.com/litestar-org/litestar/blob/c36dba249337062266fe2175a256ed7de099fa0e/litestar/cli/main.py#L52

I feel like we need to override the path that's passed into the autodiscover function on this one.
One way to do that would be to override the cwd:
        cwd = Path().cwd() if app_dir is None else Path(app_dir)
        cwd_str_path = str(cwd)
        if cwd_str_path not in sys.path:
            sys.path.append(cwd_str_path)

I feel like we need to override the path that's passed into the _autodiscover_app function on this one.
One way to do that would be to override the cwd:
        cwd = Path().cwd() if app_dir is None else Path(app_dir)
        cwd_str_path = str(cwd)
        if cwd_str_path not in sys.path:
            sys.path.append(cwd_str_path)

You would then remove the additional if conditional that was added.

I just tried it, lots of failures, all in the mock cli tests test_core_commands.py, I think both directories need to be added to the path.

Nice work!

@all-contribuors add @sykloid for bug, code, and test

@all-contributors add @sykloid for bugs, code, and tests


Bump sqlalchemy version

Related Issue(s):

Recommended by https://github.com/sqlalchemy/alembic/issues/1196#issuecomment-1458435827 to fix an alembic breakage

Description:
Doesn't need a CHANGELOG entry.
PR Checklist:

[x] Code is formatted and linted (run pre-commit run --all-files)
[x] Tests pass (run make test)
[x] Documentation has been updated to reflect changes, if applicable, and docs build successfully (run make docs)
[ ] Changes are added to the CHANGELOG.

Closing as not needed, https://github.com/sqlalchemy/alembic/commit/3c46243f23bd258744e3417566a52ca3ab312d70.


Update yotube links in README.md

Update yotube links in README.md

Motivation and context

N/A
How has this been tested?

N/A
Checklist

[x] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG file
[x] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2020 Intel Corporation
#
# SPDX-License-Identifier: MIT

Pull Request Test Coverage Report for Build 7116

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.004%) to 69.73%

Files with Coverage Reduction
New Missed Lines
%

cvat/apps/engine/media_extractors.py
1
77.29%

Totals

Change from base Build 7115:
-0.004%

Covered Lines:
11761

Relevant Lines:
16408

💛  - Coveralls


chaincode_instantiate faild

I can run setup_blockchainNetwork_v2.sh success,and in docker-dind I can find chaincode images.

But in org1peer1,when I query chaincode,is error

Thanks!

@FKmyCode , which Kubernetes version you are using?

@FKmyCode - Please take the latest code and retry. I have updated the code repository for the Kubernetes 1.16. It might work for you now. Thanks.

@FKmyCode , Hope it has worked for you. Closing this issue because of no activity. Feel free to reopen or open a new issue if required. Thanks.


Docs Search by Algolia returns 403

Hello!
I'm trying to search in the spring-data docs, but the UI doesn't display any results. When I inspected the Network tab, I noticed that Algolia endpoint is returning 403 Forbidden with the following response:
{"message":"Invalid Application-ID or API key","status":403}

Steps to Reproduce:

Go to spring-data docs.
Attempt to use the search functionality.
Observe the lack of results and check the browser's Network tab for errors.

I apologize if this is not the right place to report such an incident, and thanks for the great project!

Thanks for reporting this. And yes, this is the correct place. We'll look into it.

The correct link to the documentation is https://docs.spring.io/spring-data/relational/reference/index.html
and this affects JPA as well, but not boot. So I guess something is wrong with the Spring Data setup.


Docker image not working

I am using the docker image quay.io/vitkl/cell2location as provided and once I launch a job with bsub and a Jupiter notebook, I am able to import cell2location, but there is no package named scvi. Additionally, I cannot access various modules within cell2location. Is there a more updated docker image I should run or am I doing something wrong on my end?
Thank you.

Hi @prete
If you have time would be great if you could help and take a look at why our automated GitHub workflow fails to produce Docker and Singularity images when new releases are created.

Hi, I also encountered the same problem. And have you solved it

You don't need to use the docker image. You can just follow the installation instructions here https://github.com/BayraktarLab/cell2location

You don't need to use the docker image. You can just follow the installation instructions here https://github.com/BayraktarLab/cell2location

Thank you, I gave up using docker，and in the conda download to be able to work well


Bump build number and re-render with Python 3.11.3

My goal is to rebuild with this Python: https://anaconda.org/conda-forge/python/files?version=3.11.3

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Why Python 3.11.3 is necessary here? Is there a problem with the previous Python 3.11.x builds? I would merge #65 first but we need to use build number 3 there for consistency.


Add a vm.iter cheatecode

Component
Forge
Describe the feature you would like
In my development practice, i came across scenarios where I had to iterate through all possible values, but i found that Foundry didn't provide the tools or cheatcodes. So I had to do it that way:
address[] private tokens = [WBTC, USDC, USDT, UNI, LINK];
for (uint256 _index = 0; _index < tokens.length; ++_index) {
            deal(tokens[_index], alice, assetAmount);

            IERC20(tokens[_index]).approve(address(gloopZapper), assetAmount);
            gloopZapper.mintWGLP(
                tokens[_index],
                assetAmount,
                0,
                0
            );

It would be greater to provide a cheatecode like vm.iter() to iterate through all values.
Additional context
No response

Can you expand on how this cheatcode would work with some examples? I'm not sure I understand what this would do that you can't do with a regular solidity for loop?

Yes, it can be finished by for loop. But if there is a iterator to help us to do it, foundry will become more convenient and powerful

I still don't understand how this would look or work, given the limitations of solidity. I'm going to close this as a result, but can reopen if you share a more detailed proposal :)

This is the using example
address[] private tokens = [WBTC, USDC, USDT, UNI, LINK];

function test(address _token) public {
  _token = iter(_token, tokens);
  deal(_token, alice, assetAmount);
  IERC20(_token).approve(user, assetAmount);
  // Do sth else
}

It's kind of like vm.assume and bound in foundry, but the difference is vm.assume and bound only run a limited number of scenarios in fuzzy tests, I hope to have a cheatcode vm.iter() to iterate through all discrete values in an array.

Yes, it runs each discrete value in the array once. It's similar to #858 and #4839, but I guess not exactly.

If all type combinations become overloaded, you can divide them into different types, For example, vm.iter_Address(), vm.iter_Uint() and so on. I think this is more user friendly than requesting an ABI.

Thanks for your suggestion, marking as not planned per discussion above as it is currently not within scope and effectively superseded by fuzz fixtures: https://book.getfoundry.sh/forge/fuzz-testing


Use Bytetrack with custom detector

Hello! I would like to use Bytetrack with my own custom detector.
I followed the example you gave in your README document, but I wasn't really sure how to interpret the results.
I ran this block of code
from yolox.tracker.byte_tracker import BYTETracker tracker = BYTETracker(args) for image in images:    dets = detector(image)    online_targets = tracker.update(dets, info_imgs, img_size)
and online_targets returned something like this
[OT_1_(1-567), OT_8_(291-567), OT_10_(337-567)]  [OT_1_(1-568), OT_8_(291-568), OT_10_(337-568)]    [OT_1_(1-569), OT_8_(291-569), OT_10_(337-569), OT_14_(492-569)] [OT_1_(1-570), OT_8_(291-570), OT_10_(337-570), OT_14_(492-570), OT_18_(557-570)] [OT_1_(1-571), OT_8_(291-571), OT_10_(337-571), OT_14_(492-571)] [OT_1_(1-572), OT_8_(291-572), OT_10_(337-572)] [OT_1_(1-573), OT_8_(291-573), OT_10_(337-573), OT_18_(557-573), OT_14_(492-573)]
I took a closer look and printed out the tlwh attribute of each object, and discovered that every [OT_1_] object has the same tlwh.
From my understanding, shouldn't it be updated every frame to show the new position of the bounding box?
[729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7] [729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7] [729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7] [729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7] [729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7] [729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7] [729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7] [729.42936364<PHONE_NUMBER>9  96.1745278<PHONE_NUMBER>7]
Thanks!

just a question, how did u get args?


S3 Asset Store: Presigned upload POST request and directly upload to S3

It appears that the S3 asset store does not support asset directly upload to S3. The server tells the client to upload to skygear-server and the skygear-server upload the asset to S3 on the client’s behalf.
This is not optimal as it is more efficient for the client to directly upload to S3, reducing throughput in skygear-server.
The S3 Asset Store should work like the cloud asset store, which generate a presigned upload POST request.

This maybe related to #594


Last song remembered at startup but not last playlist

Hi, the web player, at startup, remembers the last song played but not the last playlist. Indeed, it plays other songs in the album of the last song.

Yeah this is a common issue with Spotify Web Player itself than the application.


Fresh<EMAIL_ADDRESS>installation - conflict with<EMAIL_ADDRESS>when running  nx g @nx-plus/vue:app my-vue-app

I'm trying to get this package working. I have uninstalled everything nx-related and installed<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>@nx-plus/nuxt and @nx-plus/vue.
Running  nx g @nx-plus/vue:app my-vue-app leads to the following error:
user@MY-PC:~/workspace/nx-demo$ nx g @nx-plus/vue:app my-vue-app
✔ Which style format would you like to use? · css
✔ Would you like to configure routing for this application? (y/N) · true
✔ Which version of Vue.js would you like to use? · 2
✔ Use Babel alongside TypeScript? (y/N) · true

⠧ Installing packages (npm)...npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@typescript-eslint/parser
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@nrwl/eslint-plugin-nx
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /home/user/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/user/.npm/_logs/2021-12-31T07_52_40_266Z-debug.log
✖ Package install failed, see above.
UnsuccessfulWorkflowExecution [Error]: Workflow did not execute successfully.
    at ChildProcess.<anonymous> (/home/user/workspace/nx-demo/node_modules/@angular-devkit/schematics/tasks/package-manager/executor.js:134:31)
    at ChildProcess.emit (node:events:390:28)
    at maybeClose (node:internal/child_process:1064:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)
The generator workflow failed. See above.

Upgrading to<EMAIL_ADDRESS>fails
:~/workspace/nx-demo$ npm install<EMAIL_ADDRESS>--save-dev
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@typescript-eslint/eslint-plugin
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@vue/eslint-config-typescript
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /home/user/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/user/.npm/_logs/2021-12-31T08_02_55_821Z-debug.log

Downgrading to<EMAIL_ADDRESS>fails<EMAIL_ADDRESS>was installed, despite explicitly setting everything to 12.0.0)
~/workspace/nx-demo$ npm install<EMAIL_ADDRESS>--save-dev
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@typescript-eslint/eslint-plugin
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@vue/eslint-config-typescript
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /home/user/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/user/.npm/_logs/2021-12-31T08_08_10_297Z-debug.log

I needed to remove npm remove
npm remove @nrwl/eslint-plugin-nx @vue/eslint-config-typescript
npm install<EMAIL_ADDRESS>--save-dev
and now it works.

Do you have plans to migrate to the latest nx version so far or even merge this package into the core nx project?

I'm currently working on migrating the packages to v13

Same issue Here.
On Node 14.17.5 ( A pseudo recent LTS version).
I've tested all the above solutions and followed the installation guide ( with a<EMAIL_ADDRESS>install). Not working.
And i tried with Node 12.6.1, and everything go smooth. Very weird, and very boring, because node 12.x.x support is about to drop on april of this year :/
I think migrate to NX v13 and try to follow NX versions is a good move.
Anyway thanks for this package.

You should consider upgrading @vue/eslint-config-typescript to 10.0.0, that fixes the error above 👍


Update tox/travis configuration

Fix support for Django 1.7
Add Django 1.8 to test matrix
Add explicit django CMS version to tests
Removed special cases from setup.py

Ping @intellectronica @mkoistinen for review

If you can fix the typo in the tox env list then LGTM =)

@mkoistinen done


proper instruction!

can you please provide proper instruction about that!

I'm planning to make it an npm package, so I may need to modify several parts of the code (and creating a README..).
You can expect it to be done in a few days.

Okie waiting! :-D


Performance: a capture on HL2 visibly glitches the holograms

When I turn this on, every time a stamp is taken, there's a visible lurch in the hologram tracking.
Would doing some of the more intensive parts (histogram, light direction) over several frames be a possible performance enhancement?

I have the same issue. Plays great in Unity with remoting, but in the actual build it lurches and smears every couple of seconds.
Also, forces an API update when building in Unity 2019.4., so one or more of your packages is out of date.


Add README

We need some proper documentation in the README.

Improved in e9f1378d5a0cd347825f9479919684bd02f50979, but we still need more documentation.

See #28.


Error while compiling into APK: no compiled python is present to zip, skipping

Trying to compile my project into APK I had the following error:

How can I handle it?

are you using p4a master? also, if you read the error message, there are actually instructions on what to do before you report an issue, there is simply not enough information here to help.

Trying to compile my project into APK I had the following error:

How can I handle it?

they can resolve it? I have the same problem
ubuntu 18

Trying to compile my project into APK I had the following error:

How can I handle it?

they can resolve it? I have the same problem
ubuntu 18

Unfortunately I can't remember, but is not worth to try to generate an apk via buildozer. You'll spend a lot of time trying to do that and at the end your app won't run or another error happens. I really recommend to learn Java and develop via Android Studio, that is the most productive way to create Android apps, and the apk generation is instant. There are a lot of courses in Udemy that in less than two hours can teach you how to develope, generate and install apps in your own phone or virtual devices. That's what I did, what is being productive for me and giving me some money too. Feel free to disagree or keep trying.

We can't help when people don't provide the asked information about the issue they have, this issue has been closed for lack of information, @resourceldg if you have more, please open a new issue with the full build log, and the versions of things you use.


Add Sauna command schemas & HipChat responder schema/avro

This PR adds the following schemas:

com.snowplowanalytics.sauna.commands/command/jsonschema/1-0-0 - a JSON schema for a Sauna command. Represented by a self-describing JSON which itself contains two self-describing JSONs - note the schemas for both envelope and command only accept Iglu-based sources.

https://github.com/snowplow/sauna/wiki/Commands-for-analysts#anatomy-of-a-command

com.snowplowanalytics.sauna.commands/envelope/jsonschema/1-0-0 - a JSON schema for a Sauna command's envelope, which identifies the command and contains execution-related metadata.

https://github.com/snowplow/sauna/wiki/Commands-for-analysts#anatomy-of-a-command

com.hipchat.sauna.commands/send_room_notification/jsonschema/1-0-0 - a JSON schema example of a Sauna command's action to be used for the HipChat Sauna responder.

Source: https://github.com/snowplow/sauna/wiki/HipChat-Responder-user-guide#213-example-command

com.snowplowanalytics.sauna.responders/HipchatConfig/avro/1-0-0 - an Avro configuration for the HipChat Sauna responder.

Source: https://github.com/snowplow/sauna/wiki/HipChat-Responder-setup-guide

@alexanderdean: made all the required tweaks

Thanks @rzats ! Asking @chuwy to review it next...

Hey @rzats - this is looking good. Can you now rebase please into four commits per the tickets:
https://github.com/snowplow/iglu-central/milestone/69

@alexanderdean done!

LGTM! Thanks, will get this released tonight...

Closing as cherry-picked into release branch


fix: Align activity item styling

This PR resolves ONYX-447
Description
Align activity rail item styling to match activity screen.
Before
| |![Simulator Screen Shot - iPhone 14 Pro - 2023-10-13 at 12 11 39]

After

PR Checklist

[ ] I have tested my changes on iOS and Android.
[ ] I hid my changes behind a feature flag, or they don't need one.
[ ] I have included screenshots or videos, or I have not changed the UI.
[ ] I have added tests, or my changes don't require any.
[ ] I added an app state migration, or my changes do not require one.
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Align activity rail item styling to match activity screen. - ole

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Cross-platform user-facing changes (Align activity rail item styling to match activity screen. - ole)

  Generated by :no_entry_sign: dangerJS against e279e4f2172e82af983fdcab251e2f7082388a81


helm upgrade fails with spec.clusterIP: Invalid value: "": field is immutable

When issue helm upgrade, it shows errors like, ("my-service" change from "clusterIP: None" to "type: LoadBalancer" without field clusterIP)
Error: UPGRADE FAILED: Service "my-service" is invalid: spec.clusterIP: Invalid value: "": field is immutable

However, all other pods with new version are still going to be restarted, except that "my-service" Type does not change to new type "LoadBalancer"
I understand that why upgrade failed because helm does not support changing on some certain fields. But why helm still upgrades other services/pods by restarting it. Should helm does nothing if there is any error during the upgrade? I excepted helm to treat the whole set of services as a package to either upgrade all or none, but seems my expectation might be wrong.
And if we ever end up in such situation, then what we should to get out the situation? like how to upgrade "my-service" to have new type?
And if I use --dry-run option, helm does not show any errors.
Is this consider a bug or expected, i.e. upgrade throws some error but some service still gets upgraded.

Output of helm version:
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.10-gke.27", GitCommit:"145f9e21a4515947d6fb10819e5a336aff1b6959", GitTreeState:"clean", BuildDate:"2020-02-21T18:01:40Z", GoVersion:"go1.12.12b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
GKE and Minkube

Not enough information has been provided to reproduce. Please tell us how to create a reproducible chart, and which Helm commands you used.

Hi, here are the reproduce steps
Having two services yaml file as below.
nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

prometheus.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: prometheus
spec:
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - image: prom/prometheus
        name: prometheus
        ports:
        - containerPort: 9090
        imagePullPolicy: Always
      hostname: prometheus
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
spec:
  selector:
    app: prometheus
  clusterIP: None
  ports:
  - name: headless
    port: 9090
    targetPort: 0

Then put there two files in helm1/templates/ then install. It shows prometheus service uses clusterIP and nginx version is 1.14.2
# helm upgrade --install test helm1
Release "test" does not exist. Installing it now.
NAME: test
LAST DEPLOYED: Tue Apr 21 20:42:55 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   <IP_ADDRESS>    <none>        443/TCP    35d
prometheus   ClusterIP   None         <none>        9090/TCP   7s

# kubectl describe deployment nginx |grep Image
    Image:        nginx:1.14.2

Now update the section for nginx.yaml to new version 1.16
        image: nginx:1.16

and prometheus.yaml by changing it to LoadBalancer.
spec:
  selector:
    app: prometheus
  ports:
  - name: "9090"
    port: 9090
    protocol: TCP
    targetPort: 9090
  type: LoadBalancer

Now put them as helm2 and do the upgrade. Then you can see the upgrade throw some errors, but the nginx service goes through, by upgrade to a new version, but the prometheus is not upgraded as it is still using Cluster IP.
# helm upgrade --install test helm2
Error: UPGRADE FAILED: cannot patch "prometheus" with kind Service: Service "prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable

# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   <IP_ADDRESS>    <none>        443/TCP    35d
prometheus   ClusterIP   None         <none>        9090/TCP   5m34s

# kubectl describe deployment nginx |grep Image
    Image:        nginx:1.16

helm list shows
# helm list
NAME	NAMESPACE	REVISION	UPDATED                                	STATUS	CHART                                    	APP VERSION
test	default  	2       	2020-04-21 20:48:20.133644429 -0700 PDT	failed

helm history
# helm history test
REVISION	UPDATED                 	STATUS  	CHART       APP VERSION	DESCRIPTION
1       	Tue Apr 21 20:42:55 2020	deployed	helm-helm	<IP_ADDRESS>    	Install complete
2       	Tue Apr 21 20:48:20 2020	failed  	helm-helm	<IP_ADDRESS>    	Upgrade "test" failed: cannot patch "prometheus" with kind Service: Service "prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable

We have the same behavior with v3.2.0, downgrading to v3.1.3 is our temporary fix

I've got a lot of this with my Helm 2 -> 3 migration. When trying to upgrade the converted Releases for the first time I get a lot of this. This is for Nginx Ingress, Prometheus Operator, Graylog and Jaeger charts so far. Most of them I'm content with just deleting the services and letting Helm recreate them but for Nginx Ingress this isn't an option...

Just found this https://github.com/helm/helm/issues/6378#issuecomment-557746499 which explains the problem in my case.

Closing as a duplicate of #6378. @cablespaghetti found the deeper explanation for this behaviour, which is described in great detail.
Let us know if that does not work for you.

@GaramNick why would downgrading fix this for you? Can you elaborate more on “what” was fixed by downgrading?

@bacongobbler While you're here. Is there any way to fix this situation without deleting the release and re-deploying? I can't seem a way to do that under helm 2 or 3. I want to hack the existing release data so Helm thinks the clusterIP has always been omitted and so no patch is necessary.

Have you tried kubectl edit?

We have the same issue and downgrading to 3.1.3 fixed it also for us. My guess is that it has to do with the new logic in https://github.com/helm/helm/pull/7649/commits/d829343c1514db17bee7a90624d06cdfbffde963 considering this a Create and not an update thus trying to set empty IP and not reusing the populated one

Interesting find. thank you for investigating.
@jlegrone any chance you might have time to look into this?

@bacongobbler Our CI/CD pipeline uses Helm to update our application that includes a Service with type ClusterIP. The command:
helm upgrade --install --force \
        --wait \
        --set image.repository="$CI_REGISTRY_IMAGE" \
        --set image.tag="$CI_COMMIT_REF_NAME-$CI_COMMIT_SHA" \
        --set image.pullPolicy=IfNotPresent \
        --namespace="$KUBE_NAMESPACE" \
        "$APP_NAME" \
        ./path/to/charts/

On v3.2.0 this command fails with Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable
On v3.1.3 this works fine.
Let me know if you like to have more info.

Same here. We had the following service.yaml working fine with helm2 for many many months.
After migration, the helm 3.2 helm upgrade command failed with the save error as above. Downgrading to 3.1.3 resolved it.
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.global.name }}
  namespace: {{ index .Values.global.namespace .Values.global.env }}
  labels:
     microservice: {{ .Values.global.name }}
spec:
   type: ClusterIP
   ports:
   - port: 8080
   selector:
      microservice: {{ .Values.global.name }}

We have the same issue and downgrading to 3.1.3 fixed it also for us. My guess is that it has to do with the new logic in d829343 considering this a Create and not an update thus trying to set empty IP and not reusing the populated one

@n1koo Can you explain why you think this is the code causing the issue? As this is the install and not upgrade code, and also the code in 3.1 is a ``create` and it works.

Can you test #8112 and see if that fixes your issue?

I am reviewing the issue with @adamreese , and we think it is the patch that @n1koo identified. The Create method will bypass the normal 3-way diff on the Service, which will result in the service's clusterIP being set to "" instead of the value populated by Kubernetes. As a result, the manifest sent to the API server appears to be resetting the cluster IP, which is illegal on a service (and definitely not what the user intended).
We're still looking into this and I will update if we learn more.

So https://github.com/helm/helm/issues/6378#issuecomment-557746499 is correct. Please read that before continuing on with this issue. If clusterIP: "" is set, Kubernetes will assign an IP. On the next Helm upgrade, if clusterIP:"" again, it will give the error above, because it appears to Kubernetes that you are trying to reset the IP. (Yes, Kubernetes modifies the spec: section of a service!)
When the Create method bypasses the 3-way diff, it sets clusterIP: "" instead of setting it to the IP address assigned by Kubernetes.
To reproduce:
$ helm create issue7956
$ # edit issue7956/templates/service.yaml and add `clusterIP: ""` under `spec:`
$ helm upgrade --install issue7956 issue7956
...
$ helm upgrade issue7956 issue7956
Error: UPGRADE FAILED: cannot patch "issue-issue7956" with kind Service: Service "issue-issue7956" is invalid: spec.clusterIP: Invalid value: "": field is immutable

The second time you run the upgrade, it will fail.

I cannot reproduce @IdanAdar 's case on master.

@GaramNick there is not enough info about the service you are using for us to reproduce your error.

My situation:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
given the following service template:
apiVersion: v1
kind: Service
metadata:
  name: {{ include "app.fullname" . }}
  labels:
    {{- include "app.labels" . | nindent 4 }}
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: {{ include "app.fullname" . }}_mapping
      prefix: /{{ include "app.fullname" . }}
      host: "^{{ include "app.fullname" . }}.*"
      host_regex: true
      service: {{ include "app.fullname" . }}.{{ .Release.Namespace }}
      rewrite: ""
      timeout_ms: 60000
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - Authorization
        - x-client-id
        - x-client-secret
        - x-client-trace-id
        - x-flow-proto
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: {{ include "app.fullname" . }}_swagger_mapping
      ambassador_id: corp
      prefix: /swagger
      host: "^{{ include "app.fullname" . }}.corp.*"
      host_regex: true
      service: {{ include "app.fullname" . }}.{{ .Release.Namespace }}
      rewrite: ""
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - x-client-id
        - x-client-secret
        - Authorization
        - x-flow-proto
  namespace: {{ .Release.Namespace }}
spec:
  type: {{ .Values.service.type }}
  selector:
    {{- include "app.selectorLabels" . | nindent 4 }}
  ports:
  - port: {{ .Values.service.port }}
    name: http-rest-hub
    targetPort: http-rest
  - port: {{ .Values.service.healthPort }}
    name: http-health
    targetPort : http-health

which results in the following after upgrade --install:
apiVersion: v1
kind: Service
metadata:
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: hub-alt-bor_mapping
      prefix: /hub-alt-bor
      host: "^hub-alt-bor.*"
      host_regex: true
      service: hub-alt-bor.brett
      rewrite: ""
      timeout_ms: 60000
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - Authorization
        - x-client-id
        - x-client-secret
        - x-client-trace-id
        - x-flow-proto
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: hub-alt-bor_swagger_mapping
      ambassador_id: corp
      prefix: /swagger
      host: "^hub-alt-bor.corp.*"
      host_regex: true
      service: hub-alt-bor.brett
      rewrite: ""
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - x-client-id
        - x-client-secret
        - Authorization
        - x-flow-proto
    meta.helm.sh/release-name: alt-bor
    meta.helm.sh/release-namespace: brett
  creationTimestamp: ...
  labels:
    app: hub
    app.kubernetes.io/instance: alt-bor
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: hub
    app.kubernetes.io/version: v1.6.0-rc.26
    deploy.xevo.com/stackname: bor-v0.1-test
    helm.sh/chart: hub-0.0.4
    owner: gateway
    ownerSlack: TODOunknown
  name: hub-alt-bor
  namespace: brett
  resourceVersion: ...
  selfLink: ...
  uid: ...
spec:
  clusterIP: <IP_ADDRESS>
  ports:
  - name: http-rest-hub
    port: 80
    protocol: TCP
    targetPort: http-rest
  - name: http-health
    port: 90
    protocol: TCP
    targetPort: http-health
  selector:
    app.kubernetes.io/instance: alt-bor
    app.kubernetes.io/name: hub
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

If I then upload this exact same chart as version 0.0.5 and upgrade --install again I get the following:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable
The only difference is the value of the helm.sh/chart label which now has a value of hub-0.0.5
This is a huge blocker.

@GaramNick there is not enough info about the service you are using for us to reproduce your error.

@technosophos What do you need? Happy to provide more details!

Update! The update fails ONLY when using helm upgrade --install w/ --force. Less of a blocker now.

Oh! That is interesting. That should make the error easier to track down.

Hello @technosophos @bacongobbler we have the same 2 issues:
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

Issue
We have Service template without clusterIP but kubernetes will assign clusterIP automatically:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

after migrate to helm 3 with helm 2to3 convert and try upgrade the same release helm3 upgrade --install --force:
failed to replace object: Service "dummy-stage" is invalid: spec.clusterIP: Invalid value: "": field is immutable

if i will do the same without --force -> helm3 upgrade --install works fine wothout error.

Issue
if I want change spec.selector.matchLabels which are immutable field without --force I get error:

cannot patch "dummy-stage" with kind Deployment: Deployment.apps "dummy-stage" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/name":"web-nerf-dummy-app"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

if I will do the same with --force I get error:
	 failed to replace object: Deployment.apps "dummy-stage" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/name":"web-nerf-dummy-app"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

apiVersion: v1
kind: Service
metadata:
  name: zipkin-proxy
  namespace: monitoring
spec:
  ports:
  - port: 9411
    targetPort: 9411
  selector:
    app: zipkin-proxy
  type: ClusterIP

---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: zipkin-proxy
  namespace: monitoring
spec:
  replicas: {{ .Values.zipkinProxy.replicaCount }}
  template:
    metadata:
      labels:
        app: zipkin-proxy
      annotations:
        prometheus.io/scrape: 'true'
    spec:
      containers:
      - image: {{ .Values.image.repository }}/zipkin-proxy
        name: zipkin-proxy
        env:
        - name: STORAGE_TYPE
          value: stackdriver

helm upgrade -i --debug --force --namespace monitoring zipkin-proxy --values ./values.yaml.tmp .
I have tried with removing the force option. I tried with v3.1.3, v3.2.0 as well as v3.1.3.  still the same issue.

I am having this issue when the Helm Chart version changes and having an existing deployment.
Using Helm v3.2.0

I can confirm that downgrading to 3.1.2 works.

@gor181 How can we reproduce that? What broke on 3.2 but worked on 3.1? The chart (or at least svc template) and commands are what we need to be able to figure out what changed.
@azarudeena @alexandrsemak -- for both of you, the --force flag is what is causing this. If you remove --force, does the upgrade work?

@technosophos did try without force didn't work. Planning to try with 3.1.2

@azarudeena can you please provide a set of instructions to reproduce your issue? You showed some output of a service and a deployment template, but then you also referenced a values.yaml.tmp which we don't know the output of.
Can you please provide a sample we can use to reproduce your issue?

@bacongobbler I am sharing the structure.
Chart.yaml
apiVersion: v1
description: Deploys Stackdriver Trace Zipkin Proxy
name: zipkin-proxy
version: 1.0.0

I have put my template yaml above,
my value yaml.tmp is as below
zipkinProxy:
replicaCount: 1
image:
repository: openzipkin/zipkin
I package it as helm package --version  using the same with upgrade. Let me know if this works? WIll update here once my I try with 3.1.2

I faced the same issue, but with upgrading a helm chart via terraform helm provider.
After I had changed the force_update = true to force_update = false, the error went away.

I am having this issue when the Helm Chart version changes and having an existing deployment.
Using Helm v3.2.0

Disabling  --force flag made it work.

@technosophos --force resolve issue with ClusterIP when you migrate to helm 3 as helm 2 don't try upgrade ClusterIP when helm 3 do..
Helm 3 not able resolve issue with immutable filed as matchLabels

Kubernetes modifies the spec: section of a service

Should this be considered a design flaw in Kubernetes at root? https://kubernetes.io/docs/concepts/services-networking/service/#choosing-your-own-ip-address makes no mention of this behavior. I would have expected an assigned value to be placed in the status section.
(A similar behavior exists for the .spec.nodeName of a Pod, but that is unlikely to affect Helm users.)

v3.2.3: it fails with --force, it passes w/o --force. No ClusterIP: in chart-template. Which I guess https://github.com/helm/helm/pull/8000/files was supposed to fix. Can it be buried in the helper.Replace?

I am observing this issue on 3.2.3 but not on 3.2.0. Disabling force also was a usable workaround.

FYI, the issue raised by the OP and the comments raised here about --force are separate, discrete issues. Let's try to focus on OP's issue here.
To clarify, the issue OP is describing is a potential regression @n1koo identified in https://github.com/helm/helm/issues/7956#issuecomment-620749552. That seems like a legitimate bug.
The other comments mentioning the removal of --force working for them is intentional and expected behaviour from Kubernetes' point of view. With --force, you are asking Helm to make a PUT request against Kubernetes. Effectively, you are asking Kubernetes to take your target manifests (the templates rendered in your chart from helm upgrade) as the source of truth and overwrite the resources in your cluster with the rendered manifests. This is identical to kubectl apply --overwrite.
In most cases, your templates don't specify a cluster IP, which means that helm upgrade --force is asking to remove (or change) the service's cluster IP. This is an illegal operation from Kubernetes' point of view.
This is also documented in #7082.
This is also why removing --force works: Helm makes a PATCH operation, diffing against the live state, merging in the cluster IP into the patched manifest, preserving the cluster IP over the upgrade.
If you want to forcefully remove and re-create the object like what was done in Helm 2, have a look at #7431.
Hope this clarifies things.
Moving forward, let's try to focus on OP's issue here.

Are there any known workarounds? Faced the same issue when trying to upgrade https://github.com/helm/charts/tree/master/stable/rabbitmq-ha from 1.34.1 to 1.46.4. Obviously --force or helm downgrade 3.1.3 didn't help.

@EvgeniGordeev This going to be crude solution which worked for me with small downtime. Uninstall the chart/reinstall.

We've hit this as well with the nginxinc ingress chart. We use --force generally.
Since this issue is still open, is there plans for some sort of fix to address this, or is this deemed working as designed (it is hard to discern from this + the other issues opened with the same behavior)? I read one explanation that this is an issue with the chart that itself and clusterIP: "" should not be used and instead the value should be completely omitted.
Is this something we should be chasing up with the chart developers?

@cdunford - the suggested fix it to stop using --force as was suggested https://github.com/helm/helm/issues/7956#issuecomment-643432099.
This PR could also address the issue: #7431 (aso suggested in that comment)...

We hit this issue for the N time, we are using --force flag as well in our pipeline.

original problem came along with helm2, so will it be also fixed in helm2? @bacongobbler

@bacongobbler why do you say providing "force" is different from the issue if stripping it OR downgrading helps?
I mean, I've just hit the issue with Helm 3.3.4, https://artifacthub.io/packages/helm/bitnami/nginx chart and no values changed. Tested on three different clouds: GCP/GKE, Azure/AKS and AWS/EKS, failed on all three.
Immediately worked after I have downgraded Helm to 3.1.3 AND also worked on 3.3.4 without "--force" flag.

I thought I made it fairly clear in my earlier comment that there are two separate, unique cases where a user can see this error. One is OP’s case. The other is from the use of —force. We are focusing on OP’s issue here.
Out of respect for the people who are experiencing the same issue as the OP, please stop hijacking this thread to talk about —force. We are trying to discuss how to resolve OP’s issue. If you want to talk about topics that are irrelevant to the issue that the OP described, please either open a new ticket or have a look at the suggestions I made earlier.
@tibetaam with regards to fixing this for Helm 2: no. We are no longer providing bug fixes for Helm 2. See https://helm.sh/blog/helm-v2-deprecation-timeline/ for more info.

I think I managed to reproduce OP's problem with the jupytherhub helm chart.
Hopefully, with the instructions below, you will manage to reproduce the issue:

Important
Jupyterhub helm chart does not contain a spec.clusterIP field in its Service specifications, as you can see (for example) here: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fdcc2f623a14aca/jupyterhub/templates/hub/service.yaml#L17-L29

I am using helm and kind to reproduce the problem:
➜ helm version
version.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"clean", GoVersion:"go1.14.10"}

➜ kind version
kind v0.9.0 go1.15.2 linux/amd64

➜ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.1", GitCommit:"206bcadf021e76c27513500ca24182692aabd17e", GitTreeState:"clean", BuildDate:"2020-09-14T07:30:52Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

How to reproduce

Create new kind cluster

kind create cluster

Create a file called config.yaml with following content (random generated hex):

proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

FYI I am following the instructions for helm file installation (link)

Add helm repository

helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/
helm repo update

Install the chart (with --force option)

RELEASE=jhub
NAMESPACE=jhub

helm upgrade --cleanup-on-fail --force \
  --install $RELEASE jupyterhub/jupyterhub \
  --namespace $NAMESPACE \
  --create-namespace \
  --version=0.9.0 \
  --values config.yaml

Repeat step 5

Error:
Error: UPGRADE FAILED: failed to replace object: PersistentVolumeClaim "hub-db-dir" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests for bound claims
  core.PersistentVolumeClaimSpec{
        AccessModes:      []core.PersistentVolumeAccessMode{"ReadWriteOnce"},
        Selector:         nil,
        Resources:        core.ResourceRequirements{Requests: core.ResourceList{s"storage": {i: resource.int64Amount{value:<PHONE_NUMBER>}, s: "1Gi", Format: "BinarySI"}}},
-       VolumeName:       "",
+       VolumeName:       "pvc-c614de5c-4749-4755-bd3a-6e603605c44e",
-       StorageClassName: nil,
+       StorageClassName: &"standard",
        VolumeMode:       &"Filesystem",
        DataSource:       nil,
  }
 && failed to replace object: Service "hub" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "proxy-api" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "proxy-public" is invalid: spec.clusterIP: Invalid value: "": field is immutable

I'm in helm 3.3.4 and this is still an issue

Helm 2.14.1 issue present either w/w-out --force

Workaround: switch to type.spec: NodePort fixed my helmchart upgrade.

We have the same problem on v3.4.1 with --force flag.

@bacongobbler I know you have been trying vigilantly to keep on the OP's problem (separate from  #6378) from being hijacked. I thought it might help those posting to review their error message to know if this thread is for them or not:
Is your error message "Error: UPGRADE FAILED: failed to replace..." and you did use --force in your command? GOTO #6378
Is your error message "Error: UPGRADE FAILED: cannot patch..." and you did not use --force in your command? Please post in this issue how you reproduced it.

@zpittmansf
helm3 upgrade concourse concourse/concourse -f temp.yaml  --force
Error: UPGRADE FAILED: failed to replace object: Service "concourse-web" is invalid: spec.clusterIP: Invalid value: "None": field is immutable && failed to replace object: Service "concourse-web-prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "concourse-web-worker-gateway" is invalid: spec.clusterIP: Invalid value: "": field is immutable

helm3 upgrade concourse concourse/concourse -f temp.yaml
Error: UPGRADE FAILED: cannot patch "concourse-web" with kind Service: Service "concourse-web" is invalid: spec.clusterIP: Invalid value: "None": field is immutable

I'm having the same issue on Helm 3.4.2. I run a helm-chart that creates a deployment, serviceaccount, and service. I add a label to my chart on the deployment, and now it refuses to upgrade:
helm upgrade test-whale charts/app-template/ --install --values values.yaml --namespace whale --force
Error: UPGRADE FAILED: failed to replace object: Service "test-whale" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Deployment.apps "test-whale-canary" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"test-whale", "app-id":"302040", "environment":"test", "version":"latest"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && failed to replace object: Deployment.apps "test-whale" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"test-whale", "app-id":"302040", "environment":"test", "version":"latest"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

It sound terrible, but could Helm implement a list of "immutable fields" which would receive special treatment?
In this case, an "immutable field" would be the Service object's spec.clusterIP - Helm would consider it immutable and generate such an API request which would both a) not try to replace it, b) not try to remove it, c) not try to update it.
In practice, Helm would look for the current value of an immutable field an include that value in the API request's payload. As a result, the k8s API server would see Helm's request as "ok, they are not trying to modify this field".
Current situation is that Helm is very unreliable with especially Service resources.

@jbilliau-rcd
try not using --force

I ended up figuring it out; apparently you can change labels on a Deployment and on the pod spec, but NOT on the match selector......Kubernetes does not like that. Which is strange to me; how else am I supposed to modify my deployment to only select pods on version "v2" during, say, a canary deployment? Currently, I have no way of doing that, so im confused on that part.

Upgrade to helm version 3.5.0 solved the issue.

Upgrade to helm version 3.5.0 solved the issue.

Upgrade to helm version 3.5.0 solved the issue.

how exactly?

Upgrade to helm version 3.5.0 solved the issue.

how exactly?

Upgrade to helm version 3.5.0 solved the issue.

Helm version 3.5.0 still not work.
But without --force is worked.

Upgrade to helm version 3.5.0 solved the issue.

Helm version 3.5.0 still not work.
But without --force is worked.

Hit this in helm 3.5.2

I tried to remove --force but still getting the same issue.
Upgrade "gateway" failed: failed to replace object: Service "ingress"
    is invalid: spec.clusterIPs[0]: Invalid value: []string(nil): primary clusterIP
    can not be unset

So far found a reasonable workaround - --reuse-values flag. Works for my case.

3.5.2 still got this issue, with/without --reuse-values

3.5.3 has this as well :/

Same behavior in 3.5.4.  Had to just not use Helm for the Service to get around this, which is not optimal.  Use/not-use --force or --reuse-values had no change.

Same behavior in v3.5.3. --reuse-values has no effect but remove --force seems to work.

Present in v3.6.0 too.

https://github.com/helm/helm/issues/7956#issuecomment-620603863
see https://github.com/helm/helm/issues/6378#issuecomment-850530229 for the followup conversation. Thanks.

In 3.4.2, commenting
both force_update  = true & reuse_values  = true in helm_release  solves the issue

also after an upgrade from helm2
in 3.6.3 remove --force worked


Longer Session times for WebUI?

I really often ran into situations where I do a lengthy process with the WebUI ... for exmaple installing an App. And it never shows me a success that it installed. Then I reload the page and and it asks me for my passwordA again.
So it seems that my session times out but the WebUI does not recognize it while background webevents fail.
As a quick fix I would suggest to just make the session stay valid much longer valid. Outdated session should just be a fallback in case the user forgets to logout .. so have them valid for a day even is fine with me.
@fusion44 what is our session default length at the moment?

Working on it.

I'm not convinced that this is an API problem. I've checked the token by logging in to the webui and extracting the token from the cookie. I've used the token to login to the Swagger UI and the token was valid until it was supposed to expire. Two minutes in my test case. No matter how long I set the expiry time, the webui always logs out on F5. Also, the webui seems to query the refresh-token endpoint many times a second.
The only reason I currently could see is that I set the cookie not well in when returning the response with the token. I did not set the cookie when calling refresh-token, but this should be fixed now.
@cstenglein Can you check?
Anyway, the expiry time is in seconds and not milliseconds anymore. In reality this should make no difference though.

The token will be refreshed 10minutes before expiry.

Reloading the webui with F5 wasn't working and will be fixed with https://github.com/raspiblitz/raspiblitz-web/pull/758

I'll close this as it is not an API bug. Feel free to reopen.


Retry / improve unstable tests

fixes #3499, fixes #3464, fixes #3343, fixes #3342
related #3270

Codecov Report

Merging #3524 into master will decrease coverage by <1%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #3524    +/-   ##
=======================================
- Coverage      80%     80%   -<1%
=======================================
  Files         361     361
  Lines       28702   28702
  Branches     3831    3831
=======================================
- Hits        22980   22964    -16
+ Misses       4618    4616     -2
- Partials     1104    1122    +18


What fields should my JWT define?

First:
I have an authentication server that generates JWTs, and I would like to use it for authentication in StargateAPI. I couldn't find an explicit outline of fields that the JWT needs to store in the docs. What are these fields?
Second:
I am interested in implementing row-based permission for modification, and I would like to avoid creating roles in CQLSH, and do it purely over JWTs. The logical operation is simple: if the owner ID (table column) is not identical to the user ID (on the JWT) the client has no modication rights, but can still read the row. I believe at least some devs to be interested in this topic, it should be mentioned.
The authentication documentation should focus on defining/outlining more key concepts, including these.

It sounds like you might want to implement a custom AuthenticationService (authn) and AuthorizationService (authz).
The token-based auth. service is very simple and can be used as a skeleton for getting started creating a JWT version: https://github.com/stargate/stargate/tree/v1.0.50/auth-table-based-service/src/main/java/io/stargate/auth/table
The JWT could contain whatever you need to handle authn/authz.

Really? I want to avoid customizing the code... The dream was to just use the K8ssandra helm chars. Nothing I can do through the manifest?

@caniko have you taken a look at the JWT docs here?
https://stargate.io/docs/stargate/1.0/developers-guide/authnz.html#_jwt_based_authenticationauthorization
Your JWT should contain a stargate_claims claim and in that a field of x-stargate-role which matches the role in the DB. Here's where all that is handled
https://github.com/stargate/stargate/blob/234becf8db63acb9d680828ea22ed57524b861f8/auth-jwt-service/src/main/java/io/stargate/auth/jwt/AuthnJwtService.java#L39
For row level access control you'll want to create another field inside the stargate_claims with x-stargate-COLUMN_NAME where COLUMN_NAME is the name of the column that you want to use for controlling access. The logic for that is in
https://github.com/stargate/stargate/blob/234becf8db63acb9d680828ea22ed57524b861f8/auth-jwt-service/src/main/java/io/stargate/auth/jwt/AuthzJwtService.java#L83
So, as is, the JWT based auth will perform authn without needing cqlsh but if you want to do full authz then you'll need to modify AuthzJwtService. I also believe you'll need to set -D stargate.cql_use_transitional_auth=true so the persistence module doesn't perform authz and instead trusts it's been done farther up the stack (I haven't looked at that particular functionality in awhile so you'll want to double check).

Thank you @dougwettlaufer. I have a few more questions:

Could you expand on x-stargate-role? Can this role be the admin role? As mentioned earlier read-access on all, but only modify access if the column value matches its counter part in the JWT.
How do I pass in the public key of my JWT to Stargate?

Could you expand on x-stargate-role? Can this role be the admin role? As mentioned earlier read-access on all, but only modify access if the column value matches its counter part in the JWT. I want to avoid making roles for every user.

The x-stargate-role is the role you've created via cqlsh. So if you've created web-user and web-user-admin roles then in your IDP you'll map which users get which role set in the x-stargate-role claim.

How do I pass in the public key of my JWT to Stargate for it to be decrypted?

You'll pass the URL of the "well-known" endpoint to stargate with -Dstargate.auth.jwt_provider_url

The x-stargate-role is the role you've created via cqlsh. So if you've created web-user and web-user-admin roles then in your IDP you'll map which users get which role set in the x-stargate-role claim.

This makes sense, thank you.

You'll pass the URL of the "well-known" endpoint to stargate with -Dstargate.auth.jwt_provider_url

Using JWKS is OK. However, I was hoping to have the option to decrypt the JWT on Stargate by passing the decrypt key from an opaque secret.

For row level access control you'll want to create another field inside the stargate_claims with x-stargate-COLUMN_NAME where COLUMN_NAME is the name of the column that you want to use for controlling access.

@dougwettlaufer I am a little

@dougwettlaufer, could you confirm if the example below is correct?
Read scenario
The JWT has no stargate_claims, and since -D stargate.cql_use_transitional_auth=true, Stargate does indeed return the requested rows.
Modify scenario
The JWT has stargate_claims:
{
  `x-stargate-COLUMN_NAME`: <correct value>
  `x-stargate-role`: `cqlsh role`
}

Stargate does the carriest out the modification requested by the client.

@caniko that should be correct. Although you can probably leave off stargate.cql_use_transitional_auth

Lastly, which of the key-value pairs returned from the JWKS endpoint is used by Stargate?
JWKS:
{
    "keys": [
        {
            "kid": "vdaec4Br3ZnRFtZN-pimK9v1eGd3gL2MHu8rQ6M5SiE",
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "n": "4OPCc_LDhU6ADQj7cEgRei4VUf4PZH8GYsxsR6RSdeKmDvZ48hCSEFiEgfc3FIfh-gC4r9PtKucc_nkRofrAKR4qL8KNNoSuzQAOC92Yz6r7Ao4HppHJ8-QVdo5H-d9wfNSlDLBSo5My4b4EnHb1HLuFxDqyhFpGvsoUJdgbt3m_Q3WAVb2yrM83S6HX__vrQvqUk2e7z5RNrI7LSsW3ZOz9fU7pvm8-kFFAIPJ7fOJIC7UQ9wBWg3YdwQ0B2b24jXjVr0QCGzqJ6o1G_UZYSJCDMGQDpDcEuYnvSKBLfVR-0EcAjolRhcSPjHlW0Cp0YU8qwWDHpjkbrMrFmxlO4Q",
            "e": "AQAB"
        }
    ]
}

kid means key id, alg is the algorithm, and n is the public key used for this realm. Example copied from redhat article for keycloak.
Definitely alg and n. Any of the other ones?
And, how does Stargate know which kid to use for the JWT? Is the kid in the JWT?

@caniko - Did you ever get further with this project? Is there anything that you believe should be documented from your experience with JWT?

@polandll I am currently blocked by this om the k8ssandra side for proper testing.
Please answer the questions from my last post in the meantime.

@dougwettlaufer additional to my previous question: What if correct value has no match in the COLUMN?
{
  `x-stargate-COLUMN_NAME`: <correct value>
  `x-stargate-role`: `cqlsh role`
}


UI on freecodecamp.org, Potential Confusion Area

Issue Description
This is more of a comment on the UI of the freecodecamp.org site.  Clicking on the big freeCodeCamp logo in the top left corner of the page initiates different challenges for the user to try out.  This may become very confusing for a brand new visitor just trying to explore the site, especially if they have absolutely no background in coding.  Perhaps these challenges can be inside a new "Challenges" tab?  It may become confusing if someone is just trying to return to the home page only to keep seeing new challenges.
Browser Information

Browser Name, Version:  Chrome, Version 66.0.3359.181
Operating System: Windows
Mobile, Desktop, or Tablet: Desktop

Yes, we are overhauling this experience with the new platform. Try out https://beta.freecodecamp.org


Regex and case sensitivity

It seems that the Regex are case sensitive. If this is an intentional choice, perhaps consider adding a warning? Many "typical" users may not be aware of this, as many interfaces do not differentiate based on case. Even "advanced" users might run into issues if they don't immediately realize it (definitely not speaking from experience…).

Yes it was inconsistant. It is fixed. Since it is "real" regex, for the moment I keep case sensitivity. I add this point in the doc. but it can be discussed in the future (@eollion)


docs: updated admin project deletion instructions

removed section concerning project identifier confirmation input and renamed reason input to optional comment
CU-dh1105

Task linked: CU-dh1105 Reduce number of actions for project deletion confirmation


Error on webpack example

I'm submitting a ...
[X] bug report
[ ] feature request
[ ] question about the decisions made in the repository

Do you want to request a feature or report a bug?
Webpack demo link error.

What is the current behavior?
Open a empty page.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar.
Click on this link -> . https://angular-dxqjhj.stackblitz.io/ on readme.md.

What is the expected behavior?
Open a clear example.

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

Browser: Chrome

Could you share the error? For me, a page opens, it just doesn't finish loading (see also ticket #260).

This could be a duplicate of ticket #228.


--dynamic does not work for the latest released image

and I think it's because you did not ship the latest code:
/etc/traceroute-exporter # cat bin/helper_functions.py
# (c)2022, Karneliuk.com
# Modules
from argparse import ArgumentParser
import re
import os
from prometheus_client import start_http_server, Gauge
import time

# Functions
def get_instructions():
    parser = ArgumentParser()

    parser.add_argument(
        "-d", "--dev",
        action="store_true",
        default=False,
        help="Test execution with predefined test data.",
    )

    parser.add_argument(
        "-i", "--interval",
        type=int,
        default=60,
        required=False,
        help="Time interval between consequent measurements.",
    )

As you can see, the code for that option does not exist.

Hello @Trolldemorted ,
Thanks for your message. Could you please advise, how did you download the image? Did you download using no tag (or using latest tag) or as provided in example ghcr.io/akarneliuk/traceroute-exporter:${PLATFORM} ?
Best,
Anton

I just used image: ghcr.io/akarneliuk/traceroute-exporter, is that an older image?

Yes, it was. We've just deleted it. Please, download as provided in the example. The reason we have created it in this way is that there are different images for x86_64 and for arm32v7 (Raspberry PI). So the tag allows you to download the image depending on your platform. Take a look here, please: https://github.com/akarneliuk/prometheus-traceroute-exporter/pkgs/container/traceroute-exporter

Hey @Trolldemorted ,
please, reopen the ticket if proposed method doesn't work.
Best,
Anton


Adding the gl-matrix type definitions

Adding the gl-matrix library type definitions.

gl-matrix/gl-matrix.d.ts
check list

[ ] is collect naming convention?

https://www.npmjs.com/package/gl-matrix
http://bower.io/search/?q=gl-matrix
others?

[X] has a test file? (gl-matrix/gl-matrix-tests.ts or others)
[ ] pass the Travic-CI test?

@tatchx thanks mate!

@vvakame welcome!

Hey guys, I'm not being able to use gl-matrix definitions. I can compile my code with the globals recognised, but they don't get included into the final compiled file.
If I require the dependency I want to use manually (e.g. import { vec2 } from "gl-matrix") it works, but the compiler outputs an error:
ERROR in [default] src/math/Vector2.ts:1:21
Cannot find module 'gl-matrix'.

Am I missing something?

If I just include the reference (///<reference path="...">), the error that I get is that the global instance is not defined:
Vector2.ts:10Uncaught ReferenceError: vec2 is not defined

Any thoughts? Is it working for you guys? @tatx @vvakame


Update students

Name and url added

Your repo link should point to repository, where first task is already done.


only errors (visual studio)

https://prnt.sc/vp119f
last week I was able to compile everything but nothing works since yesterday!
im using visual studio community 2019

can you take a screenshot of the whole screen and solution properties?

https://prnt.sc/vpalrz
https://prnt.sc/vpambs
https://prnt.sc/vpamrc
https://prnt.sc/vpanit

Maybe it has something to do with the name of a variable called module which confuses visual studio as it's also a keyword
https://github.com/danielkrupinski/Osiris/commit/d7372133b93b13a3b58609a2c4b7e3103e00b54c

https://prnt.sc/vpalrz

Why the hell are you adding junkcode to the project? Stop wasting your time with this, if you want to differentiate your build from the original, add some features from the "Pull Requests" tab, which will not fail to be detected with Osiris.
Instead of adding dead code that is useless, add a few more things so you can have better fun!


Api Docs Consumer.commit

In readme you describe Consumer.commit:
Consumer.commit(cb)

But in Consumer.js commit needs two params:
function autoCommit(force, cb) { ... }

Consumer.prototype.commit = Consumer.prototype.autoCommit = autoCommit;

Doesn't that commit to zookeeper or kafka?


Add Latin American Spanish localization

Latin American Spanish language

I really hate to ask this but, how significantly different is this from the existing spanish translation? The problem is that we have very little resources to be maintaining multiple translations, and are already struggling to keep up with the currently active ones.

My goal in undertaking this translation was to provide a version more in line with Latin American linguistic nuances, thus improving the experience for Spanish-speaking users. Although not explicitly stated, the existing Spanish translation reflects that of Spain.
The current Spanish translation presents some contextual issues, which prompted me to address them and align the language more closely with a "Latin American" style. Here are some examples with terms widely used in the file:
Feed ---> muro (I'm not from Spain but apparently "feed" is "noticias", "news").
Un-mute list ---> "quitar silencio" (In the existing translation, it is "Desactivar la opción de silenciar la lista" which is incorrect).
Cancel quote post ---> "Cancelar cita" (In the exiting translation, "Cancelar la publicación de un presupuesto", literally, "Cancel the publication of a budget".
The differences between Spanish in Spain and Latin America are mainly grammatical. For example, some verb conjugations, vocabulary choices and regional expressions may vary. The goal is to make the translation more linguistically consistent with the nuances of Latin American Spanish.


Update Dependencies which are insecure.

It seems like there are a number of vulnerabilities that are addressed in some of the automated PRs.
I depend on this library for importing & would prefer not to fork.
Thanks

These are the dependencies with vulnerabilities, and their usage:
set-value
Prototype Pollution
https://npmjs.com/advisories/1012
sphere-stock-import>sphere-node-sdk>sphere-node-utils>load-module-pkg>expand-pkg>normalize-pkg>map-schema>set-value
set-value
Prototype Pollution
https://npmjs.com/advisories/1012
sphere-stock-import>sphere-node-utils>load-module-pkg>expand-pkg>normalize-pkg>map-schema>set-value
set-value
Prototype Pollution
https://npmjs.com/advisories/1012
sphere-stock-import>sphere-node-sdk>sphere-node-utils>load-module-pkg>expand-pkg>normalize-pkg>map-schema>union-value>set-value
set-value
Prototype Pollution
https://npmjs.com/advisories/1012
sphere-stock-import>sphere-node-utils>load-module-pkg>expand-pkg>normalize-pkg>map-schema>union-value>set-value
csv-parse
Regular Expression Denial of Service
https://npmjs.com/advisories/1171
sphere-stock-import>csv>csv-parse
csv-parse
Regular Expression Denial of Service
https://npmjs.com/advisories/1171
sphere-stock-import>sphere-node-sdk>sphere-node-utils>csv>csv-parse
csv-parse
Regular Expression Denial of Service
https://npmjs.com/advisories/1171
sphere-stock-import>sphere-node-utils>csv>csv-parse
defaults-deep
Prototype Pollution
https://npmjs.com/advisories/778
sphere-stock-import>sphere-node-sdk>sphere-node-utils>load-module-pkg>expand-pkg>defaults-deep
defaults-deep
Prototype Pollution
https://npmjs.com/advisories/778
sphere-stock-import>sphere-node-utils>load-module-pkg>expand-pkg>defaults-deep

Most of these have been fixed now. Please install latest, v3.0.1. Only CSV package left which unfortunately would need more work as it has breaking changes.

Remove github vulneribility warnings
current direct dependencies has some github vulnerability because of the Transitive dependencies. So we need to update below packages.
lodash update to 4.17.12
kind-of update to 6.0.3
minimist to 0.2.1
csv-parse to 4.4.6

Cannot update csv-parse as it is transitive dependency of csv and we are using 1.2.0 and the latest is 4+ . So it may breaking things.


Datatables npm #73

did you get this error as well?
Uncaught TypeError: Cannot use 'in' operator to search for 'length' in
this occurs on datatable initialization (tested in chrome/firefox, and private mode)

I had this error with previous datatables version, but I think it was fixed in 10.7 https://github.com/DataTables/DataTables/issues/546

fyi: I'm a bit pre-occupied with holiday atm, but will take a look in 4 weeks ;)

Ah, I found the issue. There is an incompatability with this datatables version with jquery 1.11.0. Could you update the jquery version in your pull request to 1.11.3?

I've merged it an upped the jquery version. Thanks for the PR


Documentation: add development guide

Description
This adds a development guide with three entries:

Repository Structure
Component Structure
Managing State

There are more guides to be written but this is a decent start.
Still to come (in a separate PR):

Fetching Data
Component Performance
Writing Unit Tests
Mocking Data
Using the Local Dev Tools
Writing a Feature Flag
Installing and Updating Dependencies

Thanks for the cleanup, @tiffwong! Addressed your comments.


[Toggl Track] Toggle seconds in menubar

Extension
https://www.raycast.com/franzwilhelm/toggl-track
Description
Option not to display seconds in Toggl Track menubar.
(Also, if possible: option to omit pipe symbol between data items; option not to use colour for icon / omit icon entirely.)
Who will benefit from this feature?
People who find seconds unnecessary/distracting.
People who are bothered by the timer showing seconds but only updating every c10 seconds :)
Anything else?
Thank you very much indeed for this extension, which has made a huge improvement to my workflow.

Hi! Do you mean hiding seconds in the menubar extended state? The timer in Menubar is optional, you can toggle it in settings.

Hi – thanks so much for the incredibly swift response.
I mean the menubar in the extended state. I'd love to see the time of the running timer, but seconds feels like overkill/distracting and weird as they don't update every second anyway :)
I realise this is nitpicky for the product of someone's generous free labour, but it's such a fantastic extension that I can't help myself.

@lukebars
It'd probably be best to hide the seconds by default.

I agree @bkeys818. I'll try to raise a PR for that.


Threads

Hey there, does wasi have support for threads at the moment? Looking at current experimental wasi target for rust, look like no but this might just be a limitation of an experimental target.
Thanks!

That's right, the WASI libc does not support threads at the moment.

@sunfishcode is there support planned or it will be one of the "modules" for the spec mentioned in the article?

There are really two levels of thread support. One is whether you can write a library that can be used within an application that uses threads, and the other is whether you can write a full multithreaded application.
For the library use case, WASI itself doesn't need to add anything, as the needed features -- atomics, wait, notify, are all provided by the core WebAssembly platform. WASI libc will need to be made threading-aware, but that should be straightforward.
(There are some extra features, such as the ability to have poll_oneoff be able to wait for a wasm notify, which could be added, which would need extra WASI support, but they're not needed for basic threading support.)
For full applications, you'll need the ability to create and join threads. In the WebAssembly threads proposal, these are left to the embedder. So, one possible way forward here is for WASI to add thread create and join functions to support this. We're still working out what the right granularity should be for API modules, but offhand, putting these in their own API module doesn't seem unreasonable.

I'm curious about the status of threads for WASI as well. Is there a timeline? How do I find out more about the process? I'm new sorry if this is documented elsewhere.

See https://github.com/WebAssembly/WASI/issues/296#issuecomment-659223938 and the following comments. The basic situation is, wasm threads were designed to be built on Web Workers, which requires they create one instance per thread. People generally agree that for non-Web wasm (and possibly also Web wasm), we want a "native" threads feature, which would allow us to have one instance that has multiple threads, but at the moment no one has volunteered to champion that at the core wasm spec level.
Some people have asked about whether we could create minimal <pthread.h> compatibility which doesn't create new threads but allows programs using it to compile. That's doable, and needs someone to volunteer to do it.
Some people have asked about whether WASI could define an API that works with Worker-style threads as a temporary measure. That's also doable, though that would also depend on someone volunteering to do the work of designing and implementing it, and also of helping with the transition to "native" threads once they become available, because they probably won't be compatible, and transitions take work.

@sunfishcode I am intersted on llvm-libc based wasi-sdk, is that a possible idea?

It's my understanding that LLVM libc is very incomplete at this time, however it probably is possible. To be sure, that wouldn't change anything with respect to https://github.com/WebAssembly/WASI/issues/296#issuecomment-659223938, or Worker-style threads. To support threads, one would need to do the same work regardless of which libc is used.


Autocorrect mistakes in postcodes entered into local transaction pages

We were seeing lots of errors for postcodes entered
with obvious typos, eg. hyphens instead of spaces, 0 instead of O, I
instead of 1, etc, so this is an attempt at fixing most common ones.
Strip most non-alphanumerics and trailing whitespace. Also use the
uk_postcode gem to fix transposition of I/1, O/0.
The routes.rb file had a constraint on the areas/postcode route,
but this change failed to work with it, so I've removed it in favour
of a better regex in the controller.

Trello: https://trello.com/c/2KHTEa4l/127-auto-correct-mistakes-in-postcodes-entered-by-users-on-local-transaction-pages.
(Thanks to @h-lame for help with understanding the tests.)

I'm not sure this is doing what I think it's doing end-to-end via the local transaction pages. Closing while I work it out. :confused:

Reopening in favour of a separate approach between this and https://github.com/alphagov/frontend/pull/893, as per the conversation on https://github.com/alphagov/gds-api-adapters/pull/384 in which my point about doing it centrally was invalidated.

(Copied @alext's comment over from the gds-api-adapters PR.)

I'm not sure why we would need this in Imminence. It doesn't seem correct for an API to be doing this > autocorrection. IMO, that should be done by the component that interacts with the end-user, not an API further down the chain.

@alext: Are you suggesting then that we do the same sanitization in all of the apps that use Imminence (https://github.com/search?utf8=✓&q=user%3Aalphagov+'gds_api%2Fimminence'&type=Code&ref=searchresults (the GitHub search is slightly weird there, but...)), rather than in Imminence itself which covers most bases, with a special case for Frontend as it talks to MapIt directly?

@alext Any more thoughts on this? Should we be doing this in each place where we use the Imminence API?

Discussing this within the team, the story I'm working on was explicitly for local transactions, not everything that uses postcodes across GOV.UK, so this is now redundant given the local transactions postcode sanitization is being done in the Frontend PR linked to above. (The Frontend PR now also sanitizes areas and Find My Nearest postcodes, but that's being filtered out over there. :-)) Even though it's slightly annoying, I'm closing this because doing this would silently correct postcodes in Business Support API, Smart Answers and Publisher, and that's not what the story had in mind (which is dealt with in Frontend, now). :disappointed:


Update PPO sentiment LLaMA script arguments

Out of curiosity, are the prompts now just the beginnings of movie reviews instead of dialogues between llama and the assistant?

Out of curiosity, are the prompts now just the beginnings of movie reviews instead of dialogues between llama and the assistant?

The movie reviews is just the example from the original trlx repo! I'll add my dialogue prompts in another script in the situational-awareness repo.


Various usability improvements

Corrects many glitches and annoyances found so far while working with early adopters. (Thanks everyone who suffered!)

Better bash completion for deepdive commands with easy instructions.
deepdive run and deepdive initdb have been added back as shorthand and backward compatibility.
deepdive redo won't lose last state if canceled.
Compiler won't complain about DDlog rules for VIEWs.
process/init/app always precedes all other processes.
No more silly oscillating progress bar, only numbers are shown.
Support for environment variables in db.url.
Please see the individual commit messages for more.

@ajratner  ping?  Can we get this reviewed asap?

Sorry! Actually had looked this over already, merging now!
On Fri, Jan 29, 2016 at 5:57 PM Jaeho Shin<EMAIL_ADDRESS>wrote:

@ajratner https://github.com/ajratner ping? Can we get this reviewed
asap?
—
Reply to this email directly or view it on GitHub
https://github.com/HazyResearch/deepdive/pull/468#issuecomment-177045613
.


Replace use of eval()

We are using CSP headers and ran into an issue using this library because of the use of unsafe eval.
https://github.com/CesiumGS/cesium/blob/2fd0e8f7e4212bd1e7084299187f70597a6bbfd8/Source/Workers/cesiumWorkerBootstrapper.js#L2285
I am wondering if there is an alternative for this?

This is in third-party code (requirejs) but after a quick look at the code, I'm pretty sure this code is never used in Cesium, so you could try commenting it out or removing it.

When I ran cesium, it did go through the line mentioned above.

I don't think this is something we plan on changing at the moment, this is just part of how RequireJS works.
I would recommend adding an exception to allow this use eval when running CesiumJS.

Is it possible that use of eval will be eliminated by https://github.com/CesiumGS/cesium/issues/9473 ?

Has there been any update on this issue? We are trying to use Cesium in our application but we are required to not include 'unsafe-eval' in our CSP. Simply having Cesium load in through webpack runs into this issue.

@alexfrigault No updates yet. We are potentially taking a look at eliminating requireJS and therefore eval as a part of some modernization efforts in the near future.

@ggetz any updates on this one? :)

@pixelschubs Not yet. I would recommend keeping an eye on https://github.com/CesiumGS/cesium/issues/9473. We'll post any updates there.

@ggetz are there any updates on this Issue?
Issue https://github.com/CesiumGS/cesium/issues/9473 is closed and I don't found any helpful things there.
I'm using the packages "@cesium/engine": "^2.2.0" and "@cesium/widgets": "^2.1.1"

Hi, the most recent blocker for replacing requireJS in our packaged web workers was that Firefox did not support ESM modules in workers. The good news is that issue was recently marked as resolved!
I'll re-open this issue to track updating our build system to remove RequireJS.


Parameters can not get actual type on function overloads

🔎 Search Terms
function overloads Parameters
🕗 Version & Regression Information
5.3.3
⏯ Playground Link
No response
💻 Code
class PDate {
makeDate(timestamp: number);
makeDate(m: number, d: number, y: number): Date;
makeDate(mOrTimestamp: number, d?: number, y?: number): Date {
if (d !== undefined && y !== undefined) {
return new Date(y, mOrTimestamp, d);
} else {
return new Date(mOrTimestamp);
}
}
}
class CDate extends PDate {
constructor() {
super();
}
// Property 'makeDate' in type 'CDate' is not assignable to the same property in base type 'PDate'.
// Type '(m: number, d: number, y: number) => Date' is not assignable to type '{ (timestamp: number): any; (m: number, d: number, y: number): Date; }'.ts(2416)
override makeDate(...args: Parameters<PDate['makeDate']>) {
return super.makeDate(...args);
}
}

🙁 Actual behavior
When I want override parant class method, I need to get this method parameters type in child class, how can i get this method parameters type?
I konw Parameters will be the parameters of the last signature, Can I get this type in another way?
🙂 Expected behavior
Parameters will be the parameters of actual function
Additional information about the issue
No response

This is a documented design limitation: https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#inferring-within-conditional-types
And this is a duplicate of many.

design limitation

I konw this is a design limitation，can I get expected type in another way？

@MartinJohns
To quote from your reference:

When inferring from a type with multiple call signatures (such as the type of an overloaded function), inferences are made from the last signature (which, presumably, is the most permissive catch-all case). It is not possible to perform overload resolution based on a list of argument types.

There is some possible confusion in this description, as well as an often unmet presumption:

The description doesn't make clear whether "the last signature" is the implementation signature or the last exposed signature - if fact it means is the last exposed signature, which is logically what it must mean, because in a modules export file the implementation signature is not even included.
The often unmet presumption is that last exposed signature is "the most permissive catch-all case".  It is not error for it not to be so, as can seen in this case.  So the user reading this presumption must be forgiven for thinking that the implementation signature is the last signature being described, because the implementation signature is actually required to be "the most permissive catch-all case".

This same confusing and often unmet presumption appears verbatim in the documentation for release 2.8:
However, in this case  the error can be fixed by reversing the order of the signatures in PDate.
  makeDate(m: number, d: number, y: number): Date;
  makeDate(timestamp: number): Date; // why was the return type omitted? By default it is `any`.

@RyanCavanaugh - Could you add the issue number(s) best matching?

@RyanCavanaugh
Could I bother you to be more specific?  Search through "function overloads" I could not find anything matching the OP's particular problem with getting the overloads union of signatures when the last one is not such a union.

And this is a duplicate of many.

Could I bother you to be more specific? Search through "function overloads" I could not find anything matching the OP's particular problem with getting the overloads union of signatures when the last one is not such a union.

@zjtakato
class PDate {
  makeDate(timestamp: number);
  makeDate(m: number, d: number, y: number): Date;
  makeDate(mOrTimestamp: number, d?: number, y?: number): Date;
  makeDate(mOrTimestamp: number, d?: number, y?: number): Date {
    if (d !== undefined && y !== undefined) {
      return new Date(y, mOrTimestamp, d);
    } else if (!d) {
      return new Date(mOrTimestamp);
    }
    throw "rangeError";
  }
}
class CDate extends PDate {
  constructor() {
    super();
  }
  override makeDate(...args: Parameters<PDate['makeDate']>) {
    return super.makeDate(...args);
  }
}