Compiler options not working as expected when using project references

Issue :
Full reproduction case
Expected behavior :
I have three TS projects:

tsconfig-src.json
tsconfig-tests.json
tsconfig.json which references both of the above (using TypeScript's new "project references" feature)

When running jest, it should read compiler options from tsconfig.json.
Because tsconfig.json includes no files for itself but just references other projects, ts-jest should read its compiler options from the project reference that corresponds to any given file.
For example, tsconfig.json references the tsconfig-tests.json project:
{
  "references": [
    {
      "path": "./tsconfig-tests.json"
    }
  ]
}

In turn, tsconfig-tests.json includes all test files:
{
  "include": ["**/__tests__/**/*"]
}

Given this example, I expect any test file matching the tests TS project (tsconfig-tests.json, which includes **/__tests__/**/*) to use compiler options for that TS project.
Actual behaviour
Looking at the logs, I can see tsconfig.json is used. However, compilerOptions is read from tsconfig.json, not tsconfig-tests.json.
I have verified this:

When I add compiler options to tsconfig.json, ts-jest uses them.
When I add compiler options to tsconfig-tests.json, ts-jest does not use them.

Debug log:

log file content
# content of ts-jest.log :
{"context":{"allowJs":false,"logLevel":20,"namespace":"jest-preset","package":"ts-jest","version":"23.10.1"},"message":"creating jest presets not handling JavaScript files","sequence":1,"time":"2018-09-26T16:17:30.904Z"}
{"context":{"logLevel":20,"namespace":"Importer","package":"ts-jest","version":"23.10.1"},"message":"creating Importer singleton","sequence":2,"time":"2018-09-26T16:17:32.262Z"}
{"context":{"allowJs":false,"logLevel":20,"namespace":"jest-preset","package":"ts-jest","version":"23.10.1"},"message":"creating jest presets not handling JavaScript files","sequence":3,"time":"2018-09-26T16:17:32.268Z"}
{"context":{"actualVersion":"23.6.0","expectedVersion":">=22 <24","logLevel":20,"namespace":"versions","package":"ts-jest","version":"23.10.1"},"message":"checking version of jest: OK","sequence":4,"time":"2018-09-26T16:17:32.271Z"}
{"context":{"baseOptions":{},"logLevel":20,"namespace":"jest-transformer","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"created new transformer","sequence":5,"time":"2018-09-26T16:17:32.271Z"}
{"context":{"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/__tests__/add.ts","logLevel":20,"namespace":"jest-transformer","package":"ts-jest","transformOptions":{"instrument":false,"rootDir":"/Users/OliverJAsh/Development/temp/jest-ts-project-references"},"transformerId":1,"version":"23.10.1"},"message":"computing cache key for /Users/OliverJAsh/Development/temp/jest-ts-project-references/src/__tests__/add.ts","sequence":6,"time":"2018-09-26T16:17:32.274Z"}
{"context":{"logLevel":30,"namespace":"jest-transformer","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"no matching config-set found, creating a new one","sequence":7,"time":"2018-09-26T16:17:32.275Z"}
{"context":{"config":{"automock":false,"browser":false,"cache":true,"cacheDirectory":"/var/folders/j9/5w0fkxkx5y71q82qxpbcr_l80000gn/T/jest_dx","clearMocks":false,"coveragePathIgnorePatterns":["/node_modules/"],"cwd":"/Users/OliverJAsh/Development/temp/jest-ts-project-references","detectLeaks":false,"detectOpenHandles":false,"errorOnDeprecated":false,"filter":null,"forceCoverageMatch":[],"globals":{},"haste":{"providesModuleNodeModules":[]},"moduleDirectories":["node_modules"],"moduleFileExtensions":["js","json","jsx","node","ts","tsx"],"moduleNameMapper":{},"modulePathIgnorePatterns":[],"name":"16fd8dbb7736f57ff030f33e19558e92","prettierPath":null,"resetMocks":false,"resetModules":false,"resolver":null,"restoreMocks":false,"rootDir":"/Users/OliverJAsh/Development/temp/jest-ts-project-references","roots":["/Users/OliverJAsh/Development/temp/jest-ts-project-references"],"runner":"jest-runner","setupFiles":[],"setupTestFrameworkScriptFile":null,"skipFilter":false,"snapshotSerializers":[],"testEnvironment":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/jest-environment-node/build/index.js","testEnvironmentOptions":{},"testLocationInResults":false,"testMatch":["**/__tests__/**/*.js?(x)","**/?(*.)+(spec|test).js?(x)","**/__tests__/**/*.ts?(x)","**/?(*.)+(spec|test).ts?(x)"],"testPathIgnorePatterns":["/Users/OliverJAsh/Development/temp/jest-ts-project-references/target/"],"testRegex":"","testRunner":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/jest-jasmine2/build/index.js","testURL":"http://localhost","timers":"real","transform":[["^.+\\.tsx?$","/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/ts-jest/dist/index.js"]],"transformIgnorePatterns":["/node_modules/"],"watchPathIgnorePatterns":[]},"logLevel":20,"namespace":"backports","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"backporting config","sequence":8,"time":"2018-09-26T16:17:32.275Z"}
{"context":{"jestConfig":{"automock":false,"browser":false,"cache":true,"cacheDirectory":"/var/folders/j9/5w0fkxkx5y71q82qxpbcr_l80000gn/T/jest_dx","clearMocks":false,"coveragePathIgnorePatterns":["/node_modules/"],"cwd":"/Users/OliverJAsh/Development/temp/jest-ts-project-references","detectLeaks":false,"detectOpenHandles":false,"errorOnDeprecated":false,"filter":null,"forceCoverageMatch":[],"globals":{"ts-jest":{}},"haste":{"providesModuleNodeModules":[]},"moduleDirectories":["node_modules"],"moduleFileExtensions":["js","json","jsx","node","ts","tsx"],"moduleNameMapper":{},"modulePathIgnorePatterns":[],"name":"16fd8dbb7736f57ff030f33e19558e92","prettierPath":null,"resetMocks":false,"resetModules":false,"resolver":null,"restoreMocks":false,"rootDir":"/Users/OliverJAsh/Development/temp/jest-ts-project-references","roots":["/Users/OliverJAsh/Development/temp/jest-ts-project-references"],"runner":"jest-runner","setupFiles":[],"setupTestFrameworkScriptFile":null,"skipFilter":false,"snapshotSerializers":[],"testEnvironment":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/jest-environment-node/build/index.js","testEnvironmentOptions":{},"testLocationInResults":false,"testMatch":["**/__tests__/**/*.js?(x)","**/?(*.)+(spec|test).js?(x)","**/__tests__/**/*.ts?(x)","**/?(*.)+(spec|test).ts?(x)"],"testPathIgnorePatterns":["/Users/OliverJAsh/Development/temp/jest-ts-project-references/target/"],"testRegex":"","testRunner":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/jest-jasmine2/build/index.js","testURL":"http://localhost","timers":"real","transform":[["^.+\\.tsx?$","/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/ts-jest/dist/index.js"]],"transformIgnorePatterns":["/node_modules/"],"watchPathIgnorePatterns":[]},"logLevel":20,"namespace":"config","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"normalized jest config","sequence":9,"time":"2018-09-26T16:17:32.276Z"}
{"context":{"logLevel":20,"namespace":"config","package":"ts-jest","transformerId":1,"tsJestConfig":{"compiler":"typescript","diagnostics":{"ignoreCodes":[6059,18002,18003],"pretty":true,"throws":true},"isolatedModules":false,"transformers":[],"tsConfig":{"kind":"file"}},"version":"23.10.1"},"message":"normalized ts-jest config","sequence":10,"time":"2018-09-26T16:17:32.276Z"}
{"context":{"logLevel":20,"namespace":"config","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"babel is disabled","sequence":11,"time":"2018-09-26T16:17:32.277Z"}
{"context":{"logLevel":20,"namespace":"Importer","package":"ts-jest","version":"23.10.1"},"message":"loaded module typescript","sequence":12,"time":"2018-09-26T16:17:32.574Z"}
{"context":{"logLevel":20,"namespace":"Importer","package":"ts-jest","version":"23.10.1"},"message":"patching typescript","sequence":13,"time":"2018-09-26T16:17:32.574Z"}
{"context":{"actualVersion":"3.0.3","expectedVersion":">=2.7 <4","logLevel":20,"namespace":"versions","package":"ts-jest","version":"23.10.1"},"message":"checking version of typescript: OK","sequence":14,"time":"2018-09-26T16:17:32.575Z"}
{"context":{"logLevel":20,"namespace":"config","package":"ts-jest","transformerId":1,"tsConfigFileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/tsconfig.json","version":"23.10.1"},"message":"readTsConfig(): reading /Users/OliverJAsh/Development/temp/jest-ts-project-references/tsconfig.json","sequence":15,"time":"2018-09-26T16:17:32.575Z"}
{"context":{"logLevel":20,"namespace":"config","package":"ts-jest","transformerId":1,"tsconfig":{"input":{"compilerOptions":{},"files":[],"include":[],"references":[{"path":"./tsconfig-src.json"},{"path":"./tsconfig-tests.json"}]},"resolved":{"compileOnSave":false,"configFileSpecs":{"filesSpecs":[],"includeSpecs":[],"validatedIncludeSpecs":[],"wildcardDirectories":{}},"errors":[{"category":1,"code":18002,"messageText":"The 'files' list in config file '/Users/OliverJAsh/Development/temp/jest-ts-project-references/tsconfig.json' is empty."}],"fileNames":[],"options":{"configFilePath":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/tsconfig.json","declaration":false,"inlineSourceMap":false,"inlineSources":true,"module":1,"noEmit":false,"outDir":"$$ts-jest$$","removeComments":false,"sourceMap":true,"target":1},"projectReferences":[{"originalPath":"./tsconfig-src.json","path":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/tsconfig-src.json"},{"originalPath":"./tsconfig-tests.json","path":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/tsconfig-tests.json"}],"raw":{"compileOnSave":false,"compilerOptions":{},"files":[],"include":[],"references":[{"path":"./tsconfig-src.json"},{"path":"./tsconfig-tests.json"}]},"typeAcquisition":{"enable":false,"exclude":[],"include":[]},"wildcardDirectories":{}}},"version":"23.10.1"},"message":"normalized typescript config","sequence":16,"time":"2018-09-26T16:17:32.583Z"}
{"context":{"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":20,"namespace":"jest-transformer","package":"ts-jest","transformOptions":{"instrument":false,"rootDir":"/Users/OliverJAsh/Development/temp/jest-ts-project-references"},"transformerId":1,"version":"23.10.1"},"message":"computing cache key for /Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","sequence":17,"time":"2018-09-26T16:17:32.597Z"}
{"context":{"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":20,"namespace":"jest-transformer","package":"ts-jest","transformOptions":{"instrument":false},"transformerId":1,"version":"23.10.1"},"message":"processing /Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","sequence":18,"time":"2018-09-26T16:17:32.597Z"}
{"context":{"logLevel":20,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"creating typescript compiler (language service)","sequence":19,"time":"2018-09-26T16:17:32.598Z"}
{"context":{"cacheDirectory":"/var/folders/j9/5w0fkxkx5y71q82qxpbcr_l80000gn/T/jest_dx/ts-jest-12649e7f15d09e17a4fbf3203d8f5538cdd2552e","logLevel":20,"namespace":"config","package":"ts-jest","version":"23.10.1"},"message":"will use file caching","sequence":20,"time":"2018-09-26T16:17:32.598Z"}
{"context":{"logLevel":20,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"creating language service","sequence":21,"time":"2018-09-26T16:17:32.599Z"}
{"context":{"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":20,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readThrough(): cache miss","sequence":22,"time":"2018-09-26T16:17:32.601Z"}
{"context":{"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":20,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getOutput(): compiling using language service","sequence":23,"time":"2018-09-26T16:17:32.602Z"}
{"context":{"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":20,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"updateMemoryCache()","sequence":24,"time":"2018-09-26T16:17:32.602Z"}
{"context":{"cacheHit":true,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache hit","sequence":25,"time":"2018-09-26T16:17:32.602Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":26,"time":"2018-09-26T16:17:32.615Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":27,"time":"2018-09-26T16:17:32.617Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/add.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":28,"time":"2018-09-26T16:17:32.619Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":29,"time":"2018-09-26T16:17:32.622Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/index.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":30,"time":"2018-09-26T16:17:32.623Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/common.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":31,"time":"2018-09-26T16:17:32.627Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":32,"time":"2018-09-26T16:17:32.644Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/array.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":33,"time":"2018-09-26T16:17:32.645Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/collection.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":34,"time":"2018-09-26T16:17:32.719Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/date.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":35,"time":"2018-09-26T16:17:32.750Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/function.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":36,"time":"2018-09-26T16:17:32.751Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/lang.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":37,"time":"2018-09-26T16:17:32.796Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/math.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":38,"time":"2018-09-26T16:17:32.816Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/number.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":39,"time":"2018-09-26T16:17:32.820Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/object.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":40,"time":"2018-09-26T16:17:32.825Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/seq.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":41,"time":"2018-09-26T16:17:32.869Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/string.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":42,"time":"2018-09-26T16:17:32.872Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/common/util.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":43,"time":"2018-09-26T16:17:32.880Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":44,"time":"2018-09-26T16:17:32.913Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":45,"time":"2018-09-26T16:17:32.914Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":46,"time":"2018-09-26T16:17:32.916Z"}
{"context":{"call":null,"logLevel":10,"namespace":"ts:serviceHost","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"readFile","sequence":47,"time":"2018-09-26T16:17:32.917Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/jest/index.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":48,"time":"2018-09-26T16:17:32.919Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/typescript/lib/lib.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":49,"time":"2018-09-26T16:17:32.936Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/typescript/lib/lib.es5.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":50,"time":"2018-09-26T16:17:32.937Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/typescript/lib/lib.dom.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":51,"time":"2018-09-26T16:17:32.982Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/typescript/lib/lib.webworker.importscripts.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":52,"time":"2018-09-26T16:17:33.139Z"}
{"context":{"cacheHit":false,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/typescript/lib/lib.scripthost.d.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache miss","sequence":53,"time":"2018-09-26T16:17:33.142Z"}
{"context":{"call":null,"logLevel":20,"namespace":"ts-hoisting","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"visitSourceFileNode(): hoisting","sequence":54,"time":"2018-09-26T16:17:33.516Z"}
{"context":{"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":20,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getOutput(): computing diagnostics","sequence":55,"time":"2018-09-26T16:17:33.534Z"}
{"context":{"cacheHit":true,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache hit","sequence":56,"time":"2018-09-26T16:17:33.534Z"}
{"context":{"cacheHit":true,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache hit","sequence":57,"time":"2018-09-26T16:17:33.535Z"}
{"context":{"cacheHit":true,"fileName":"/Users/OliverJAsh/Development/temp/jest-ts-project-references/src/add.ts","logLevel":10,"namespace":"ts-compiler","package":"ts-jest","transformerId":1,"version":"23.10.1"},"message":"getScriptSnapshot(): cache hit","sequence":58,"time":"2018-09-26T16:17:33.535Z"}
{"context":{"diagnosticCodes":[1192],"diagnosticText":"\u001b[96msrc/add.ts\u001b[0m:\u001b[93m1\u001b[0m:\u001b[93m8\u001b[0m - \u001b[91merror\u001b[0m\u001b[90m TS1192: \u001b[0mModule '\"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/add\"' has no default export.\n\n\u001b[30;47m1\u001b[0m import add from 'lodash/add';\n\u001b[30;47m \u001b[0m \u001b[91m       ~~~\u001b[0m\n","logLevel":20,"namespace":"TSError","package":"ts-jest","version":"23.10.1"},"message":"created new TSError","sequence":59,"time":"2018-09-26T16:17:33.537Z"}

Minimal repo :
Full reproduction case
In the full reproduction case I have created, you will see that running tsc -b -f tsconfig.json has no problems, but running jest fails with:
 FAIL  src/__tests__/add.ts
  ● Test suite failed to run

    TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
    src/add.ts:1:8 - error TS1192: Module '"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/add"' has no default export.

    1 import add from 'lodash/add';
             ~~~

This failure suggests that the allowSyntheticDefaultImports compiler option, used in tsconfig-tests.json, is not picked up.

Fixed in 23.10.2. This was in fact related to the forced esModuleInterop which has been fixed in 23.10.2.

This was in fact related to the forced esModuleInterop which has been fixed in 23.10.2.

I believe the issue here may be wider than this.
In my testing, no compiler options are respected from the referenced TS project—not just allowSyntheticDefaultImports.
For example: https://github.com/OliverJAsh/jest-ts-project-references/blob/ac25a2d857cae3831d5aff35dd32776f1e47f4a6/src/tests/add.ts#L3

Also 23.10.2 does not fix the issue even for the allowSyntheticDefaultImports example given above. Here is the same full reproduction case but upgraded, and you will find the issue still occurs. https://github.com/OliverJAsh/jest-ts-project-references/tree/ts-jest-issue-upgrade

Actually I said it was fixed because I did clone, upgrade and then yarn test which succeeded.

Can you upgrade the minimal repo's master adding an option that makes jest fail while tsc pass?
Be sure to upgrade ts-jest (personally I git clone ..., yarn and then yarn add --dev ts-jest@latest

Arrrrrrgg wrong button, sorry!

Can you upgrade the minimal repo's master

The original repro is on the ts-jest-issue branch.

Be sure to upgrade ts-jest

The upgraded repro is on the ts-jest-issue-upgrade branch. I have checked yarn.lock and it's definitely upgraded.

makes jest fail while tsc pass

tsc does pass and jest fails, as per my original description.
Passes:
$ tsc -b -f tsconfig.json

Fails:
$ jest
 FAIL  src/__tests__/add.ts
  ● Test suite failed to run

    TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
    src/add.ts:1:8 - error TS1192: Module '"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/add"' has no default export.

    1 import add from 'lodash/add';
             ~~~

Ok I've tested on master, that might be the reason ;-)

If you have multiple projects, you should have a jest config for each of them as well, and then in the main jest.config.js you'd have a projects field with each of your jest config listed.

Why would you have, in the same project, different options between the sources and the tests files (except types)?

Separating tests from source code are one of the primary use cases for project references (see https://www.typescriptlang.org/docs/handbook/project-references.html#an-example-project).
This separation allows you to have different compiler options, which is useful for specifying different types as in my example. In addition to that, the TypeScript docs themselves specify some other good reasons to do this: https://www.typescriptlang.org/docs/handbook/project-references.html#an-example-project

Previously, this structure was rather awkward to work with if you used a single tsconfig file:

It was possible for the implementation files to import the test files
It wasn’t possible to build test and src at the same time without having src appear in the output folder name, which you probably don’t want
Changing just the internals in the implementation files required typechecking the tests again, even though this wouldn’t ever cause new errors
Changing just the tests required typechecking the implementation again, even if nothing changed
You could use multiple tsconfig files to solve some of those problems, but new ones would appear:

There’s no built-in up-to-date checking, so you end up always running tsc twice

Invoking tsc twice incurs more startup time overhead
tsc -w can’t run on multiple config files at once
Project references can solve all of these problems and more.

Project references can solve all of these problems and more.

hmmmm... makes sense ok.
I'll look deeper into what are the options here. I'll have to look in their API how they handle this, because we're using the language service so it should work out of the box.
Anyway, until this get fixed, here is how I deal with the problem they exposed:

I have a tsconfig.json which has all types, almost no exclude, and noEmit: true.
Then I have tsconfig.build.json which extends the tsconfig.json and has noEmit: false, and the correct exclude/include to just build my dist.

Any updates on this issue?
I'm not 100% sure if my issue is related, but I have a hunch it is... I've just spent best part of a day trying to get ts-jest to transpile typescript from another module within a monorepo so that coverage is correct.
I think I have jest/ts-jest configured correctly with moduleNameMapper but I get TypeError: ...: Emit skipped. I've debugged down to typescript.js and the output of .getProjectReferences() is undefined.

I have similar problem:
FAIL tests/pages/Project.tsx
Test suite failed to run
TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
tests/pages/Project.tsx:10:27 - error TS2307: Cannot find module '../../src/graphql/projectQuery.gql
import PROJECT_QUERY from "../../src/graphql/projectQuery.gql";

When I run project everything works properly but it when I try to test it fails. I use jest-transform-graphql in the test environment to transpile gql files.
transform: {
  "^.+\\.gql$": "jest-transform-graphql",
}

Any idea how to solve this problem?

Any updates or RIP?

It seems like when resolving import x from 'y', the references:[] in tsconfig is not working.
My test case is removing the built artifacts (i.e. dist or lib and *.tsbuildinfo), and then try to run jest.
The error is Cannot find module 'y'.
tsc -b is working fine.

@unional I'm having that same issue...  did you find a solution?

My solution is to not rely on the diagnostic at all.
I run tsc -b -w in one terminal and jest --watch in another.
You can check out standard-log as an example.

Also, I find that having the diagnostic in the jest actually slows me down.
there are times that I am in the process of refactoring and the type breaks.
For many times I don't care about the type breakage at that moment, I don't want to see if the code work or not.
I can always go back and fix the type.
With diagnostic turned on, I'm force to fix the type on a solution that I don't know if it is correct or not, which would be a waste of time if I will be throwing the code away anyway.

I got my mono-repo to compile on jest run without having to build files by using moduleNameMapper with typescript project references, etc.

@j how did you do it?

In my case Jest does not even tries to build the project references, it just fails with error:
 FAIL  src/foo.spec.ts
  ● Test suite failed to run

    Cannot find module 'web-modules-core' from 'foo.ts'

    However, Jest was able to find:
        './foo.spec.ts'
        './foo.ts'

    You might want to include a file extension in your import, or update your 'moduleFileExtensions', which is currently ['js', 'json', 'jsx', 'ts', 'tsx', 'node', 'ts', 'tsx'].

    See https://jestjs.io/docs/en/configuration#modulefileextensions-array-string

    > 1 | export {getConfig} from 'web-modules-core';
        | ^
      2 |

tsc -b works as expected though.

You have to use moduleNameMapper. If you are using jest projects and typescript references, then your typescript paths are based on the baseUrl, but the jest paths are based on where the jest.config is located for that project.
So if you have a tsconfig.json at the root level with "baseUrl": ".", and a jest config at /packages/example/jest.config.js, then your jest rootdir is at /packages/example and the typescript baseUrl is at /.
So instead of:
{ '^@example/prefix\\-(.*)$': '<rootDir>/packages/$1' }

Your actual path is:
{ '^@example/prefix\\-(.*)$': '<rootDir>/../$1' }

This can be calculated via:
const tsConfigPaths = require('tsconfig-paths')
const { pathsToModuleNameMapper } = require('ts-jest/utils');
const { join, dirname, relative } = require('path');

function tsPathsToJestPaths(tsConfigPath) {
  const tsConfigPathsResult = tsConfigPaths.loadConfig(tsConfigPath);
  const paths = tsConfigPathsResult.paths;
  const absolutePaths = Object.keys(paths).reduce((result, moduleName) => {
    result[moduleName] = paths[moduleName].map((path) => {
      const mappedPath = relative(dirname(tsConfigPath), join(dirname(tsConfigPath), tsConfigPathsResult.baseUrl, path))
      return `<rootDir>/${mappedPath}`;
    });
    return result;
  }, {})
  return pathsToModuleNameMapper(absolutePaths)
}

where tsConfigPath is the absolute path to your tsconfig, i.e. resolve(__dirname, "tsconfig.json")
Perhaps ts-jest can automatically do this based on globals.ts-jest.tsConfig

This is not what happened. Modules themselves are just simple Lerna links, that totally can be found by any Node script.
Jest cannot find the module because it does not have build artifacts (JS files that are referred from main of package.json).
It happens because JEST does not initiate build of upstream projects, just like I said.

In my case Jest does not even tries to build the project references, it just fails with error:
 FAIL  src/foo.spec.ts
  ● Test suite failed to run

    Cannot find module 'web-modules-core' from 'foo.ts'

    However, Jest was able to find:
        './foo.spec.ts'
        './foo.ts'

    You might want to include a file extension in your import, or update your 'moduleFileExtensions', which is currently ['js', 'json', 'jsx', 'ts', 'tsx', 'node', 'ts', 'tsx'].

    See https://jestjs.io/docs/en/configuration#modulefileextensions-array-string

    > 1 | export {getConfig} from 'web-modules-core';
        | ^
      2 |

tsc -b works as expected though.

this might be fixed by #1385, do you have an example repo for your case ?

Issue :
Full reproduction case
Expected behavior :
I have three TS projects:

tsconfig-src.json
tsconfig-tests.json
tsconfig.json which references both of the above (using TypeScript's new "project references" feature)

When running jest, it should read compiler options from tsconfig.json.
Because tsconfig.json includes no files for itself but just references other projects, ts-jest should read its compiler options from the project reference that corresponds to any given file.
For example, tsconfig.json references the tsconfig-tests.json project:
{
  "references": [
    {
      "path": "./tsconfig-tests.json"
    }
  ]
}

In turn, tsconfig-tests.json includes all test files:
{
  "include": ["**/__tests__/**/*"]
}

Given this example, I expect any test file matching the tests TS project (tsconfig-tests.json, which includes **/__tests__/**/*) to use compiler options for that TS project.
Actual behaviour
Looking at the logs, I can see tsconfig.json is used. However, compilerOptions is read from tsconfig.json, not tsconfig-tests.json.
I have verified this:

When I add compiler options to tsconfig.json, ts-jest uses them.
When I add compiler options to tsconfig-tests.json, ts-jest does not use them.

Debug log:
log file content
Minimal repo :
Full reproduction case
In the full reproduction case I have created, you will see that running tsc -b -f tsconfig.json has no problems, but running jest fails with:
 FAIL  src/__tests__/add.ts
  ● Test suite failed to run

    TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
    src/add.ts:1:8 - error TS1192: Module '"/Users/OliverJAsh/Development/temp/jest-ts-project-references/node_modules/@types/lodash/add"' has no default export.

    1 import add from 'lodash/add';
             ~~~

This failure suggests that the allowSyntheticDefaultImports compiler option, used in tsconfig-tests.json, is not picked up.

I checked out your repo and did some following steps:

Upgrade jest, @types/jest, ts-jest, typescript to the latest version
Run yarn test

and there is no error anymore. I think your issue is solved with latest dependencies

@ahnpnl Are you using the ts-jest-issue branch? Maybe I didn't make that clear enough in my original post, sorry.
https://github.com/OliverJAsh/jest-ts-project-references/tree/ts-jest-issue
I made a new branch that contains the upgrades you mentioned. The branch still fails:
https://github.com/OliverJAsh/jest-ts-project-references/tree/ts-jest-issue-upgrade

Oh right, I’m sorry. It could be that when cloning the repo to my laptop, I forgot to switch branch. I will take a look again.

read tsconfig of these references and combine everything together

That sounds more like the functionality of extends rather than references.
References is a bit more complicated, since the compiler options inside a referenced TS config should only apply to the files in the scope of that TS project.

hmm i'm not experienced with this project reference but your explanation makes some clearance for me. However, I don't know how we can tackle this. Do you have any suggested solutions ?
In general, ts-jest always has a final config which will be used for running tests. This config will affect to the outcome of tests.

the issue will be fixed by specifying the correct tsconfig for ts-jest to read. In this case, jest.config.js needs to be modified as
globals: {
    'ts-jest': {
        tsConfig: 'tsconfig-tests.json'
    },
},

This will tell ts-jest to use the correct tsconfig. Because by default without specifying tsConfig in ts-jest option, ts-jest will read root tsconfig.json.

Also possibly solved by https://github.com/microsoft/TypeScript/pull/37239

I know this is an old issue, but if anyone else is running into similar problems...
I just made this on Jest config and it worked for me:
  globals: {
    'ts-jest': {
      isolatedModules: true,
    },
  }

@alexbruno  this is not a solution, is a workaround with a drawback: you loose type checking


Correctly type useFetch based on the method

Describe the feature
Distinguishing types has been has been implemented in: https://github.com/unjs/nitro/pull/686 I'm wondering if a similar feature should be added to useFetch?
Additional information

[ ] Would you be willing to help implement this feature?
[ ] Could this feature be implemented as a module?

Final checks

[X] Read the contribution guide.
[X] Check existing discussions and issues.

Let's track in https://github.com/nuxt/nuxt/issues/15280.


failing unit tests

It seems the unit tests are currently failing.
We should check them, I'll probably provide a PR if I find a solution.
https://travis-ci.org/sindresorhus/opn/builds/68854431

Closing as it's not really feasible or any point to test it on Travis, as we can't verify if it actually worked. Manual testing is the only way, I think.


RSpec/InstanceVariable should ignore static (literal) classes

We have some specs where we're defining classes inside specs like this:
describe 'Foo' do
  class Bar
    def initialize(name)
      @name = name
    end

    def execute
      p @name
    end
  end
end

RSpec/InstanceVariable should not fire in this case.

@AlexWayfer I think you're right that RSpec/InstanceVariable is probably not the right mechanism to flag this, but it should actually still get flagged by something as written.
When you define Bar using class inside of a describe, it is not scoped to a describe. You are permanently introducing Bar into the global scope and it will be available across all specs.
See #197 for more details.
I'm assuming this is still broken for dynamic class declarations that do not pollute the global scope where accessing instance variables would be legitimate (using Class.new { ... }) so we should at least confirm and fix that.

When you define Bar using class inside of a describe, it is not scoped to a describe. You are permanently introducing Bar into the global scope and it will be available across all specs.

Yep, I know. And I don't know how to define scoped constants normally, beside ugly (and sometimes slow) stub_const. There is approaches like self::Bar = Class.new, but it doesn't work for any case (constant nested usage).

I commonly do something like
let(:bar) do
	Class.new(WhateverParentClass) do
		...
	end
end

it 'works' do
	expect(bar.new).to be_whatever
end

or within an example just using a local variable
it 'works' do
	bar =
		Class.new(WhateverParentClass) do
			...
		end

  expect(bar.new).to be_whatever
end

If you need a generated constant within a constant for some reason you can use const_set on your dynamic class, though it can be a little hairy if you're doing something complex.
let(:bar) do
	Class.new(WhateverParentClass) do
		const_set(:BAZ, 5)
	end
end

it 'works' do
	expect(bar::BAZ).to eql(5)
end

And you can still inherit from your dynamic class using:
baz = Class.new(bar)

etc.
Usually I try to think carefully about what I'm doing if any of this is necessary and make sure I haven't created a difficult to test design when I didn't need to.
Either way, I think it's generally worth remembering that a class doesn't actually have to be assigned to a constant, though if you feel you need one stub_const is probably a better bet because it gives you some kind of test isolation.
I think rubocop-rspec should definitely try to discourage the introduction of constants in test files, but the instance variable cop probably shouldn't care about instance variables inside whatever classes you define.

Since LeakyConstantDeclaration cop was added to flag constant definitions.
RSpec/InstanceVariable is completely ignorant to:
RSpec.describe do
  let(:bar) do
    Class.new do
      def initialize(name)
        @name = name
      end

      def execute
        p @name
      end
    end
  end
  it {}
end

Do you think this might be closed @dgollahon ?

This is still, technically, a false-positive because if you chose not to enable the LeakyConstantDeclaration cop (or did an inline disable for one case) then this is still flagging something in a context it wasn't meant to and you'd need to add a disable statement.
That said, this is a pretty uncommon situation and I don't know if we should direct any energy at fixing the false-positive. If you / others think we should just not worry about it I do think it's a little less important now that we're flagging the constant declaration.

May also be relevant: https://github.com/rubocop-hq/rubocop-rspec/pull/381#issuecomment-288871191
If you stub the constant, then create it (and that works as illustrated here^ I haven't tried to define a class like this in a very long time so i'm not 100% on the legitimacy of this) you'd have a false positive still.

Mixed-style will only lead to confusion especially in cases when constant stubbing and class reopening are scattered:
before do
  stub_const('Foo', Class.new)
end

context 'when Foo has some specific method defined' do
  class Foo
    def some_method
    end
  end
  # ...
end

Wouldn't it be better to use class_eval:
context 'when Foo has some specific method defined' do
  Foo.class_eval do # will also work with "sacrificial" anonymous classes
    def some_method
    end
  end
  # ...
end

In case it's not scattered, the whole class can be defined in a single place with Class.new do: https://github.com/rubocop-hq/rubocop-rspec/pull/765#issuecomment-493705348

@pirj I'm not saying one should do it the way I referenced, just that someone might (although I'm not actually sure it's leak-free in all situations...). I guess it would still be flagged by the LeakyConstantDeclaration cop though so maybe that aspect is not a big deal. Still, the instance variable cop is only meant to discourage ivars in the spec's scope but I don't know if we need to be that meticulous about detection.
I still think on style/format consistency grounds it's still a reasonable thing to have a preference on though and would probably make a good cop.

how independent our cops should be designed
Now I think I understand what you mean.

So speaking about this specific case in question, when class is defined directly in example group, LeakyConstantDeclaration is disabled, and instance vars are used, do you think it makes sense to detect scope change (like we do in DescribedClass) and ignore instance variables there? I like that, it makes total sense to me.


Update admission queryset to be admission-specific

Makes the application list not care about is_staff and is_superuser, but rather the memberships in the groups pertaining the the admission.
The code that deletes applications still uses is_staff and is_superuser, but you could copy the same logic in that part if that's important..

Looks nice, assuming tests fail since the test-user must be added to the admission.admin_group :+1:

Agree, although I have no more time to look at it for the next 8+ hrs, so I won't be able to fix that right now


JRTB-3: Implement Command pattern for telegrambot

Implement Command pattern for telegram bot.
Acceptance criteria:

/start stub command added

added #16 pull-request


[nmap] update to 7.95

Library name: nmap
New version number: 7.95
Other information that may be useful (release notes, etc...)
https://nmap.org/dist/
https://nmap.org/dist/nmap-7.95.tar.bz2
https://nmap.org/changelog.html

The patches that are currently used for this port won't apply cleanly to 7.92 but some fixes to the vcxproj files are still needed.

The nmap port has been deleted by PR https://github.com/microsoft/vcpkg/pull/41458, so this PR is no longer valid and I will close this issue.


[model] missing RL_FREE

around line 3100 (near end of LoadOBJ) there is an RL_FREE missing (commented out??), also the material counts haven't been freed
//RL_FREE(fileData);

should be
RL_FREE(fileData);
RL_FREE(matFaces);

untriangulated meshes are still causing seg faults, no idea what's happening there...

also notice diffuse colour doesn't seem to be working, works okay with my OBJ loader, so its not rlgl ... quite a puzzle!

I'll try to review LoadOBJ() more carefully when I have time...


ci: 🐝 update CI config

Description
Update GitHub Actions with spell checking workflow.
Type of change

[X] CI

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] Any dependent changes have been merged and published in downstream modules

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

Project coverage is 51.05%. Comparing base (1994f1e) to head (e0c77dd).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@           Coverage Diff           @@
##             main     #146   +/-   ##
=======================================
  Coverage   51.05%   51.05%
=======================================
  Files           9        9
  Lines         521      521
  Branches      117      117
=======================================
  Hits          266      266
  Misses        255      255

Files
Coverage Δ

src/components.h
80.95% <ø> (ø)


[DOC] add  ')'  for  the doc checkpoints.md

For Configure for per job when constructing the state backend, add ')'

@rmetzger Hi


[Feature] Update Template on Import

Checklist

[x] I tested all changes and all related features with different users (student, tutor, instructor, admin) on the test server https://artemistest.ase.in.tum.de.
[x] Server: I followed the coding and design guidelines.
[x] Server: I documented the Java code using JavaDoc style.
[x] Client: I followed the coding and design guidelines.
[x] Client: I added multiple screenshots/screencasts of my UI changes
[x] Client: I translated all the newly inserted strings into German and English

Motivation and Context

This PR adds an option to the import of programming exercises which updates the template files with the latest template of Artemis. In later iterations of this feature, this will allow instructors to enable/disable feature which were locked on import before. For this first iteration the Maven pom files found in the test, exercise, solution repositories are updated with dependencies and plugins found in the latest template. This only works for non-sequential tests for now.
Description

Implements a strategy pattern for different upgrade strategies per programming language
Implements a strategy for Java which updates the repository project object models plugins and dependencies with the ones found in the template.

Steps for Testing

Log in to Artemis
Identify a old Java programming exercise (still using JUnit4) or manipulate pom files of Java exercises yourself (add plugins, dependencies, change versions and JDK, add JUNIT
Import this exercise, and activate the Upgrade Template option
Check the pom.xml files in the Test/Solution/Template repository using 'Edit in Editor'
--> JUnit should be gone
--> Legacy dependencies org.json.json and me.xdrop.fuzzywuzzy should be gone
--> AJTS should be added
--> Plugins failsafe, surefire, compiler should have the same version and configuration as in the latest template (check the JDK version)
--> Overall, all dependencies except ones the instructor added himself should use the version of found in the template.
The tests will most likely not work out of the box after activating this option. This is expected
Also test this with a maven project type programming exercise. As they are quite new, you will have to fabricate the pom.xml files for this exercise yourself e.g. downgrade to JDK 14, introduce junit4...
Quickly create a programming exercise with SCA and another one with sequential test runs to check that this still works.

Test Coverage

Decreases. The new functionality file be covered in a follow up.
Screenshots

@kloessst we are not sure if this is an issue:
For a maven exercise I added further dependencies in the solution, template and test repo.

linkt to maven exercise: https://artemistest.ase.in.tum.de/#/course-management/294/programming-exercises/4495/code-editor/231646
After importing this maven exercise, the added dependencies were only kept in the test repo and not solution nor template:

link to imported maven exercise: https://artemistest.ase.in.tum.de/#/course-management/294/programming-exercises/4700/code-editor/232144
You wrote in the testing steps that --> Overall, all dependencies except ones the instructor added himself should use the version of found in the template.
This means that the dependencies should not be deleted at all right, or am I undressing this wrong? :D
Except this, everything worked fine. Good job 👍

@fde312 The Test repository of the source exercise contained the dependencies twice. The upgrade deletes them only once, because it assumes that the pom in question makes sense. I can add an iterative delete in a follow up if needed.


CODE OF CONDUCT file and contributing file

Hi @VedantKhairnar
I would like to contribute to this project , I found that there is no contributing.md file and code_of_conduct.md file , kindly assign me , I can make a well documented and formatted files

Pls proceed.

@VedantKhairnar  Kindly do add the Level tag  for DWOC
also and add the SWOC2021 label if this project is registed in SWOC too

Pls proceed.

Thank you @VedantKhairnar

It will depend upon your contribution. So, I'll check the files first and give labels accordingly!

It will depend upon your contribution. So, I'll check the files first and give labels accordingly!

Okay @VedantKhairnar

Hey, can i work on this

Hey, can i work on this

It will depend upon your contribution. So, I'll check the files first and give labels accordingly!

Hi @VedantKhairnar
I have worked on it now , kindly do check the links below attached , and let me know if any changes required
Kindly do add the label also
This is the CONTRIBUTION.md file
This is the CODE OF CONDUCT.md file

It will depend upon your contribution. So, I'll check the files first and give labels accordingly!

Hi @VedantKhairnar
I have worked on it now , kindly do check the links below attached , and let me know if any changes required
Kindly do add the label also
This is the CONTRIBUTION.md file
This is the CODE OF CONDUCT.md file

It will depend upon your contribution. So, I'll check the files first and give labels accordingly!

Hi @VedantKhairnar
I have worked on it now , kindly do check the links below attached , and let me know if any changes required
Kindly do add the label also
Let me know so that I can open a PR
This is the CONTRIBUTION.md file
This is the CODE OF CONDUCT.md file

@VedantKhairnar

It will depend upon your contribution. So, I'll check the files first and give labels accordingly!

Hi @VedantKhairnar
I have worked on it now , kindly do check the links below attached , and let me know if any changes required
Kindly do add the label also
Let me know so that I can open a PR
This is the CONTRIBUTION.md file
This is the CODE OF CONDUCT.md file

@VedantKhairnar

Cool! Good to go!

Cool! Good to go!

#15

#15


Explicity label arguments to remove deprecation warning in Ubuntu 20.04

Will add to this as I work through the rest of the warnings.

I added a few more fixes for the DeprecationWarnings but that spawn_async is going to be interesting. I don't even really want to start thinking about that one.

Do we want to merge this as-is? Or are we going to mandate a spawn_async fix?

I'm ok merging as is, especially since we don't have it set to close the parent issue. I can't review since I own the PR though, so if you, @Advill, or @nuttercd want to do the honors, please do.

Looks like we've got enough approvals. I'll go ahead and merge. Thanks, all!


npm install on alpine is wrong

Hi
i am using this plugin on 2 instances of linux.
I have seen following error on 1 of the instance newly added to the system:
Task ':OlisWebGUI:npm_install' is not up-to-date because:
Task has not declared any outputs despite executing actions.
Starting process 'command '/home/jenkins/slave/workspace/test/workspace/OlisWeb/OlisWebGUI/.gradle/nodejs/node-v12.13.1-linux-x64/bin/npm''. Working directory: /home/jenkins/slave/workspace/test/workspace/OlisWeb/OlisWebGUI Command: /home/jenkins/slave/workspace/test/workspace/OlisWeb/OlisWebGUI/.gradle/nodejs/node-v12.13.1-linux-x64/bin/npm install
Successfully started process 'command '/home/jenkins/slave/workspace/test/workspace/OlisWeb/OlisWebGUI/.gradle/nodejs/node-v12.13.1-linux-x64/bin/npm''
env: can't execute 'node': No such file or directory
:OlisWebGUI:npm_install (Thread[Execution worker for ':' Thread 5,5,main]) completed. Took 0.066 secs.
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':OlisWebGUI:npm_install'.

Process 'command '/home/jenkins/slave/workspace/test/workspace/OlisWeb/OlisWebGUI/.gradle/nodejs/node-v12.13.1-linux-x64/bin/npm'' finished with non-zero exit value 127

after long debugging, i have found out, the linux i am using where this is failing is alpine, and it looks like, node original distro requires libc, but alpine uses musl
analyzing the official docker image from node:alpine it looks like, there is an unofficial distro for alpine linux.
would it be possible to fix the plugin, so it would detect alpine linux and download the proper distro from node/npm ?
Thanks,
kappelmi

pls also have a look in this file:
https://github.com/nodejs/docker-node/blob/c6bc44e84afcdb81d9749b7b034c60e916a519ad/10/alpine3.10/Dockerfile

@kappelmi I'm experiencing the same issue on alpine, have you found a solution for this?

It's because alpine uses musl and there's no official nodejs for musl.
There's some more info in the fork at https://github.com/node-gradle/gradle-node-plugin/issues/51


chore(maven) factorize metadata into a mavenmetadata package + apply code conventions for plugin

This PR is a refactor of the maven plugin to allow continuing the work in #412.
No functionnal changes (hence the chore) label.
It introduces the following changes:

Update the maven example + add it to the end 2 end testing framework
Moved the mavenmetadata logic into its own package + use it on both maven and jenkins to decouple

Include unit test with HTTP mocking (reusing the work from #453)

Apply code conventions for the plugin maven (exports a Spec object and a New(spec) constructor method

Test
To test this pull request, you can run the following commands:
go build -o ./dist/updatecli && ./dist/updatecli diff --config examples/updatecli.generic/maven.yaml
make test-e2e

Additional Information
Jenkins plugin is the next to be refactored. Almost there \o/

PR ready with your last feedbacks (and blocking #482).

Thanks for the review @lemeurherve !
PR rebased with your proposal

Since this PR is labelled as chore (e.g. no functionnal change), and that it has been reviewed with only minor elements, I'll put it as auto-merge with squash.
Thanks folks!


Page not found when navigate from Microsoft blogs

URL: https://blogs.msdn.microsoft.com/vsappcenter/mobile_cicd_101/
When clicked on the link: docs.microsoft.com/en-us/appcenter/build/custom/variables, the extra dot make it 404

@truongkhanhduy95 Thanks. I'll have someone take a look.


Custom highlighter/marker

Hello
I need to create a linechart with specific design.

I was able to fix the design for the axis, etc but I'm having trouble on how to achieve the custom highlighter/marker.
Requirements

the highlighted value should have a circle on the value
the highlighted value should have a line from the value to the bottom
when changing the highlighted value, the top half of the highlighter should have a dashed line + a marker on the top of the view indicating it's value.

Any help is welcome!
Kind regards

refer

public protocol IMarker: NSObjectProtocol

Write your own marker. You can take a look at how BalloonMarker is implemented. For the dashed line, one option is override drawHighlightLines() only enable the vertical highlight line and make it dashed.

@VanHoutte Did you make the tooltip successfully?

@VanHoutte did you archive this design?
https://user-images.githubusercontent.com/9484483/28835400-7b483378-76e5-11e7-9d6b-ded7a5df0a07.png

@VanHoutte did you archive this design?
https://user-images.githubusercontent.com/9484483/28835400-7b483378-76e5-11e7-9d6b-ded7a5df0a07.png

I no longer work at the company that I needed this design. I think I switched to a different library. I suppose that almost 8 years later there is a library that supports this 😅


✨Add a build for MacOS

This copies the Linux build to generate binaries for MacOS. Resolves #59

LGTM. Thank you, @cowboyd.

Let's rename webui-2-aarch64-apple-darwin.dylib to webui-2-x64.dyn to be consistent with other platforms' names. Please see this line for mere details.


Slice/Contour transfer functions sample the wrong data

The Slice and Contour histograms sample the currently active 3D variable, which exists outside of the plane that gets rendered.  Their histograms should be sampled from the ArbitrarilyOrientedRegularGrid instead.

This should be an optional capability - but not necessarily the default.


Bug wrong result when compare two float type

Proposed changes
Issue Number: close #17954
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

We will set enable fold constant by default after this PR so we do not need to add a regression test now

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 33.85 seconds
stream load tsv:          466 seconds loaded<PHONE_NUMBER>9 Bytes, about 153 MB/s
stream load json:         24 seconds loaded<PHONE_NUMBER> Bytes, about 93 MB/s
stream load orc:          74 seconds loaded<PHONE_NUMBER> Bytes, about 14 MB/s
stream load parquet:          32 seconds loaded 861443392 Bytes, about 25 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230320093029_clickbench_pr_117275.html


Flutter : Test Drive

Steps to Reproduce
while running the app in android studio I get this -
Launching lib\main.dart on Nexus 6P in debug mode...
Initializing gradle...
Resolving dependencies...
Finished with error:

Error running Gradle:
Unable to download needed Android SDK components, as the following licenses have not been accepted:
Android SDK Build-Tools 26.0.2

To resolve this, please run the following command in a Terminal:
flutter doctor --android-licenses
after I run this comman in terminal -
C:\Users\vrajs>flutter doctor --android-licenses
sdkmanager --version failed: 1
Logs
C:\Users\vrajs\AndroidStudioProjects\mind_spark>flutter analyze
Analyzing C:\Users\vrajs\AndroidStudioProjects\mind_spark...
No issues found!
Ran in 8.9s
Flutter Doctor
C:\Users\vrajs>flutter doctor -v
[√] Flutter (Channel beta, v0.1.5, on Microsoft Windows [Version 10.0.16299.248], locale en-US)
• Flutter version 0.1.5 at C:\Vraj\GitTrial\flutter
• Framework revision 3ea4d06340 (11 days ago), 2018-02-22 11:12:39 -0800
• Engine revision ead227f118
• Dart version 2.0.0-dev.28.0.flutter-0b4f01f759
[√] Android toolchain - develop for Android devices (Android SDK 27.0.3)
• Android SDK at C:\Users\vrajs\AppData\Local\Android\sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-27, build-tools 27.0.3
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)
[√] Android Studio (version 3.0)
• Android Studio at C:\Program Files\Android\Android Studio
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)
[!] IntelliJ IDEA Community Edition (version 2017.2)
X Flutter plugin not installed; this adds Flutter specific functionality.
X Dart plugin not installed; this adds Dart specific functionality.
• For information about installing plugins, see
https://flutter.io/intellij-setup/#installing-the-plugins
[!] VS Code (version 1.20.1)
• VS Code at C:\Program Files\Microsoft VS Code
• Dart Code extension not installed; install from
https://marketplace.visualstudio.com/items?itemName=Dart-Code.dart-code
[√] Connected devices (1 available)
• Nexus 6P • 8XV7N16128002032 • android-arm64 • Android 8.1.0 (API 27)
! Doctor found issues in 2 categories.

For more information about diagnosing and reporting Flutter bugs, please see https://flutter.io/bug-reports/.

Do you have Android SDK Build-Tools 26.0.2 installed?

Thanks. It was not installed( different version was). Issue is solved

Do you have Android SDK Build-Tools 26.0.2 installed?

@mit-mit @devoncarew Is something missing from doctor here? Seems to suggest android toolchain is good, but the error from Gradle and the response suggest that it was not?

It's hard for doctor to check for that: The particular version of Build Tools to use is project specific based on what is stated in the gradle build file.


Feature Request: Build File-Sample-Participant Mapping

Description
Use the file manifest received from ARCUS of all the submitted files and convert that into a manifest mapping file, sample, and participant. This mapping file should have the following columns:

[ ] genomic_file_id for the file's genomic file ID
[ ] sample_id for the kf_id of the sample associated with the file
[ ] participant_id for the kf_id of the participant associated with the sample

This file should be the same format as the one for CDS.
The generated mapping file should be placed in the data/ directory and the script(s) used to build the manifest should be in the scripts/ directory.

Created a new PR for the file and SQL here.


Fix Unicode problem

Hey, I was facing annoying problem while trying to execute it on python3
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 78357
I was referred to the modified line in the code, I changed it from the standard 'r' which is the default to 'rb' and everything is working like it should now.

Coverage decreased (-0.08%) to 92.447% when pulling b212e35ef6dee5426b89ffb0ad9240a9f5dcccb5 on Bennyelg:fixUnicodeProblemWhileReadingSpecOnPython3 into 56f29a0e6ed65ba197f6e005d86cd56e66db0731 on spulec:master.

Coverage decreased (-0.08%) to 92.447% when pulling b212e35ef6dee5426b89ffb0ad9240a9f5dcccb5 on Bennyelg:fixUnicodeProblemWhileReadingSpecOnPython3 into 56f29a0e6ed65ba197f6e005d86cd56e66db0731 on spulec:master.

@spulec  Will appreciate your assistance :]

Nice fix, @Bennyelg! Thanks for this. And welcome to Moto!

@Bennyelg thanks for this!

This is now released in 1.3.2. Thanks!


Remove bintrayUpload constraints

The deployment section in circle.yml will guarantee jars won't be
uploaded unless it's a release

Can you add information in the README.md about where the releases can be found?


[WIP] '/milestones' endpoints

Adds the '{owner}/{repo}/milestones' endpoints as per https://developer.github.com/v3/issues/milestones/

@GeorgiCodes :cake: This looks great!
Were you planning on implementing full CRUD for milestones here or in separate PRs?

@pengwynn I got excited and opened the PR a bit to soon. Ill add the other endpoints for milestones up and then ask for a review :sparkle:.

@pengwynn okie doke, thing this is ready for some :eyes: please. Had a blast writing some Go today :dancers:.

:metal:


Test: connecting to WSL workspaces over SSH

Refs: https://github.com/microsoft/vscode-remote-release/issues/9777

[ ] macOS @roblourens
[x] linux @sbatten
[ ] windows @bhavyaus

Complexity: 3
Create Issue

Pre-requisites

Have a Windows machine with WSL installed and an SSH server running (guide https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse?tabs=gui)
Have the latest version of Remote - WSL and Remote - SSH installed on your (non-Windows) machine

Test Steps

Use Remote - SSH to connect to the Windows machine
Check that the usual WSL bits work.

The WSL section of the Remote Explorer works
With a workspace folder open, you can "Reopen in WSL" to open the current folder in WSL
From inside WSL, you can "Reopen in Windows" to exit WSL

This requires WSL 0.88.1 which I am publishing currently. Please make sure you're on this version before doing the TPI


Fix/djang admin reviews list

I don't know exactly when this broke, the Django changelogs mention this function signature more often than I care to investigate further.

Very nice, tested here and it works for me


Move PolyMath codebase to Pharo 7.0

We start by adding Pharo7.0 to CI.
There is a problem at the moment with SMark that fails in Pharo 7.0 : https://travis-ci.org/PolyMathOrg/PolyMath/jobs/397973698
ScriptStarter class>>install use #ifNotNilDo: that is deprecated since Pharo 6.1. The problem has been reported upstream to Max Leske.

SMark now has a new stable version 1.0.2, which is also marked as stable (meaning, you can use #stable as version description).
Version 1.0.2 includes a couple of minor compatibility improvements and pulls in an updated version of the Scripting package, in which I have replaced the use of #ifNotNilDo:.
Let me know if I broke something.


docs: Readme add Local Setup and Setup a New scheduler sections

This pull request is updating the README.md to add local setup section and how to add a new scheduler.

:tada: This PR is included in version 1.32.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Validate SGX attestation quotes.

This is a spinoff from #68.
The AVR contains a quote that attests an enclave.  While it is impossible to validate the signature of the quote (EPID key), IAS will give a yes/no answer regarding the quote validity.  It is necessary to validate the enclave parameters against per-contract reference values.  Ideally this should happen both prior to sending the signed quote to IAS, and after the AVR has been received, though the latter case can be implemented as a memcmp.
Per @pro-wh:

I made this spreadsheet to compare what fields the Intel SGX SDK uses where:
https://docs.google.com/spreadsheets/d/1p5C2cYcLTZ3kg8c7nSjxVb9qVbYADc8HUSDL36EBipA/edit?usp=sharing

cpu_svn: check equality to (or should we also allow greater?) a reference value
misc_select: mask with 0xF0000000 (the misc_mask that sgx_seal_data uses by default) and check equality to a reference value
attributes: mask with 0xFF0000000000000B (the misc mask that sgx_seal_data uses by default) and check equality to a reference value (I forgot how this mask is meant to line up with the sgx_attributes_t though. you might have to dig through some SGX code to see how they normally do it)
mr_enclave: check equality to a reference value
mr_signer: don't check
isv_prod_id: check equality to a reference value
isv_svn: check equality to (or should we allow greater?) a reference value
padding: don't check (should we?)

This is done.


feat: update .luarc.json to include Black Atom repo types (DEV-141)

#69  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @nikbrunner and the rest of your teammates on  Graphite


Rdma functional tests improvements

This PR makes the RDMA functional tests more robust specially on single node environments where the API server will not be available during system restart

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 47.284%

Totals

Change from base Build<PHONE_NUMBER>9:
0.04%

Covered Lines:
7207

Relevant Lines:
15242

💛  - Coveralls


Can I use this in swiftUI

Hello,
Sorry for this silly question as I am a noob in iOS development.
I wanna just ask that this library is made in UIKit so can I use this library in my SwiftUI project ?

Yes. There are no any UIKit imports or requirements. Just one thing, I use GCD for concurrency, but you can add necessary functions as extension and implement structured concurrency approach.

Hello @odyshewroman
Thanks man
If I understand it correctly then if I don't want structured concurrency approach then still can I use this library into my SwiftUI without any change in project ?

Yep

Ok thanks


Prompt text overwritten on error in the previous command

I use the latest oh-my-zsh with the bira theme on zsh 5.7.1 installed using antigen.
antigen use oh-my-zsh
antigen theme robbyrussell/oh-my-zsh themes/bira
antigen apply
COMPLETION_WAITING_DOTS=false

When I run a command which returns an error, the cursor on the next prompt line gets moved to the $ character in the prompt causing it to be overwritten when a command is typed. There was also an issue with the cursor getting pushed a bit to the right and the backspace not working in some cases, but disabling COMPLETION_WAITING_DOTS seems to have fixed it. Example illustrating the issue below:
─ guruprasad@precious ~
╰─$ date
Thu Apr 11 23:48:03 IST 2019
╭─ guruprasad@precious ~
╰─$ lll
zsh: correct 'lll' to 'll' [nyae]? n
zsh: command not found: lll
╭─ guruprasad@precious ~
╰─$
╭─ guruprasad@precious ~
╰─ls

Make sure you have a locale that supports UTF-8. See locale -a for options, then set LANG to one of them.

@mcornella, thanks that was the issue on my computer :+1:


Remove invalid matrix spark 3.1 in GA

:mag: Description
Issue References 🔗

Maven profile spark-3.1 is removed.
Describe Your Solution 🔧
Remove invalid matrix spark 3.1 in GA. Note, that the cross version verify still exists to ensure that the Spark SQL engine works well on the Spark 3.1 runtime
Types of changes :bookmark:

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

Test Plan 🧪
Pass GA.

Checklist 📝

[x] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 61.01%. Comparing base (992042b) to head (f50de2e).

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #6151      +/-   ##
============================================
+ Coverage     60.99%   61.01%   +0.01%
  Complexity       24       24
============================================
  Files           625      625
  Lines         37219    37219
  Branches       5029     5029
============================================
+ Hits          22703    22710       +7
+ Misses        12068    12059       -9
- Partials       2448     2450       +2

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

Thanks, merged to master


Closed sessions are not immediately updated in the UI

Environment

Elixir & Erlang/OTP versions (elixir --version): OTP 24 / Elixir 1.13.0
Operating system: macOS
How have you started Livebook (mix phx.server, livebook CLI, Docker, etc): mix phx.server
Livebook version (use git show if running with mix): main
Browsers that reproduce this bug (the more the merrier): Firefox
Include what is logged in the browser console: -
Include what is logged to the server console: -

Current behavior
When a close an open session the file stays green.
Expected behavior
The file should change to grey to indicate it is not currently active
FileSelectComponent.update_file_infos/2 is not called when the session is closed, since the directory didn't change and force_reload? is false.
A workaround would be to check if the running_files are different in the socket and the assigns given during FileSelectComponent.update/2.
e.g adding:
force_reload? =
      (socket.assigns[:running_files] || []) != assigns[:running_files] or force_reload?

to FileSelectComponent.update/2 but that looks kinda ugly and there is probably a better approach.

The solution looks good to me, I'd just refactor into a separate variable like:
running_files_changed? = assigns.running_files != (socket.assigns[:running_files] || [])

Yes, no problem.
Then like
 update_file_infos(force_reload? or running_files_changed?)

or
 update_file_infos(force_reload?, running_files_changed?)

and update update_file_infos accordingly?

Cool! I prefer the first one, so update_file_infos stays unaware of that :)


Remove setup.py?

ga4gh_common/setup.py does consolidate setup code across the repos, but importing it in each repo's setup.py requires that ga4gh_common is installed as a package before the other package is installed, which is not always true and can cause an install to fail.  Which is more important, consolidating setup code or guaranteeing a normal pip install pattern?

I recommend against importing another setup.py within a package's own setup.py. It won't work in contexts where ga4gh_common isn't already installed.
One alternative is to use ga4gh_common as a template and manually sync changes between repos. This creates an incentive to package-specific details in configuration files, such as setup.cfg. I do this with my python template package and it works okay.
Another, possibly better option, is to use PBR, which puts everything in a config file. (I don't use PBR because I want to also sync a bunch of other files (see pytemplate above), so it wouldn't save me effort.)

Thanks for the info, @reece
Yes, I'm leaning towards taking out the import since we want to not break pip semantics and ensure a path of least resistance for (new) users.  Unfortunately, this will resort in code duplication, but I don't see any way around that.
PBR looks like it solves different problems than the ones we have.  I want to eliminate redundancy in setup.py files across different ga4gh repositories.  PBR looks like it only operates within one repository.
(I suppose we could utilize a different project structure that united all of our code into one giant repository, but I don't see a need for doing that -- indeed, there are many drawbacks.  But in that case, the problem I am trying to solve would not come up in the first place.)

Fixed in #12


Firebase email Trigger Custom Domain Error

[READ] Step 1: Are you in the right place?
[REQUIRED] Step 2: Describe your configuration

Extension name: _ (firestore-send-email)

[REQUIRED] Step 3: Describe the problem
So Iam in process to develop an Firestore Flutter Web App.
and when users fill a form I want to send an automatic mail to them.
aim used Firestore as a database and trying to set up cloud function to send email.
I have created an 'email' collection in the database and when data is added to this database the email trigger must work to send email automatically.
I have a custom email.
I have set the SMTP setting properly, and billing to blaze plan.
But when the data is added to the database I get error

Error when delivering message=email/wC0n9FGAN0DwQpx5ZdZC: Error:<PHONE_NUMBER>16832:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:827:

Steps to reproduce:
Followed the example given resulted with error. Somewhere I feel it must be related about TSL and SSL, certificates but I tried two different email resulting in the same error
Expected result
The mail getting send and the Delivery status to be success
Actual result
Error in the mail Delivery and status Error

Hi @ShreeBhagwat, do you mind sharing the insensitive (not the password) parts of you smtp URI? The error message above says unknown protocol which makes me think the SMTP URI protocol might be incorrectly set.


Objects always interpreted as optional when inside an object

Similar to #12, objects are interpreted as optional when inside an object, even when they are marked as required() or exist().
Code:
import * as Joi from '@hapi/joi'
import 'joi-extract-type'

const validator = Joi.object().required().keys({
  nested: Joi.object().required().keys({
    foo: Joi.string().required()
  })
})

type ResultType = Joi.extractType<typeof validator>
/*
ResultType is
Map<{
  nested?: Map<{} & {
    foo: string;
  }> | undefined; } & {}>
*/

// No error here
const x: ResultType = {}

// TS2532: Object is possibly 'undefined'.
console.log(x.nested.foo)

Versions:

Typescript 3.7.2
@hapi/joi 16.1.8
joi-extract-type 15.0.2

@bspot This is an issue with Joi 16. examples works on Joi 15
https://github.com/TCMiranda/joi-extract-type/issues/22


initial project move from kudo into its own project

There are a number of issues that need to be resolved however this move most of kudo test harness into its own project as kuttl
Changes:

The create-or-update integration test used to install / update an instance kind which is kudo specific and it has been removed.
TestWaitForCRDs was a kudo specific test and was removed

Todos:
[] harness.go used to have a RunKUDO function.  It has been removed but we need a way from KUDO (or other project) to initial the cluster (for instances with it's CRDS etc.)
[] test type defines StartKUDO bool json:"startKUDO"`` which should be removed
[] document this new project on how to use it (especially with above changes)
[] modify kudo to use this project.
[] document that kubebuilder is required with etcd in the path (fails otherwise)
This project infra supports 1) gen from test type, 2) lints with same standards as other kudobuilder projects, 3) make test and make integration-test work
Considerations:

do we need a CLI to execute? or does all users of this lib create their own?  I am expecting to have kudo test command which will integrate into this project.   That said... it would be nice to be able to run tests with cli.

Signed-off-by: Ken Sipe<EMAIL_ADDRESS>

yeah we should bring this out into it's own binary, if we want to keep kudo test then we'll just call out to kuttl.Init or whatever that code path is over from the kubectl kudo CLI, so we can bind a version of kuttl to a version of kudo test.

Another consideration - do we want to turn the provisioning/usage of external clusters into data, rather than using KIND? We don't need to solve that by any means in this PR, but it would result in removing the startKIND section. though IMO I kind of like having KIND as a nice built-in default for development, and then coming up from a data format of "bring your own cluster!"

@jmccormick2001

yeah... with more thought on it... I think having an executable CLI makes sense here

yeah... with more thought on it... I think having an executable CLI makes sense here

plus then when we make it a kubectl plugin it's kubectl kuttl - or kube cuttle cuttle. ;)


OpenEBS K8s provisioner should push images with "ci" tag as part of travis build

Is this a BUG REPORT or FEATURE REQUEST?
BUG REPORT

What happened:
To enable e2e runs on images with latest dev changes, the openebs/m-apiserver, openebs/openebs-k8s-provisioner and openebs/jiva images need to be pushed with a "ci" tag as part of the travis build. The ansible playbooks running in the ci suite will update the openebs-operator yaml from the release branch with the "ci" tags and deploy (refer #616 )
What you expected to happen:
openebs/m-apiserver and openebs/jiva already push the "ci" tag upon code changes, with "latest" & release-tags upon performing a major/minor release.
This needs to be extended to openebs/openebs-k8s-provisioner

We can solve it..
tag the image & push the image to the registry.

docker build -f Dockerfile -t $REPO:$COMMIT .
— docker tag $REPO:$COMMIT $REPO:$TAG
— docker tag $REPO:$COMMIT $REPO:travis-$TRAVIS_BUILD_NUMBER
— docker push $REPO


Meet the team updates

[ ] Add new team members per org chart
[ ] Yesenia Gutierrez needs to be updated to Yesenia Aparicio.

@erica-stivison and I are automatically notified when someone fills out the form to be added to Meet the team. Inclusion is opt-in. Is there anyone you're aware of @YeseniaGtz who wants to be on the page and isn't?
I will update your name today. Thank you for the prompt!


Give up display tokens in the faucet

The faucet is the only place in CosmJS where we still have the BCP token tickers supported (e.g. request SHELL instead of ushell). This causes a lot of effort to get right in the faucet and it also seems to confuse testnet users trying to request the base denom.
What about removing
export interface BankTokenMeta {
  readonly denom: string;
  /**
   * The token ticker symbol, e.g. ATOM or ETH.
   */
  readonly tickerSymbol: string;
  /**
   * The number of fractional digits the token supports.
   *
   * A quantity is expressed as atomic units. 10^fractionalDigits of those
   * atomic units make up 1 token.
   *
   * E.g. in Ethereum 10^18 wei are 1 ETH and from the quantity<PHONE_NUMBER>00000000000
   * the last 18 digits are the fractional part and the rest the wole part.
   */
  readonly fractionalDigits: number;
}

from the faucet entirely and leave it up to UI applications to convert between the base denom and a display token (where the logic needs to exist anyways for all the other APIs).
So instead of
JSON=$(jq -n --arg addr $(coral keys show -a fred) '{"ticker":"COSM", "address":$addr}') \
  && curl -X POST --header "Content-Type: application/json" --data "$JSON" https://faucet.coralnet.cosmwasm.com/credit

you'd
JSON=$(jq -n --arg addr $(coral keys show -a fred) '{"denom":"ucosm", "address":$addr}') \
  && curl -X POST --header "Content-Type: application/json" --data "$JSON" https://faucet.coralnet.cosmwasm.com/credit

@ethanfrey @orkunkl

Yes. Please!
It makes everything simpler and removes one more config variable in both frontend apps and @cosmjs/cli

On second thought can we punt this to 0.24?
We have the faucets and tutorials set up on coralnet and I would rather not break them.
I like the idea, but now that we have configurable tokens in env variables, I could also define ushell=10^0ushell and this would use the native token.
Faucet always seems a bit fragile and I would like to avoid changes before your vacation

The deployment API will change for sure in 0.23, but I guess this is not the critical part.
What we can do as an intermediate step is accept both the display token and the base token
{"ticker":"COSM", "address":$addr}

or
{"denom":"ucosm", "address":$addr}

at the same time. This allows us to migrate tutorials slowly.

Sounds like a good compromise

I guess #407 didn't actually close this as it's only the intermediate step.

Thanks Will. Removing this from the 0.23.0 milestone.

Since both of our current testsnets use CosmJS 0.22.x, we can finish this now on 0.23 or 0.24.


Converts ResultType from string to int enum

This converts the ResultType from string to int enum to curtail
the size of json object emittted by steps.
Closes #4150
Signed-off-by: Shivam Mukhade<EMAIL_ADDRESS>

Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Docs included if any changes are user facing
[ ] Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes

@sbwsg Could you take a look and let me know if I am right track? 😅

One potential risk here is if a controller is upgraded while a TaskRun is mid-execution. If that would happen then the taskrun's pod could return "TaskRunResult" but the controller could be expecting 1.  Is there a way we could work around this by implementing the Unmarshaller interface for ResultType? So if our custom UnmarshalJSON() detects a string then we convert it to its equivalent int?

@sbwsg yeah that make sense to not change type tot. Thank you adding the code snippet.
Updated the pr with changes.
@ScrapCodes Updated UnknownResultType to have value 10 let me know if that is good enough
ptal :)

@vdemeester the way we pass messages from Tasks to the controller is an internal implementation detail isn't it?

@vdemeester the way we pass messages from Tasks to the controller is an internal implementation detail isn't it?

Well, isn't this "exposed" as part of the status field of a TaskRun or PipelineRun ? If yes, then this means a user that was looking at those (for whatever reason) will have a "breakage" as the type changed (using to be a string, and is a number now). This is, I think, also affecting the tkn cli 🙃 (cc @piyush-garg) as we display results.

It's exposed at the following location in taskruns:
status:
  steps:
  - container: step-print-date-human-readable
    terminated:
      message: '[{"key":"current-date-human-readable","value":"Mon Sep 13 14:28:59
        UTC 2021\n","type":"TaskRunResult"},{"key":"current-date-unix-timestamp","value":"1631543338\n","type":"TaskRunResult"}]'

To be super explicit: we're talking about the stringified JSON blob in the termination message field. The "type" field in that stringified JSON blob will change from a string ("TaskRunResult") to an int.
You're saying that consumers of our API are parsing the stringified JSON blob for this data rather than looking in the status.taskResults list for the value?

You're saying that consumers of our API are parsing the stringified JSON blob for this data rather than looking in the status.taskResults list for the value?

They might but yes, if it's only exposed there, then I think we are safe 😛

I kind of agree with @vdemeester, whoever is looking at the terminated JSON blob will have a message with int instead of TaskRunResult. But I don't think it was designed to consume it in that way anyways so I am all good with these changes.
I would like to see the changes in the release notes to be on the safer side. @sm43 will you be able to please add the release notes with the status JSON blob change.

Nice idea @afrittoli I'll make a PR to document the lack of guarantees around the termination message.

Created https://github.com/tektoncd/pipeline/pull/4226 to capture termination message note.

@sbwsg @pritidesai added release notes, ptal if it looks okay.

thanks @sm43
/lgtm


4.0.2 spotbugs-gradle-plugin does not work with freefair lombok plugin

This is the project :
https://github.com/adaptris/interlok-nats/tree/spotbugs-gradle-4.0
We're using the freefair lombok plugin using lombok to reduce the amount of "clutter" in our java-code
spotbugs-gradle-plugin 3.0.0 works fine as is (check the develop branch); however, the 4.0.2 plugin fails.
lchan@phooey MINGW64 /c/adaptris/work/dev/nats (spotbugs-gradle-4.0)
$ ./gradlew compileJava

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\adaptris\work\dev\nats\build.gradle' line: 5

* What went wrong:
An exception occurred applying plugin request [id: 'java']
> Failed to apply plugin [id 'org.gradle.java']
   > com.github.spotbugs.snom.SpotBugsExtension_Decorated cannot be cast to org.gradle.api.plugins.quality.CodeQualityExtension

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 767ms

The changes in the branch are :

Upgraded to gradle 6.2.2 (since we were running 5.6.3)
Switch to just a spotbugsMain{} section rather than a tasks.withType() since you've changed the package name.
It's running with Java8 :

$ java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (Zulu <IP_ADDRESS>-CA-win64) (build 1.8.0_242-b20)
OpenJDK 64-Bit Server VM (Zulu <IP_ADDRESS>-CA-win64) (build 25.242-b20, mixed mode)

Note that we can upgrade other projects that don't use lombok to the 4.0.2 plugin; using Java 8 + gradle 5.6.3

I checked the src code and it's because the groovy task extends DefaultTask, and doesn't extend CodeQualityExtension.

Currently our extension does not depend on CodeQualityExtension. because:

The setSourceSets() API introduces hidden dependency in build script and it makes build unstable unexpectedly.
It lacks documentation. Even though it's not put into internal package, it actually behaves Gradle internal one. Gradle sometimes changes behavior of public API (example) so it's better to stop depending on nonessential API, in my feeling.
I think setSourceSets() API is not proper in the manner of recent Gradle. It should receive ListProperty<SourceSet>. Gradle could bring breaking change here.

This plugin is initially forked from Gradle official plugin, but it's now re-implemented from scratch, then has less motivation to extend CodeQualityExtension. Could you propose a fix to the freefair lombok plugin side? Thanks for your understanding!

Hello, please could you explain is there another similar bug about Lombok and spotbugs gradle plugin? why this ticket is closed?

@yuriy-slobodchikov I opened the above ticket with the lombok plugin, and it looks like they've committed a fix for this issue on their end. I imagine this will be fixed whenever they release a new lombok plugin version.


etcdctl: unset ETCDCTL_ARGS on cov builds

The stricter warnings on pkg/flags generates extra output that
break coverage tests. Unset the ETCDCTL_ARGS environment variable
so the warnings aren't printed.

lgtm


Missing AutomationId on ComponentFactory.Krypton.Ribbon

We use Krypton (V 4.4.0) on our windows form to create ribbons for the menu.
We have a main ribbon which holds additional tabs (like in Microsoft Word). This main ribbon has the "File" tab, when clicked it displays a collection [KryptonContextMenuItem()] of menu items but none of them display an AutomationId on the inspect.exe tool.
The additional tabs (Path Planner) don't have the same issue, is just the squared window that comes up when "File" is clicked.
The krypton tool doesn't have a "name" member, just the "Text". The menu item names are set on the code as:
this->kryptonContextImportMesh->Text = L"Import Mesh...";

Any recommendations on how to solve this? I can't open the window shown by the "File" tab through my tests.

Hi @marlamulero,
If Inspect.exe can pick up the elements, then WinAppDriver will be able to automate / interact against it. If Inspect.exe or UI Recorder are not able to pick up these elements, then WinAppDriver will not able to automate against it.


Implement KeyboardFocus resource and focus keyboard events

What problem does this solve or what need does it fill?
See discussion: #15374
What solution would you like?
Implementation steps:

[ ] Define KeyboardFocus resource.
[ ] Write synchronization code between KeyboardFocus and bevy_a11y::Focus.
[ ] Define FocusKeyboardEvent and HoverKeyboardEvent types.
[ ] Write systems to read from input queue and dispatch the events.
[ ] Write plugin which adds these systems and resources.

@alice-i-cecile @UkoeHB

Prototype is in PR #15611


Calling consoleInit with sf2dlib running results in a crash

I wanted to draw on the top screen with sf2dlib, and use ctrulib's built-in console on the bottom screen. But when I added the consoleInit call to my program, it crashed as soon as it started. I tried moving it to before the sf2d_init call, and the same thing happened.
I understand that normally it wouldn't make sense to be using two things that require a full screen to write to at once, but I'm writing a program for a device that has two screens, so I don't see why this shouldn't be possible.

ctrulib's console works fine for me, as long as I'm not making a frame for that screen.

Oh, I just tried again and it worked fine. No idea what went wrong before. Thanks!


Hyperion maxing out cpu on Pi2

Hi,
first I have to say I am absolute newbie so please forgive any dumb questions or missing infos. I recently build a Ambilight with Pi2, 186 Apa102 LEDs and using this on raspian Jesse, controlled via atmolight plugin from Mediaportal.
I am currently seeing a high cpu load for my Pi2. After a while (sometimes an hour, sometimes only a few minutes) one core is at 100% CPU load, and temperatures and mem usage are increasing too. See attached pic of htop.

strace shows the following:

poll([{fd=3, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=7, events=POLLIN}], 4, 0) = 2 ([{fd=3, revents=POLLIN}, {fd=7, revents=POLLIN}])
read(3, "\2\0\0\0\0\0\0\0", 16)         = 8
ioctl(7, FIONREAD, [911458])            = 0
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x577b1000
read(7, "\0\0000\31\10\2Z\224\0102\20@\30@\"\2001 \0223"\21,\30\0100\36\6\22\v"..., 911458) = 911458
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x576b0000
mremap(0x577b1000, 1052672, 69632, MREMAP_MAYMOVE) = 0x577b1000
munmap(0x577b1000, 69632)               = 0
mremap(0x578b2000, 460644352, 536875008, MREMAP_MAYMOVE) = 0x376af000
munmap(0x576b0000, 1052672)             = 0
gettimeofday({1453452189, 441913}, NULL) = 0
gettimeofday({1453452189, 442405}, NULL) = 0
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
write(7, "\0\0\0\2\10\1", 6)            = 6
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
mmap2(NULL, 461545472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x577d6000
munmap(0x376af000, 536875008)           = 0
poll([{fd=3, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=7, events=POLLIN}], 4, 0) = 2 ([{fd=3, revents=POLLIN}, {fd=7, revents=POLLIN}])
read(3, "\2\0\0\0\0\0\0\0", 16)         = 8
ioctl(7, FIONREAD, [911447])            = 0
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x576d5000
read(7, "\0\0000\31\10\2Z\224\0102\20@\30@\"\200'\32!%\31\31&\32\35!\31\31%""..., 911447) = 911447
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x575d4000
mremap(0x576d5000, 1052672, 69632, MREMAP_MAYMOVE) = 0x576d5000
munmap(0x576d5000, 69632)               = 0
mremap(0x577d6000, 461545472, 536875008, MREMAP_MAYMOVE) = 0x375d3000
munmap(0x575d4000, 1052672)             = 0
gettimeofday({1453452190, 928819}, NULL) = 0
gettimeofday({1453452190, 929478}, NULL) = 0
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
write(7, "\0\0\0\2\10\1", 6)            = 6
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
mmap2(NULL, 462442496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x576fb000
munmap(0x375d3000, 536875008)           = 0
poll([{fd=3, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=7, events=POLLIN}], 4, 0) = 2 ([{fd=3, revents=POLLIN}, {fd=7, revents=POLLIN}])
read(3, "\2\0\0\0\0\0\0\0", 16)         = 8
ioctl(7, FIONREAD, [1046956])           = 0
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x575fa000
read(7, "(\377\377\377\377\377\377\377\377\377\1\0\0000\31\10\2Z\224\0102\20<EMAIL_ADDRESS>1046956) = 1046956
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x574f9000
mremap(0x574f9000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x572f8000
mremap(0x575fa000, 1052672, 69632, MREMAP_MAYMOVE) = 0x575fa000
munmap(0x575fa000, 69632)               = 0
mremap(0x572f8000, 2101248, 1052672, MREMAP_MAYMOVE) = 0x572f8000
mremap(0x576fb000, 462442496, 536875008, MREMAP_MAYMOVE) = 0x372f7000
munmap(0x572f8000, 1052672)             = 0
gettimeofday({1453452192, 640949}, NULL) = 0
gettimeofday({1453452192, 641449}, NULL) = 0
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
write(7, "\0\0\0\2\10\1", 6)            = 6
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
mmap2(NULL, 463478784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x575fe000
munmap(0x372f7000, 536875008)           = 0
poll([{fd=3, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=7, events=POLLIN}], 4, 0) = 2 ([{fd=3, revents=POLLIN}, {fd=7, revents=POLLIN}])
read(3, "\2\0\0\0\0\0\0\0", 16)         = 8
ioctl(7, FIONREAD, [3395655])           = 0
mmap2(NULL, 4198400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x571fd000
read(7, "\0\0000\31\10\2Z\224\0102\20@\30@\"\200\21\24\30!\33\37 \27\35\36\31\33\32\30"..., 3395655) = 3395655
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x570fc000
mremap(0x570fc000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x56efb000
mremap(0x56efb000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x56afa000
mremap(0x571fd000, 4198400, 69632, MREMAP_MAYMOVE) = 0x571fd000
munmap(0x571fd000, 69632)               = 0
mremap(0x575fe000, 463478784, 536875008, MREMAP_MAYMOVE) = 0x36af9000
munmap(0x56afa000, 4198400)             = 0
gettimeofday({1453452201, 111827}, NULL) = 0
gettimeofday({1453452201, 112419}, NULL) = 0
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
write(7, "\0\0\0\2\10\1", 6)            = 6
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
mmap2(NULL, 466862080, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x572c4000
????( <unfinished ...>
+++ killed by SIGKILL +++

Do you have any pointer for me how to solve this?

Ok, seems to be settled. I've raised the bitrate from 250.000 to 750.000. No problems since then...

Hi,
Check also the resolution of the frame grabber, if you have changed to a bigger size than 64x64 it will consume more CPU/MEM.

I haven't even enabled framegrabber. But as said, raising the bitrate did the trick. Tho I still think this is a bug, shouldn't max out CPU if bitrate is too low.

@theMPstig can it be closed?