Dependencies update for conf/dependencies.yml

I have a partial solution. I am having problems with updating the dependencies. It seems some of the upstream libraries cannot be resolved. This is what I started with as a result:
~ *****************************************************************************
~ WARNING: These dependencies are missing, your application may not work properly (use --verbose for details),
~
~       javax.media->jai_core 1.1.3: missing artifact
~       org.opentripplanner->otp 1.0.0-SNAPSHOT
~       voldemort.store.compress->h2-lzf 1.0
~       java3d->vecmath 1.3.2
~       jgridshift->jgridshift 1.0
~ *****************************************************************************

As suggested by Damien Goujard in issue #171 one can manually copy some of the dependency files directly the the lib/ folder. That, however, resulted in the following warnings:
~ *****************************************************************************
~ WARNING: Your lib/ and modules/ directories and not synced with current dependencies (use --sync to automatically delete them)
~
~       Unknown: /usr/local/gtfs-editor/lib/jgridshift-1.0.jar
~       Unknown: /usr/local/gtfs-editor/lib/jai_core-1.1.3.jar
~       Unknown: /usr/local/gtfs-editor/lib/h2-lzf-1.0.jar
~       Unknown: /usr/local/gtfs-editor/lib/vecmath-1.3.2.jar
~       Unknown: /usr/local/gtfs-editor/lib/otp-1.0.0-SNAPSHOT.jar
~ *****************************************************************************

And yes, if you now use --sync it indeed deletes your just-completed hard work ;-)
I have been able to resolve most of these, and did it by changing the contains: portion of the conf/depedencies.yml file as follows:
# Application dependencies
...

repositories:
    - typesafe:
        type: iBiblio
        root: "http://repo.typesafe.com/typesafe/releases/"
        contains:
            - com.typesafe.akka -> *
            - voldemort.store.compress -> *
    - osgeo:
        type: iBiblio
        root: "http://download.osgeo.org/webdav/geotools/"
        contains:
            - org.geotools -> *
            - java3d -> *
            - javax.media -> *
            - jgridshift -> *
    - conveyal:
        type: iBiblio
        root: "http://maven.conveyal.com/"
        contains:
            - org.opentripplanner -> *

But I remain with two problems:
~ *****************************************************************************
~ WARNING: These dependencies are missing, your application may not work properly (use --verbose for details),
~
~       javax.media->jai_core 1.1.3: missing artifact
~       org.opentripplanner->otp 1.0.0-SNAPSHOT
~ *****************************************************************************

... even though both these jar files have been copied manually to the lib/ folder.

I have checked that osgeo.org contains javax.media and jai_core 1.1.3 - the .jar file is there. However, it seems that before osgeo.org is checked, Maven Central is checked first!! An there too is a java/media/jai_core/1.1.3/ folder but it does not contain the correct .jar file. So it does not fall back to osgeo.org. Is there a way one can tell the dependency management to first check the repositories we provide in the dependencies.yml file before checking maven central? It was logged as a known issue on Maven central, stating the jar was possible never there... and the issue was closed with a 'won't fix' comment.
I cannot access Conveyal's maven repository. I get 404 Not found response with the following additional info:

Code: NoSuchKey
Message: The specified key does not exist.
Key: index.html
RequestId: E7C4DACA2F4DA880
HostId: fpwoGNvuculLATNVuiJ7jt6o8SIE95Od9geQULj9zjvZI8ssucSHxJkpR9oSJPTfOHshR40NaXc=

Any suggestions please?

I get the same error message as yours at the top but it doesn't seem to matter. I just copied otp-1.0.0-SNAPSHOT.jar into the lib/ directory, and use the .yml file as it comes from the repo.
This is possibly a bit of a silly suggestion, and people who understand these things better will be able to say for sure, but I've never been sure whether play requires Maven or Ivy to be installed to correctly manage dependencies. For what it's worth, both are installed on the box where I have this working.
Cheers

As of current version (c5c18e6), I have the following issues:
::          UNRESOLVED DEPENDENCIES         ::
::::::::::::::::::::::::::::::::::::::::::::::
:: voldemort.store.compress#h2-lzf;1.0: not found
:: java3d#vecmath;1.3.2: not found
:: jgridshift#jgridshift;1.0: not found
::::::::::::::::::::::::::::::::::::::::::::::
::              FAILED DOWNLOADS            ::
:: javax.media#jai_core;1.1.3!jai_core.jar

No more problem wit otp.
@JWJoubert solution parly worked except I had to change repo for voldemort:
- akka:
    type: iBiblio
    root: "http://repo.akka.io/releases/"
    contains:
        - voldemort.store.compress -> *

And the only remaining warning is with jai_core

Hello, attached my dependencies.yml file, which might be helpful for others, too.
I could fix every issue, except for otp-0.14.0.jar. See also:
https://groups.google.com/forum/#!topic/opentripplanner-users/V6dDw1QIO7E
In the end, as neither 0.20.0 nor latest 1.1.0 worked for me, I just copied the otp-0.14.0.jar into the lib folder, and conveyal worked even in a docker image.
# Application dependencies

require:
    - play
    - com.typesafe.akka -> akka-actor 2.0.3
    - com.typesafe.akka -> akka-remote 2.0.3
    - gov.sandia.foundry -> gov-sandia-cognition-common-core 3.3.2
    - gov.sandia.foundry -> gov-sandia-cognition-learning-core 3.3.2
    - com.google.guava -> guava 11.0.1
    - com.vividsolutions -> jts 1.12
    - org.geotools -> gt-main 12.2
    - org.geotools -> gt-geojson 12.2
    - com.fasterxml.jackson.core -> jackson-core 2.4.4
    - com.fasterxml.jackson.core -> jackson-databind 2.4.4
    - net.sf.opencsv -> opencsv 2.0
    - org.mapdb -> mapdb 1.0.7

    - org.opentripplanner -> otp 0.14.0

    - org.hsqldb -> hsqldb 2.3.4
    - com.google.guava -> guava 11.0.1
    - javax.servlet -> servlet-api 2.5
    - javax.media -> jai_core 1.1.3
    - voldemort.store.compress -> h2-lzf 1.0
    - java3d -> vecmath 1.5.2
    - jgridshift -> jgridshift 1.0

repositories:

    - typesafe:
        type: iBiblio
        root: "http://repo.typesafe.com/typesafe/releases/"
        contains:
            - com.typesafe.akka -> *

    - akka:
        type: iBiblio
        root: "http://repo.akka.io/releases/"
        contains:
            - voldemort.store.compress -> *

    - osgeo:
        type: iBiblio
        root: "http://download.osgeo.org/webdav/geotools/"
        contains:
            - org.geotools -> *
            - java3d -> *
            - javax.media -> *
            - jgridshift -> *

    - conveyal:
        type: iBiblio
        root: "http://maven.conveyal.com/"
        contains:
            - org.opentripplanner -> *


4.1.X.Y Data Provenance Tracking

Update "Data Provenance Tracking" from old RAM <IP_ADDRESS>

Closed by #193


Cargo resolves different versions of dependencies (with different MSRV) from Cargo 1.60 and up

Hi! I'm using GitHub Workflows to check PRs. I also added a check ensuring that all PRs conform to the rust-version defined in the projects Cargo.toml. However, it seems I got something wrong. Do you have an idea what could be the problem? :)
Here's what I've got:
verify-msrv:
    runs-on: ubuntu-latest
    name: verify minimum supported rust version (ubuntu)
    timeout-minutes: 30

    # we are using the `cargo-msrv` app
    # https://github.com/foresterre/cargo-msrv

    steps:
      - uses: actions/checkout@v2

      - name: Install or use cached foresterre/cargo-msrv
        uses: baptiste0928/cargo-install@v1
        with:
          crate: cargo-msrv

      - name: Verify the Rustc version declared in `cargo.toml`
        run: |
          cargo-msrv verify

(see https://github.com/johannesvollmer/exrs/blob/a4aa0acc9fe9d4467eabf47cb647ff99dc7b10b5/.github/workflows/rust.yml#L39)
I checked that your tool returns exit codes. Somehow, the check does not fail though. This is the output I get from GitHub:
Run cargo-msrv verify
  cargo-msrv verify
  shell: /usr/bin/bash -e {0}
Fetching index
Verifying the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check

(see https://github.com/johannesvollmer/exrs/actions/runs/5441981161/jobs/9896601827?pr=191)
Shouldn't there be more text? The same command correctly fails on my local machine. Maybe you have an idea? :)

Happy to help if I can!
Attempts to reproduce
I shallow cloned your repo and got the following (locally):

Making sure I'm running the latest release, and not the latest beta
❯ cargo msrv --version
cargo-msrv 0.15.1

Showing the MSRV
❯ cargo msrv show
Fetching index
1.59.0

Running `cargo msrv` to find the MSRV
NB: In this case it will never go below the currently set rust-version, which is 1.59. I also removed the rust-version and ran the test again; then the MSRV is still 1.59, because rayon-core requires 1.59 or newer.
❯ cargo msrv
Fetching index
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check

Check for toolchain '1.51.0-x86_64-unknown-linux-gnu' failed with:
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ warning: `rust-version` is not supported on this version of Cargo and will be ignored                                      │
│                                                                                │
│ this Cargo does not support nightly features, but if you                                                                   │
│ switch to nightly channel you can add                                                                                │
│ `cargo-features = ["rust-version"]` to enable this feature                                                                 │
│     Updating crates.io index                                                                                │
│  Downloading crates ...                                                                                │
│   Downloaded spin v0.9.8                                                                                │
│   Downloaded simd-adler32 v0.3.5                                                                                │
│   Downloaded miniz_oxide v0.7.1                                                                                │
│   Downloaded getrandom v0.2.10                                                                                │
│   Downloaded futures-sink v0.3.28                                                                                │
│   Downloaded futures-core v0.3.28                                                                                │
│   Downloaded memoffset v0.9.0                                                                                │
│   Downloaded quote v1.0.29                                                                                │
│   Downloaded pin-project-internal v1.1.2                                                                                │
│   Downloaded unicode-ident v1.0.9                                                                                │
│   Downloaded zune-inflate v0.2.54                                                                                │
│   Downloaded pin-project v1.1.2                                                                                │
│   Downloaded num_cpus v1.16.0                                                                                │
│   Downloaded bit_field v0.10.2                                                                                │
│   Downloaded lock_api v0.4.10                                                                                │
│   Downloaded crossbeam-utils v0.8.16                                                                                │
│   Downloaded proc-macro2 v1.0.63                                                                                │
│   Downloaded crossbeam-epoch v0.9.15                                                                                │
│   Downloaded crossbeam-channel v0.5.8                                                                                │
│   Downloaded syn v2.0.23                                                                                │
│   Downloaded libc v0.2.147                                                                                │
│    Compiling autocfg v1.1.0                                                                                │
│     Checking cfg-if v1.0.0                                                                                │
│    Compiling libc v0.2.147                                                                                │
│    Compiling proc-macro2 v1.0.63                                                                                │
│    Compiling quote v1.0.29                                                                                │
│    Compiling crossbeam-utils v0.8.16                                                                                │
│     Checking scopeguard v1.1.0                                                                                │
│    Compiling unicode-ident v1.0.9                                                                                │
│    Compiling futures-core v0.3.28                                                                                │
│     Checking simd-adler32 v0.3.5                                                                                │
│    Compiling rayon-core v1.11.0                                                                                │
│     Checking futures-sink v0.3.28                                                                                │
│ error: edition 2021 is unstable and only available with -Z unstable-options.                                               │
│                                                                                │
│ error: could not compile `rayon-core`                                                                                │
│                                                                                │
│ To learn more, run the command again with --verbose.                                                                       │
│ warning: build failed, waiting for other jobs to finish...                                                                 │
│ error: build failed                                                                                │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Check for toolchain '1.61.0-x86_64-unknown-linux-gnu' succeeded

Check for toolchain '1.56.1-x86_64-unknown-linux-gnu' failed with:
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ error: package `exr v1.6.5 (/home/marwen/ws/cargo-msrv-exrs)` cannot be built because it requires rustc 1.59.0 or newer,   │
│ while the currently active rustc version is 1.56.1                                                                         │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Check for toolchain '1.58.1-x86_64-unknown-linux-gnu' failed with:
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ error: package `rayon-core v1.11.0` cannot be built because it requires rustc 1.59 or newer, while the currently active    │
│ rustc version is 1.58.1                                                                                │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Check for toolchain '1.59.0-x86_64-unknown-linux-gnu' succeeded
   Finished The MSRV is: 1.59.0   ███████████████████████████████████████████████████████████████████████████████████ 00:00:47

Running cargo msrv verify (I expected it to succeed since the MSRV was found to be 1.59)
❯ cargo msrv verify
Fetching index
Verifying the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check
   Finished Satisfied MSRV check: 1.59.0 ████████████████████████████████████████████████████████████████████████████ 00:00:00

</details>

<details>
<summary>Setting the MSRV to 1.58 test whether that would fail (as expected)</summary>```

❯ cargo msrv set 1.58
Fetching index
❯ cargo msrv verify
Fetching index
Verifying the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check
Done Bad check for 1.58.1      ███████████████████████████████████████████████████████████████████████████████████ 00:00:00
Failed check command cargo check didn't succeed
Crate source was found to be incompatible with its MSRV '1.58.1', as defined in '/home/marwen/ws/cargo-msrv-exrs/Cargo.toml'
❯ echo $?
1

</details>

<details>
<summary>Running some commands on linked commit `a4aa0acc`</summary>

❯ cargo msrv set 1.59
Fetching index
❯ cargo msrv --output-format json verify
{"reason":"fetching-index"}
{"reason":"mode","mode":"verify-msrv","toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"installing","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"checking","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"check-complete","version":"1.59.0","step":0,"total_steps":1,"success":true,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"verify-complete","success":true,"msrv":"1.59.0","toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}

After the above I checked with your linked commit.

git fetch --depth=1 upstream a4aa0acc9fe9d4467eabf47cb647ff99dc7b10b5
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 2), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), 439 bytes | 109.00 KiB/s, done.
From github.com:johannesvollmer/exrs

branch            a4aa0acc9fe9d4467eabf47cb647ff99dc7b10b5 -> FETCH_HEAD

❯ git checkout a4aa0acc9fe9d4467eabf47cb647ff99dc7b10b5
M       Cargo.toml
Note: switching to 'a4aa0acc9fe9d4467eabf47cb647ff99dc7b10b5'.
❯ git checkout Cargo.toml
Updated 1 path from the index
❯ cargo msrv show
Fetching index
1.59.0
❯ cargo msrv verify
Fetching index
Verifying the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check
Finished Satisfied MSRV check: 1.59.0 ████████████████████████████████████████████████████████████████████████████ 00:00:00
❯ echo $?
0

</details>

### Request for more information :)

> I checked that your tool returns exit codes. Somehow, the check does not fail though. This is the output I get from GitHub

For what MSRV do you expect it to fail? Running it locally suggests an MSRV is 1.59, so running `cargo msrv verify` on 1.59 should succeed (with exit code 0).

> Shouldn't there be more text? The same command correctly fails on my local machine. Maybe you have an idea? :)

There should be more text indeed. Can you perhaps try the json output format to confirm it has nothing to do with the indicatif based formatter used by default:

`cargo msrv --output-format json verify`

Hi! Thanks for your help so far.
I realize I forgot some important information, sorry. The main/master branch is fine. But a currently open PR should fail, which is the branch f16_batch_conversion.
The reason why I expect it to fail is because a dependency was updated in this PR, but the new version of that dependency has a newer MSRV, 1.70. See half-rs/Cargo.toml:rust-version. Running cargo msrv verify on that branch fails, as expected. But it doesn't fail in the CI on the same branch.

There should be more text indeed. Can you perhaps try the json output format to confirm it has nothing to do with the indicatif based formatter used by default:
cargo msrv --output-format json verify

Yes I'll do that :)

I realize I forgot some important information, sorry. The main/master branch is fine. But a currently open PR should fail, which is the branch f16_batch_conversion.
The reason why I expect it to fail is because a dependency (half-rs) was updated in this PR, which requires a newer Rust version than we currently have. (The new version of that dependency has a newer MSRV, 1.70, see half-rs/Cargo.toml:rust-version, but we have 1.59).

An initial reply; I will need to dive a bit deeper before I can conclude anything, however, when I check out the branch (which defines rust-version as 1.59) and run:
1) cargo msrv verify
rm -f Cargo.lock && cargo msrv --output-format json verify
{"reason":"fetching-index"}
{"reason":"mode","mode":"verify-msrv","toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"installing","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"checking","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"check-complete","version":"1.59.0","step":0,"total_steps":1,"success":true,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"verify-complete","success":true,"msrv":"1.59.0","toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}

2) cargo +1.70.0 check && cargo msrv verify
rm -f Cargo.lock && cargo check && cargo msrv --output-format json verify
    Updating crates.io index
    Finished dev [optimized + debuginfo] target(s) in 0.58s
{"reason":"fetching-index"}
{"reason":"mode","mode":"verify-msrv","toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"installing","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"checking","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"check-complete","version":"1.59.0","step":0,"total_steps":1,"success":false,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}
{"reason":"verify-complete","success":false,"toolchain":"x86_64-unknown-linux-gnu","check_cmd":"cargo check"}

I get different results, based on which Rust version resolves the Cargo.lock file. Both use resolver version = 3.

This is what I got for the branch f16_batch_conversion:
{"reason":"fetching-index"}
{"reason":"mode","mode":"verify-msrv","toolchain":"x86_64-pc-windows-msvc","check_cmd":"cargo check"}
{"reason":"installing","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-pc-windows-msvc","check_cmd":"cargo check"}
{"reason":"checking","version":"1.59.0","step":0,"total":1,"toolchain":"x86_64-pc-windows-msvc","check_cmd":"cargo check"}
{"reason":"check-complete","version":"1.59.0","step":0,"total_steps":1,"success":false,"toolchain":"x86_64-pc-windows-msvc","check_cmd":"cargo check"}
{"reason":"verify-complete","success":false,"toolchain":"x86_64-pc-windows-msvc","check_cmd":"cargo check"}
Crate source was found to be incompatible with its MSRV '1.59.0', as defined in 'C:\Users\JohannesVollmer\Documents\Github\exrs\Cargo.toml'

Cargo.lock version = 3

exrs> rustc --version
rustc 1.70.0 (90c541806 2023-05-31)

Your stable Rust version shouldn't matter for cargo-msrv, all calls to Cargo go through rustup run with a specific toolchain.

I created a new crate for minimal reproduction, and tested this issue with all toolchains from Rust 1.56 - 1.70 here: https://github.com/foresterre/wow-cargo
The resolver behaviour really seems to change from Rust 1.59 to Rust 1.60.
I also checked the cargo changelog: https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-160-2022-04-07
To me, there is nothing which explicitely stands out: there are no changes to the resolver itself.

I asked on Zulip in the t-cargo channel.
There is a Cargo issue open: https://github.com/rust-lang/cargo/issues/10623
The problem is caused by the new dep: syntax instroduced with Cargo 1.60.

This is an issue with Cargo, but not one that's easy to fix. The issue comes because egui uses the new dep: syntax. Older Cargos don't know how to interpret this syntax and so skip parsing the version. Cargo could error on versions that they don't know how to interpret, but then you would be unable to build older versions using an older cargo just because newer versions used a newer feature. The correct solution here is for Cargo to keep track of a reason why any given package/version/feature cannot be selected and display it when relevant. Unfortunately the "when relevant" hard is a really hard feature. There are often hundreds of "reasons" that relate to the final resolution/error, only a handful of which are actually interesting to the user. We might be able to make incremental progress on these simple cases, but I am saving my effort for the multi year project of using pubgrub for our error messages.
-- https://github.com/rust-lang/cargo/issues/10688#issuecomment-1133639803

Thanks to @Eh2406 on Zulip for pointing me to Cargo issue.

I'm thinking about what to do from here; there doesn't seem to be an easy solution.

It may be still using an old lock file, especially since it is in the gitignore, so you won't be notified on switching branches.

I think I ran cargo update after switching the branch to exclude that possibility. But maybe I got mixed up

When I tried cargo +1.70.0 check yesterday (and a few other rustc versions), it never succeeded, because it couldn't select an appropriate version for half or image dependency. I didn't read the manual on that command though

But independent of dependency management, the following conditions should always lead to a failure, but somehow succeed:

half = "^2.3" (their rust-version being 1.70)
Cargo.toml: rust-version = 1.59

I don't think it's possible that Cargo will ever select a version of half below 2.3?
Therefore, it's perhaps a caching issue in the pipeline. I think I'll try some kind of clean build without caching in the pipeline

But independent of dependency management, the following conditions should always lead to a failure, but somehow succeed:

half = "^2.3" (their rust-version being 1.70)
Cargo.toml: rust-version = 1.59

I don't think it's possible that Cargo will ever select a version of half below 2.3?

I think that should be impossible, indeed.
I tested this in my test repo, and for me it does indeed fail:
[package]
name = "wow-cargo"
version = "0.1.0"
edition = "2021"
rust-version = "1.59"

[dependencies]
half = "^2.3.0"

 cargo msrv verify
  [Meta]   cargo-msrv 0.16.0-beta.14
Compatibility Check #1: Rust 1.59.0
  [FAIL]   Is incompatible

  ╭─────────────────────────────────────────────────────────────────────────╮
  │     Updating crates.io index                                            │
  │ error: failed to select a version for the requirement `half = "^2.3.0"` │
  │ candidate versions found which didn't match: 2.2.1, 2.2.0, 2.1.0, ...   │
  │ location searched: crates.io index                                      │
  │ required by package `wow-cargo v0.1.0 (/home/marwen/ws/wow-cargo)`      │
  │                                                                         │
  ╰─────────────────────────────────────────────────────────────────────────╯

Crate source was found to be incompatible with Rust version '1.59' specified as MSRV in the Cargo manifest located at '/home/user/wow-cargo/Cargo.toml'

I'll try to remove the caching from my pipeline and run the tool without any Cargo.lock :)

The script I used, to avoid caching is:
    steps:
      - uses: actions/checkout@v2

      - name: Install foresterre/cargo-msrv without cache
        run: |
          cargo install cargo-msrv

      - name: Verify the Rustc version declared in `cargo.toml`
        run: |
          rm -f Cargo.lock
          cargo update
          cargo-msrv verify

And it worked! The pipeline failed, as it should :)


Avoid stacktrace for msrest ValidationError.

Fixes #3271.

This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[N/A] The PR has modified HISTORY.rst with an appropriate description of the change (see Modifying change log).

Command Guidelines

[N/A] Each command and parameter has a meaningful description.
[N/A] Each new command has a test.

(see Authoring Command Modules)

@troydai for the telemetry related stuff (I just went by example). @derekbekoe since he agreed with the fix (at least conceptually :smile:)

Codecov Report

Merging #3431 into master will increase coverage by 0.2%.
The diff coverage is 37.5%.

@@           Coverage Diff            @@
##           master   #3431     +/-   ##
========================================
+ Coverage    70.6%   70.8%   +0.2%
========================================
  Files         394     394
  Lines       25552   25559      +7
  Branches     3879    3894     +15
========================================
+ Hits        18040   18097     +57
+ Misses       6365    6317     -48
+ Partials     1147    1145      -2

Impacted Files
Coverage Δ

...li-acs/azure/cli/command_modules/acs/acs_client.py
49.12% <0%> (+0.87%)
:arrow_up:

...azure-cli-core/azure/cli/core/commands/__init__.py
82.27% <42.85%> (-0.2%)
:arrow_down:

...zure-cli-vm/azure/cli/command_modules/vm/custom.py
75.53% <0%> (+0.32%)
:arrow_up:

...ource/azure/cli/command_modules/resource/custom.py
54.1% <0%> (+0.33%)
:arrow_up:

...cli-vm/azure/cli/command_modules/vm/_validators.py
68.92% <0%> (+0.35%)
:arrow_up:

...ice/azure/cli/command_modules/appservice/custom.py
73.54% <0%> (+0.37%)
:arrow_up:

.../azure/cli/command_modules/vm/_template_builder.py
77.31% <0%> (+0.51%)
:arrow_up:

...zure-cli-sf/azure/cli/command_modules/sf/custom.py
9.8% <0%> (+0.73%)
:arrow_up:

... and 13 more

Continue to review full report at Codecov.

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


Asset identifier – a standard/universal identifier linked to any proprietary identifiers that users may already use – N   or T.  May be autogenerated if not imported from asset management or other system.

Part of Asset Inventory: Asset Data Requirements

use a lexical key on the identifier so we can integrate
field to be included


[Bug] Create a new bot from scratch

Describe the bug
If you create a new bot today, with "Empty Bot" Template, the Teams Middleware is not working.
You get an error "System.MissingMethodException: 'Method not found: 'Void Microsoft.Bot.Connector.Authentication.MicrosoftAppCredentials"
SDK Version
Microsoft.Bot.Builder.Teams : 4.0.0-beta1
Microsoft.Bot.Builder: 4.2.2
.Net Version
.net core 2.1
Additional context
A workaround solution is to downgrade Microsoft.Bot.Builder to 4.1.1

Looking into this

It's also working with Microsoft.Bot.Builder 4.1.5

Did you see this issue when starting the bot or when the request arrived?

When the request arrived and you try to get the Teams Context.
On this line:
var teamsContext = turnContext.TurnState.Get<ITeamsContext>();

I tried up until 4.2.0 and things are working, 4.2.2 looks like an issue though. We will work on it internally and try to get support for 4.2.2 up soon.

I'm still experiencing this issue. The versions i'm using are the same as stated in the question.
The error appears when I try to add the TeamsMiddleware in Startup.cs, like this:
options.Middleware.Add(new TeamsMiddleware(new ConfigurationCredentialProvider(this.Configuration)));
Even when this is the only thing that references the package.
I tried downgrading the Microsoft.Bot.Builder package to no avail.
The error I'm getting is as follows:

System.MissingMethodException: Method not found: 'Void Microsoft.Bot.Connector.Authentication.MicrosoftAppCredentials..ctor(System.String, System.String)'. at Microsoft.Bot.Builder.Teams.Middlewares.TeamsMiddleware.GetAppCredentialsAsync(String appId) at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine) at Microsoft.Bot.Builder.Teams.Middlewares.TeamsMiddleware.GetAppCredentialsAsync(String appId) at Microsoft.Bot.Builder.Teams.Middlewares.TeamsMiddleware.CreateTeamsConnectorClientAsync(String serviceUrl, ClaimsIdentity claimsIdentity) in D:\a\1\s\CSharp\Microsoft.Bot.Builder.Teams\Middlewares\TeamsMiddleware.cs:line 127 at Microsoft.Bot.Builder.Teams.Middlewares.TeamsMiddleware.OnTurnAsync(ITurnContext context, NextDelegate nextDelegate, CancellationToken cancellationToken) in D:\a\1\s\CSharp\Microsoft.Bot.Builder.Teams\Middlewares\TeamsMiddleware.cs:line 98 at ilxAskBot.Middleware.IntentRecognizerMiddleware.OnTurnAsync(ITurnContext context, NextDelegate nextTurn, CancellationToken cancellationToken) in C:\Users\rhellenthal\source\repos\projectname\projectname\Middleware\IntentRecognizerMiddleware.cs:line 71 at Microsoft.Bot.Builder.MiddlewareSet.ReceiveActivityWithStatusAsync(ITurnContext turnContext, BotCallbackHandler callback, CancellationToken cancellationToken) in D:\a\1\s\libraries\Microsoft.Bot.Builder\MiddlewareSet.cs:line 55 at Microsoft.Bot.Builder.BotAdapter.RunPipelineAsync(ITurnContext turnContext, BotCallbackHandler callback, CancellationToken cancellationToken) in D:\a\1\s\libraries\Microsoft.Bot.Builder\BotAdapter.cs:line 167

Any ideas?

For now please use Bot.Builder version 4.2.0. Once this issue is closed, you can use the latest version.

I'm still getting the error on earlier versions of Bot.Builder, I tried the following versions:

4.2.2
4.2.0
4.1.5
4.1.1

Would you be able to share the repro? I tried with 4.2.0 and was able to get it working.

@rickhellenthal @RamjotSingh it's also working for me with 4.2.0

@RamjotSingh While I was fixing another issue I noticed that the environment that ngrok was referring to was a different one than that he bot was running on. When I changed the 'name' of the endpoint in the .bot file I was able to fixed this.
After this the error message about the missing function disappeared as well, so it is working now.
Thank you for your time!


Move keybindings into an extensionPack extension

For https://github.com/microsoft/vscode-jupyter/issues/7172, https://github.com/microsoft/vscode/issues/106679

Codecov Report

Merging #7173 (4ed3aae) into main (cccf84e) will decrease coverage by 0%.
The diff coverage is n/a.

@@          Coverage Diff          @@
##            main   #7173   +/-   ##
=====================================
- Coverage     64%     64%   -1%
=====================================
  Files        362     362
  Lines      22887   22853   -34
  Branches    3430    3424    -6
=====================================
- Hits       14858   14807   -51
- Misses      6715    6740   +25
+ Partials    1314    1306    -8

Impacted Files
Coverage Δ

...rc/client/datascience/commands/notebookCommands.ts
45% <ø> (+7%)
:arrow_up:

src/client/datascience/constants.ts
99% <ø> (-1%)
:arrow_down:

src/client/datascience/notebook/notebookEditor.ts
38% <ø> (-2%)
:arrow_down:

src/client/datascience/dataScienceSurveyBanner.ts
52% <0%> (-14%)
:arrow_down:

.../datascience/editor-integration/codeLensFactory.ts
53% <0%> (-10%)
:arrow_down:

src/client/terminals/codeExecution/helper.ts
13% <0%> (-6%)
:arrow_down:

src/client/common/application/notebook.ts
78% <0%> (-4%)
:arrow_down:

...datascience/editor-integration/codelensprovider.ts
63% <0%> (-3%)
:arrow_down:

...lient/datascience/jupyter/kernels/cellExecution.ts
66% <0%> (-2%)
:arrow_down:

...ient/datascience/editor-integration/codewatcher.ts
67% <0%> (-1%)
:arrow_down:

... and 13 more

Installed https://github.com/microsoft/vscode-jupyter/suites/3555967044/artifacts/85299554 locally and tested, keymap extension got auto installed correctly, I could disable and uninstall it, and shortcuts worked correctly.


Add Dockerfile

Add Dockerfile to easily build the project as Docker image.
(I will do this and create a PR.)

Hi @jlelse, have you made any progress on this? I already use a Dockerfile locally and am happy to let the community iterate on it. 😊

@hirusi Oh I'm sorry, in the end I didn't choose Indiekit but wrote my own micropub endpoint. So I also have no Dockerfile for Indiekit.

For v0.0.x, a reference Dockerfile is available here.

Once v0.1.0 is published, I will be happy to contribute a starting point for a Dockerfile.

Just saw the notification for the v0.1 release and wanted to drop by for a quick update: I have moved over to WP and at least as of now have no motivation to work on this.
To anyone else who wants to pick this up, please feel free to take this up if you'd like to, fellow interneter.

For anyone needing a sample Docker setup, I've got one in my site's Indiekit repo. Hit me up if you need any help getting it to work (or integrating this into the official project).

@paulrobertlloyd I think my Docker setup is pretty solid. It uses Docker Compose to create a MongoDB server alongside the Indiekit Node server and connects the two up, configuring them with an .env file, a sample of which is provided in the repo.
I could imagine some users would prefer to use third party managed MongoDB hosting and just run the Indiekit server themselves, so I could still make the Indiekit Dockerfile a little more flexible by declaring the environment variables necessary for this (especially MONGO_URL), to prompt the user to provide them.
I'm thinking that npm create indiekit should generate a Dockerfile for the indiekit server itself (which can be provided a MONGO_URL, etc.), and a docker-compose.yml for running Indiekit and a MongoDB server. The documentation should explain how to configure and run both of these setups.

@sentience Glad you got it working. If you wanted to submit a PR to the example config repo, I think that might be a good first step in making a baseline Docker config more widely available.
@thejdev did something similar earlier this year, but that was when the project was using an older configuration file format. Maybe there are some aspects of Jaidev’s PR that could be used?

I'm thinking that npm create indiekit should generate a Dockerfile for the indiekit server itself (which can be provided a MONGO_URL, etc.), and a docker-compose.yml for running Indiekit and a MongoDB server. The documentation should explain how to configure and run both of these setups.

This is an excellent idea! This would be the perfect way to generate the required Docker config files, and I’d like to include this in the final release of v1.0.0. Happy to do this, but if you’d like to submit a PR for that too, I’d be happy to point you in the right direction.

The example config now provides an example Dockerfile and related docker-compose.yml and .dockerignore files.
This means there is at least now some ‘official’ recommendation (though one that I’m happy to update based on feedback). However, given some of the environment values and other factors will vary based on an individual’s Indiekit config, I’m going to keep this issue open until I’ve added the option to create these files as part of the initialisation script.
Hopefully having such functionality will make onboarding with Docker easier, and make writing the tutorials for getting started with different hosting providers a bit easier too!

With the addition of #639, there is now fuller support for Docker.
When it comes to writing tutorials for different hosting platforms, the documentation can recommend using the option to create the various Docker files as part of the configuration and setup. It can also note which is these files is used by those different services (Railway doesn’t yet support Docker Compose, for example).
Thanks again for the suggestion, @sentience.


setCondition not checking character sheet condition box

Using the setCondition function in a macro does not check the box in the character sheet. It does apply the icon and apply debuffs though.
Way to reproduce:
Use below macro:
setCondition-Example.txt
Apply any condition to a player or NPC token, and see the box not check on condition tab.

Simplified macro for testing purposes:
const actor = canvas.tokens.controlled[0].actor;
const hasBleeding = actor.hasCondition("bleeding");
actor.setCondition("bleeding", !hasBleeding);

The setCondition function wasn't actually toggling the data field for the checkboxes. This has been rectified and will be available in the next release. :)

Nice, thanks!


fix: Update to objc2 0.3.0-beta.4; use new icrate bindings

fixes #199
Switching from our own AppKit bindings to the new ones in icrate isn't strictly necessary to fix the bug, but I figured it was a good idea anyway.
@madsmtm Please review.

I will probably reverse the description to pull the AppKit definitions from icrate, due to the substantial increase in compile time. I don't want developers that care about compile time to reject AccessKit. In any case, there's no longer any urgency to this PR, since the dependency on objc2 is now correctly pinned in main.

It looks like this should now update to objc2 version 0.4.x and the current icrate which uses features to control which things are included to keep acceptable compile times.
Is that correct?

Yes, I've known about objc2 0.4.0 for several days but have been putting off working on this.

I'm thinking about doing it this month or next, if you like.

OK, I'll abandon this PR and look forward to your contribution. Thanks!


11214 DEV create new masterIntegration gerritBasicAuth and its fields

https://github.com/Shippable/pm/issues/11214

This is complete.
Closing.


A Problem with the mod

Hello, I have a problem with the mod. When I approach a pet it shows me the message "Something went wrong" but in the chat it shows me the owner of the pet correctly.
Additionally when I right click on a cat it shows me the owner duplicated.
The owner's visualization problem happens to me with all pets.
I attach images of the problem

Thank you very much for your support :)

Sorry for the delay, have been very busy.  So I have a few questions.
First of all, I don't even recognize the message that is in chat, I don't believe it's in any of the translation files. Next question, is this a cracked/non premium server? I ask because the name AlpacunaHot does not show up in the mojang API. If not, does the server have multiple worlds?

Hello, to answer the questions:

I have realized that the chat message is a plugin of the server where I am playing.
The server is not premium, I can provide you with the ip if you want to try the mod on the server.

Thank you very much for your support!

Unfortunately the mod only works on premium servers because it has to get the username from the mojang API. I'll add that to the curseforge page, sorry!


Use TI-Toolkit standard token representations

Heya,
As you know, we're trying to standardize textual token representations; TI-Toolkit strongly advocates for new tools to use the accessible token representations provided in https://github.com/TI-Toolkit/tokens/blob/main/8X.xml while we work behind-the-scenes on other community projects to integrate them.
It's currently unclear what token representations you're using- this is partially a call-to-action to use these new sheets and a request for information on what token representations you've chosen. I was pleasantly surprised to see this made it into linguist, congrats and great work!
~ iPhoenix

The current highlighting is mainly based on SourceCoder, though I've been working on implementing importing / exporting using tivars_lib_cpp and emscripten which I think should use those tokens. I'm not sure exactly where to go from there - to only support the accessible token representations or try to support SourceCoder as well for backwards compatibility with pre-existing source files on GitHub and SourceCoder. What do you think makes the most sense?

I don't believe the current tivars_lib_cpp supports the updated tokens sheets yet, that's a question for @Adriweb
The tokens sheet is mostly backward-compatible with SC3 sheets- and completely backward-compatible for the tokens that people actually use- but considering I hope to get SC3 updated to use these tokens, this will eventually be a moot point. The SC3 sheets are based on an old version of the TokenIDE sheets, and the TI-Toolkit sheets document all extant formats and some new research. Unfortunately, a grammar integrating all the extant formats would be wildly ambiguous; we made an informed choice for the accessible field. There is one note to be made about things like Gray/Grey, though, of which only one is chosen for the accessible field.
It would not be too difficult to only include alternatives that would not ambiguate the grammar, and such a thing would be more general than any of the other options.
I'm firmly of the opinion that the syntax for writing TI-BASIC as plain text should be opinionated and standardized; it's a mess right now and it is difficult to write tools supporting such a mess.

yeah the C++ lib doesn't yet use the new tokens data, it's planned though.
(my opinion about (de)tok would be to use Unicode everywhere but 👀)

I've updated the syntax to now use the accessible formats specified in 8X.xml in a99235c.


cmake: Add new file since 4e7f71dc

Fixes compilation with MediaInfo app.

@tribouille forgot to update the CMakeList.
I forgot to block the PR due to this missing update.
Thanks for remind us about CMake.
We need to add a Travis CI test.


Least/Higher Privilege Swapped

The Least Privileged section of the table is swapped with the Higher Privileged section. Read/Write is higher than Read.

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

ID: fa296054-6c96-8bdb-c170-cbf094f058d5
Version Independent ID: 5e781010-697d-10e9-f448-da588612d590
Content: Get teamworkTag - Microsoft Graph v1.0
Content Source: api-reference/v1.0/api/teamworktag-get.md
Product: microsoft-teams
Technology: microsoft-graph
GitHub Login: @RamjotSingh
Microsoft Alias: MSGraphDocsVteam

Thank you for reporting this, we will check this and update the doc.

Hello @RamjotSingh - Please help to check and update the documentation.

Raised pull request https://github.com/microsoftgraph/microsoft-graph-docs/pull/23343 to update the documents.

PR has been raised to update the doc, changes will reflect in the doc once the PR is merged.

@jbnable , thanks for filing this issue; we have merged the docs PR and the fix will go live today.


HTTP Error 400. The size of the request headers is too long.

I am using IdentityServer4 for SSO purpose. When a user logged in from a browser successfully and then tries to login from other browser then it throws error (Bad Request - Request Too Long). Strange behavior.
Anybody guide me where am I doing wrong.

Are you running behind a proxy (nginx e.g.)

I'm having the same issue. I notice that the number of idsrv session cookies grows on each login. So If all I do is login and logout multiple times, this will end up in me hitting that 400 Error with request header too long. Is this a possible booboo on my end or is this a known issue of some sort? Increasing acceptable header length is not a "fix", that is just moving the problem further down the road. :)

This maybe is a Chrome issue for me. I just found out that Firefox doesn't store these cookies on each login/logout but Chrome does. I changed the setting in chrome where it says "Continue where you left off" when relaunching Chrome to "Open the new tab page" and on next browser close the cookies are all cleared. Before, having already logged out and closed the tab using the service that talks to IDsrv, made no difference - Having "continue where you left off" set is what causes this no matter what.

I notice that the number of idsrv session cookies grows on each login

Might be worth looking in to

If a user does things in Chrome to affect cookies as set by the server, then there's not much I can do to help. I've heard of this setting in chrome -- it also stores cookies on disk even tho the cookie is set as a session cookie (for example if you hibernate/shutdown the OS).
Other than that, it's possible that you're getting not authentication cookies, but OIDC middleware cookies piling up from the client app. If the signin handshake is not completed, then it's possible that nonce cookies are not cleaned up.

Yeah I'm aware theres not much you can do about this being a Chrome issue :D My problem is most people I know use the 'Continue where you left off' setting :(
All I know right now is the cookies are called idsrv.ClientSessions.XXXX... but we'll continue looking into it.
Should IdentityServer destroy these cookies (right now, by design) when the user logs out or is it relying on the browser to do its normal cleanup? Just wondering where to focus my attention on this.

idsrv.ClientSessions.XXXX

Those don't look like authentication cookies -- those look like cookies that are issued to do single signout. Are you letting the "logged out" page render, or are you navigating away from it immediately?

We redirect away from it, maybe it doesn't fully render before redirecting. Is that the problem?

Yes. You need to let it render so all the iframes can complete.

You beautiful specimen

Uhh, thanks?

@siggirh can you give more brief background on this? How you solve it ? Becouse I'am facing the same problem

Our problem was when the user logged out we had a javascript redirect in the logout page where we redirected to our official landing page as soon as the redirect page started loading. We just needed to let the logout page finish rendering (so the iframes load properly and do their thing) and then redirect on a delayed timer.


improve_bfc_allocator

1.Modify the Roundedbytes method
2.Modify the frequently called small methods to make them inline methos

@gbaned I am not familiar with this code. Please add the author of these methods as a reviewer.

@mrry
Can you help to review this code.thanks!

@mrry

@Xuxue1 Could you please check reviewer comments and keep us posted. Thanks!

Hi there. Sorry for the long delay on reviewing this PR. After some internal discussion with @dubey, who works more closely on this part of the code, we've decided that the additional code complexity from the bitwise operations outweighs the performance improvement (which is uncertain, since I'd expect an optimizing compiler to find the same optimization when dividing/multiplying by a constant power of two). Therefore we're going to close this PR without accepting it.
If you can measure a performance difference with and without this change, we'd be open to reconsidering.


Quick Start Example Issue

I tried to create the simplest example possible and I ran across a few issues:

I started with a blank ember new app

I did ember install ember-simple-auth-auth0

I added the route, controller and template code

The lock component loads, and I can login, after a successful login the url contains the JWT
localhost:4200/#access_token=ey...
however I the session doesn't seem to be present in the template and there is an error Error while processing route: index in the console

However, if I refresh the page the session data is displayed. (email address).

If I delete the token from the URL it still works (I imagine because it is now in the store)

(I have now tried this with the latest ember-simple-auth-auth0)
AM I missing something?

@angelosarto I was experiencing the same thing. In app/controllers/application.js I added the responseType attribute to my lockOptions so it looks like:
const lockOptions = {
  auth: {
    params: {
      scope: 'openid user_metadata',
      responseType: 'id_token token',
    }
  }
};

Now it works without the refresh.

None of this is working for me. What im noticing is that auth0 is bubbling up an error saying that the Nonce does not match which is causing the Error while processing route but when I hard refresh the callback route like @angelosarto, it works fine. I've been hunting down the issue all last night, but still have not turned up why this is happening.
seems related to https://github.com/auth0/auth0.js/issues/365 and I saw that @seawatts makes an appearance in the comments, but im also noticing other weird stuff, like the beforeModel hook in the mixin being called twice. In certain cases, the first time its called, it passes verification with the nonce, but then it gets called a second time and the nonce doesn't match, causing an error on the route.
I'm going to continue digging but I'm starting to pull my hair out over the issue. 😢

Okay so I may have been shooting myself in the foot.... although im still a little confused. I moved the mixin to only be on the callback route and that worked. I suppose beforeModel was getting called twice, once when I entered my callback route, and then again when I tried to redirect to my protected route.
This isn't a good solution obviously because it breaks logout. I'm wondering if maybe the applicationroutemixin needs to be changed in this repo 🤔

Alright so I copied the mixin into my project, and added this into the beforeModel right after the promise variable assignment to make it all work. I'm not thrilled about the solution, but it does prevent the beforeModel hook in the mixin from being called twice, and auth is working so :man_shrugging:
if (transition.targetName !== 'auth-callback') { //name of callback route
      return promise;
}

From what I could tell, ESA's sessionAuthenticated() hook is firing, causing a transition into whatever you configure as your routeAfterAuthentication which is causing the beforeModel in the mixin to be fired again.

Is there any official answer on this problem. I find it hard to believe you and I are the only ones with this problem and the fix seems to be a bit over the top for an addon. It doesn't make sense in that way.
Id really like to get more information on why others are not experiencing this issue. This has been a blocker for my home projects for about 3 weeks now. I've essentially given up on Auth0 because of it. @seawatts / @jmar910 can we make any movement on this at all? Hints on possible PRs or better workarounds? Auth0 can't be dead in the water for Ember folks!

Also I think the title should be changed because this isn't a documentation problem it's an ApplicationMixin bug.

@sukima i'm curious, does my workaround work for you? I'd say use that for now, and I'll try to find time to see if i can whip up a real fix. Ive been using it and haven't given it a second thought. it might not be pretty but it holds up.
I am also curious how others are not running into this, or maybe they are and it's not being reported?

Yeah I think the issue is that it is being called twice. I need to fix this.

@seawatts sweet, let me know if i can help

Does the Auth0 JS library offer a promise instead of hijacking the URL?

OK, just been working through this one myself.  The issue seems to occur if a nonce is created by the auth0 lock.js container, which only occurs for me when using a social provider.  If I don't use a social provider, then no nonce is created by auth0, and no nonce checking happens.
The way I worked around this was by modifying the _getNewUrlHashData() method so that it explicitly passes in the window.location.hash object to parseHash, like follows:
    return new Ember.RSVP.Promise((resolve, reject) => {
        auth0.parseHash(window.location.hash, (err, parsedPayload) => {
          if (err) {
            console.log('got an error parsing the harsh', err);
            if (err.errorDescription) {
              err.errorDescription = decodeURI(err.errorDescription);
            }

            return reject(err);
          }

          resolve(parsedPayload);
        });
      });

Once I made that change, auth0 correctly parsed the hash from the url, and as the nonce matches the one created as part of the login process, worked correctly.

I gave up trying and simply used torii to open up my Auth0's OAuth URL. Old school but means I can remove the auth0 lock.js which is not fastboot friendly.

So this Issue makes this addon unusable?

Hi, What I did in order to inspect not to fix beforeModel, I added beforeModel in application route like this:
beforeModel() {
	this._super(...arguments)
},

Strange, but it worked as expected without doing nothing. access_token and other parameters disappeared from url and I was redirected to my good dashboard page.

I took ioanszabo's advice, added 'this' to the parameters, and my nonce mismatch issue went away.
routes/application.js
  beforeModel() {
    this._super.apply(this, ...arguments);
  },

Just as a random update, I was setting up a sample project earlier and ran into this exact issue (as described in the first post). I'll take a look at this as soon as I can, but the immediate priority is cutting a release.

I was having the exact issues everyone else here was having, however after manually clearing my browser local storage, the example app started working as expected.

I am also encountering this. Refreshing when the token stuff is in the URL always makes it break for me. Removing it from the URL works fine. I've tried the proposed fixes, but they won't work for me unfortunately.

If it helps, I get this behavior when trying to use "redirect mode;" using popup mode (archaic as it is) works fine, for folks who find it a feasible workaround (YMMV).


Fixes #6 by adding namespace support

Description

Adding namespace support to run cron function in different k8s namespaces.
Motivation and Context

[x] I have raised an issue to propose this change (required)
[ ] My issue has received approval from the maintainers or lead with the design/approved label

How Has This Been Tested?

See main_test.go.
Also tested manually using jdewinne/cron-connector
Types of changes

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

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Signed-off-by: Joris De Winne<EMAIL_ADDRESS>

@jdewinne there are merge conflicts. Could you please resolve them and squash the commits ?

@viveksyngh I've resolved the merge conflicts. I haven't squashed the commits yet, as I would like your input on the following:

Is there an easier way to handle authentication? See also other comment.
Is the vendor folder needed? Can't we run go mod vendor within the Dockerfile?

:pray:

I have answered 1st question in the comments.
To Answer 2nd question.
Idea is to have migrate all OpenFaaS project to go modules with vendor folder. We will may try to remove vendor/ folder in future but not at the moment.
https://trello.com/c/duCUKQPe/161-migration-to-go-modules-for-all-projects
You can have look at this MR for migrating this to go modules.
https://github.com/openfaas/faas-idler/pull/43
It may be a good idea to separate multiple namespace and go modules migrations in separate PRs

Thanks. I think @alexellis already migrated it to go modules. I was just wondering if the vendor folder is actually needed, as it looks generated.
For the 1st question regarding authentication: I don't see the comment regarding that. Can you post again?

I think this is the right way to with the SDK. What part do you find challenging ?

Yes please run go mod tidy and go mod vendor to update that directory.
This PR also needs to be rebased please, in its current state it can't be merged.

@alexellis @viveksyngh Did the rebase and squashed the commits.

We need a rebase, to move back to Go 1.15 and for @viveksyngh to review again.

One more thing @jdewinne - please edit the PR description and use the PR template - https://raw.githubusercontent.com/openfaas/cron-connector/master/.github/PULL_REQUEST_TEMPLATE.md
Not sure if it was available when you created the PR.

@jdewinne thank you for this PR.
If you find it useful, it may help to change this line:
https://github.com/openfaas/cron-connector/blob/3a5e9c415c2f046690ef360266c8a214b1124fb5/types/scheduler.go#L38
To this:
log.Print(fmt.Sprintf("Executed function: %s (ns=%s)", c.Name, c.Namespace))

Did the rebase and squash again. @viveksyngh can you review?

@viveksyngh @alexellis Made some of the requested changes.


After running run-tye.ps1, I encountered several problems

1、the web-public-gateway service show
Fetch error
Failed to fetch http://administrationService/swagger/v1/swagger.json
Fetch error
Possible mixed-content issue? The page was loaded over https:// but a http:// URL was specified. Check that you are not attempting to load mixed content.
2、the public-web service  log show
System.Threading.Tasks.TaskCanceledException: A task was canceled.
[public-web_83d057e2-6]: [18:32:52 INF] Sending HTTP request GET http://webpublicgateway/api/abp/application-configuration?IncludeLocalizationResources=False&api-version=1.0
[public-web_83d057e2-6]: [18:32:57 ERR] Resilience event occurred. EventName: 'OnTimeout', Source: '-standard//Standard-AttemptTimeout', Operation Key: 'null', Result: 'null'
[public-web_83d057e2-6]: [18:32:57 WRN] Execution attempt. Source: '-standard//Standard-Retry', Operation Key: 'null', Result: 'The operation didn't complete within the allowed timeout of '00:00:10'.', Handled: 'True', Attempt: '0', Execution Time: '10029.0442'
[public-web_83d057e2-6]: Polly.Timeout.TimeoutRejectedException: The operation didn't complete within the allowed timeout of '00:00:10'.
[public-web_83d057e2-6]: ---> System.Threading.Tasks.TaskCanceledException: A task was canceled.
[public-web_83d057e2-6]: at Polly.Retry.AsyncRetryEngine.ImplementationAsync[TResult](Func3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates1 shouldRetryResultPredicates, Func5 onRetryAsync, Int32 permittedRetryCount, IEnumerable1 sleepDurationsEnumerable, Func4 sleepDurationProvider, Boolean continueOnCapturedContext) [public-web_83d057e2-6]: at Polly.AsyncPolicy1.ExecuteAsync(Func3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext) [public-web_83d057e2-6]: at Microsoft.Extensions.Http.PolicyHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) [public-web_83d057e2-6]: at Microsoft.Extensions.ServiceDiscovery.Http.ResolvingHttpDelegatingHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) in /_/src/Microsoft.Extensions.ServiceDiscovery/Http/ResolvingHttpDelegatingHandler.cs:line 53 [public-web_83d057e2-6]: at Microsoft.Extensions.Http.Resilience.ResilienceHandler.<>c.<<SendAsync>b__3_0>d.MoveNext() [public-web_83d057e2-6]: --- End of inner exception stack trace --- [public-web_83d057e2-6]: at Polly.Utils.ExceptionUtilities.TrySetStackTrace[T](T exception) [public-web_83d057e2-6]: at Polly.Timeout.TimeoutResilienceStrategy.ExecuteCore[TResult,TState](Func3 callback, ResilienceContext context, TState state)
[public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s)
[public-web_83d057e2-6]: at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
[public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread)
[public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext()
[public-web_83d057e2-6]: at System.Runtime.CompilerServices.TaskAwaiter.<>c.b__12_0(Action innerContinuation, Task innerTask)
[public-web_83d057e2-6]: at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining)
[public-web_83d057e2-6]: at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
[public-web_83d057e2-6]: at System.Threading.Tasks.Task1.TrySetResult(TResult result) [public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetExistingTaskResult(Task1 task, TResult result) [public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder1.SetResult(TResult result)
[public-web_83d057e2-6]: at Polly.Utils.StrategyHelper.g__AwaitTask|0_0[TResult,TState,T](ValueTask1 task, Boolean continueOnCapturedContext) [public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) [public-web_83d057e2-6]: at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) [public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) [public-web_83d057e2-6]: at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox`1.MoveNext()
[public-web_83d057e2-6]: at System.Runtime.CompilerServices.TaskAwaiter.<>c.b__12_0(Action innerContinuation, Task innerTask)
[public-web_83d057e2-6]: at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining)
[public-web_83d057e2-6]: at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
3、In addition, do I need to do some additional processing for these links http://webpublicgateway? Can it be used normally?

I have the same problem but don't know how to solve it.

Modify the hosts file?


Fix missing cors handler in /api/healthz

Added the CORS middleware to the /api/healthz route
Fix #22718

Should I change the following line as well?
https://github.com/go-gitea/gitea/blob/1e0e79dcbfb21971ac4cd591585672517117d4f0/routers/install/routes.go#L112
If so, how can I reuse the CorsHandler defined in web.go?
https://github.com/go-gitea/gitea/blob/1e0e79dcbfb21971ac4cd591585672517117d4f0/routers/web/web.go#L62

but does this need CORS?

If CORS is enabled in app.ini, no?

But it's not an actual useful endpoint for getting data - it's just for ensuring that the server is up. I don't understand why this would need CORS protection.

So you don't consider #22718 a bug. If so, feel free to close

Yes, I don't consider it a bug either.
I've already been confused why someone would want to spend the time in the first place to open the issue.
CORS specifies where resources might be loaded from.
I don't even know why API requests should receive CORS headers at all.
They only return JSON, so there's nothing to load from somewhere else?
Or am I missing something fundamental?

I think it's better to move this router to routers/api directly.

I think it's better to move this router to routers/api/... directly.

No. The healthz is a de-facto standard endpoint. There is nothing with Gitea's versioned API /api/v1/xxx.

Gotcha, I'll close this then


Security Vulnerability

current "request" node-module is using outdated "qs" version with a security vulnerability as described here: https://nodesecurity.io/advisories/qs_dos_memory_exhaustion.  Requesting update of "request" version to fix the issue.

Version 0.5.0 of this module has been published to npm with a qs dependency >= 1.0.0. Thanks for the report!


Update DEPLOYMENT.md

This PR adds/fixes ...
How to prepare for test:

[ ] ssh to Hasta
[ ] install on stage of Hasta:
bash servers/resources/hasta.sclifelab.se/update-genotype-stage.sh Use-new-generic-update-script

How to test:

[ ] login to ...
[ ] click on ...

Expected test outcome:

[ ] check that ...
[ ] Take a screenshot and attach or copy/paste the output.

Review:

[ ] code approved by
[ ] tests executed by
[ ] "Merge and deploy" approved by
Thanks for filling in who performed the code review and the test!

This version is a:

[ ] MAJOR - when you make incompatible API changes
[ ] MINOR - when you add functionality in a backwards compatible manner
[ ] PATCH - when you make backwards compatible bug fixes or documentation/instructions

Implementation plan:

[ ] Deploy to ...
[ ] Inform to ...

Tested here: https://github.com/Clinical-Genomics/servers/pull/910

θ61° [henrik.stranneheim@hasta:~] [base] 5s $ bash /home/proj/production/servers/resources/hasta.scilifelab.se/update-tool-stage.sh -e S_genotype -t genotype -b Use-new-generic-update-script
Collecting git+https://github.com/Clinical-Genomics/genotype@Use-new-generic-update-script
  Running command git clone --quiet https://github.com/Clinical-Genomics/genotype /home/henrik.stranneheim/tmp/pip-req-build-63l8l2sr
  Cloning https://github.com/Clinical-Genomics/genotype (to revision Use-new-generic-update-script) to ./tmp/pip-req-build-63l8l2sr
  Running command git checkout -b Use-new-generic-update-script --track origin/Use-new-generic-update-script
  Resolved https://github.com/Clinical-Genomics/genotype to commit 2c5ba4864d540433e71503ae549b6efaf3a01f61
  Switched to a new branch 'Use-new-generic-update-script'
  Installing build dependencies: started
  Branch Use-new-generic-update-script set up to track remote branch Use-new-generic-update-script from origin.
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
  Preparing metadata (pyproject.toml): started
  Preparing metadata (pyproject.toml): finished with status 'done'
Building wheels for collected packages: genotype
  Building wheel for genotype (pyproject.toml): started
  Building wheel for genotype (pyproject.toml): finished with status 'done'
  Created wheel for genotype: filename=genotype-4.1.0-py3-none-any.whl size=31299 sha256=1767b019eba6cebfdad0465c262a8576b168fd08c853f2706882762ea40146a2
  Stored in directory: /home/henrik.stranneheim/tmp/pip-ephem-wheel-cache-0mz_j0f4/wheels/b4/bd/1f/de9d4c5659600d3be37b9eb80c14019c93b33ac93df02bdc68
Successfully built genotype
Installing collected packages: genotype
  Attempting uninstall: genotype
    Found existing installation: genotype 4.1.0
    Uninstalling genotype-4.1.0:
      Successfully uninstalled genotype-4.1.0
Successfully installed genotype-4.1.0
Collecting git+https://github.com/Clinical-Genomics/genotype@Use-new-generic-update-script
  Running command git clone --quiet https://github.com/Clinical-Genomics/genotype /home/henrik.stranneheim/tmp/pip-req-build-p0j0gc62
  Cloning https://github.com/Clinical-Genomics/genotype (to revision Use-new-generic-update-script) to ./tmp/pip-req-build-p0j0gc62
  Running command git checkout -b Use-new-generic-update-script --track origin/Use-new-generic-update-script
  Resolved https://github.com/Clinical-Genomics/genotype to commit 2c5ba4864d540433e71503ae549b6efaf3a01f61
  Switched to a new branch 'Use-new-generic-update-script'
  Installing build dependencies: started
  Branch Use-new-generic-update-script set up to track remote branch Use-new-generic-update-script from origin.
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
  Preparing metadata (pyproject.toml): started
  Preparing metadata (pyproject.toml): finished with status 'done'
Requirement already satisfied: pyyaml in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (6.0)
Requirement already satisfied: wheel in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.37.1)
Requirement already satisfied: Flask-SQLAlchemy==2.1 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (2.1)
Requirement already satisfied: xlrd==1.2.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (1.2.0)
Requirement already satisfied: pymysql in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (1.0.2)
Requirement already satisfied: ruamel.yaml in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.17.21)
Requirement already satisfied: Flask-Reverse-Proxy in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (<IP_ADDRESS>)
Requirement already satisfied: Flask-Bootstrap in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (<IP_ADDRESS>)
Requirement already satisfied: gunicorn in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (20.1.0)
Requirement already satisfied: Flask-Alchy in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.5.0)
Requirement already satisfied: cyvcf2 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.30.18)
Requirement already satisfied: Flask-Login==0.5.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.5.0)
Requirement already satisfied: click in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (8.1.3)
Collecting numpy==1.19.2
  Using cached numpy-1.19.2-cp37-cp37m-manylinux2010_x86_64.whl (14.5 MB)
Requirement already satisfied: Flask-Dance==3.0.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (3.0.0)
Requirement already satisfied: markupsafe==1.1.1 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (1.1.1)
Requirement already satisfied: jinja2==2.11.2 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (2.11.2)
Requirement already satisfied: Alchy in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (2.2.2)
Requirement already satisfied: coloredlogs in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (15.0.1)
Requirement already satisfied: itsdangerous==1.1.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (1.1.0)
Requirement already satisfied: cython in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.29.32)
Requirement already satisfied: Flask-Security in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (3.0.0)
Requirement already satisfied: SQLAlchemy<1.4 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (1.3.24)
Requirement already satisfied: werkzeug<1.0.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.16.1)
Requirement already satisfied: Flask==1.1.1 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (1.1.1)
Requirement already satisfied: pysam in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from genotype==4.1.0) (0.19.1)
Requirement already satisfied: urlobject in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.0) (2.4.3)
Requirement already satisfied: six in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.0) (1.16.0)
Requirement already satisfied: requests-oauthlib>=1.0.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.0) (1.3.1)
Requirement already satisfied: oauthlib in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.0) (3.2.0)
Requirement already satisfied: requests>=2.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.0) (2.28.1)
Requirement already satisfied: importlib-metadata in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from click->genotype==4.1.0) (5.0.0)
Requirement already satisfied: pydash>=3.4.7 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Alchy->genotype==4.1.0) (5.1.0)
Requirement already satisfied: humanfriendly>=9.1 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from coloredlogs->genotype==4.1.0) (10.0)
Requirement already satisfied: dominate in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Bootstrap->genotype==4.1.0) (2.7.0)
Requirement already satisfied: visitor in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Bootstrap->genotype==4.1.0) (0.1.3)
Requirement already satisfied: passlib>=1.7 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.0) (1.7.4)
Requirement already satisfied: Flask-BabelEx>=0.9.3 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.0) (0.9.4)
Requirement already satisfied: Flask-WTF>=0.13.1 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.0) (1.0.1)
Requirement already satisfied: Flask-Principal>=0.3.3 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.0) (0.4.0)
Requirement already satisfied: Flask-Mail>=0.7.3 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.0) (0.9.1)
Requirement already satisfied: setuptools>=3.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from gunicorn->genotype==4.1.0) (65.3.0)
Requirement already satisfied: ruamel.yaml.clib>=0.2.6 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from ruamel.yaml->genotype==4.1.0) (0.2.6)
Requirement already satisfied: Babel>=1.0 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-BabelEx>=0.9.3->Flask-Security->genotype==4.1.0) (2.10.3)
Requirement already satisfied: speaklater>=1.2 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-BabelEx>=0.9.3->Flask-Security->genotype==4.1.0) (1.3)
Requirement already satisfied: blinker in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-Mail>=0.7.3->Flask-Security->genotype==4.1.0) (1.5)
Requirement already satisfied: WTForms in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Flask-WTF>=0.13.1->Flask-Security->genotype==4.1.0) (3.0.1)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.0) (1.26.12)
Requirement already satisfied: charset-normalizer<3,>=2 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.0) (2.1.1)
Requirement already satisfied: certifi>=2017.4.17 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.0) (2022.6.15)
Requirement already satisfied: idna<4,>=2.5 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.0) (3.3)
Requirement already satisfied: zipp>=0.5 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from importlib-metadata->click->genotype==4.1.0) (3.10.0)
Requirement already satisfied: typing-extensions>=3.6.4 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from importlib-metadata->click->genotype==4.1.0) (4.4.0)
Requirement already satisfied: pytz>=2015.7 in /home/proj/stage/bin/miniconda3/envs/S_genotype/lib/python3.7/site-packages (from Babel>=1.0->Flask-BabelEx>=0.9.3->Flask-Security->genotype==4.1.0) (2022.2.1)
Installing collected packages: numpy
  Attempting uninstall: numpy
    Found existing installation: numpy 1.21.6
    Uninstalling numpy-1.21.6:
      Successfully uninstalled numpy-1.21.6
Successfully installed numpy-1.19.2
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
repository is clean
Logging deploy ...
Getting deployer... done.
Getting last commit message and SHA... done.
Getting version of deploy scripts... /home/henrik.stranneheim
done.
Log deploy... done.
θ64° [henrik.stranneheim@hasta:~] [base] 1m34s $ which genotype
alias genotype='/home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml'
	/home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype
θ64° [henrik.stranneheim@hasta:~] [base] $ gentype --version
bash: gentype: command not found...
θ60° [henrik.stranneheim@hasta:~] [base] 127 $ genotype --version
genotype, version 4.1.0
θ63° [henrik.stranneheim@hasta:~] [base] 5s $ genotype --help
Usage: genotype [OPTIONS] COMMAND [ARGS]...

  Interact with genotype comparison tool.

Options:
  -c, --config PATH     path to config file
  -d, --database TEXT   path/URI of the SQL database
  -l, --log-level TEXT
  --log-file PATH
  --version             Show the version and exit.
  --help                Show this message and exit.

Commands:
  add-sex                 Add sex determination to samples and analyses.
  check                   Check integrity of a sample.
  delete                  Delete analyses and samples from the database.
  delete-user             Delete user from the database.
  export-sample           Gets data for samples from the sample table,...
  export-sample-analysis  Gets analysis data for samples from the...
  init                    Setup a new Genotype database.
  list-users              List users from the database.
  load                    Load data from genotype resources.
  ls                      List samples from the database.
  match                   Match genotypes for an analysis against all...
  sample                  Get a sample from the database.
  serve                   Start up the web interface.
  snps                    Export the snp definitions
  view                    View added genotypes for all analyses of a sample.

Upload ✅
θ65° [henrik.stranneheim@hasta:~] [base] 24s $ cg upload genotypes justhusky
/home/proj/stage/bin/miniconda3/envs/S_main/lib/python3.7/site-packages/sqlalchemy/orm/relationships.py:2231: SAWarning: Cascade settings "delete, merge, save-update" should not be combined with a viewonly=True relationship.   This configuration will raise an error in version 1.4.  Note that in versions prior to 1.4, these cascade settings may still produce a mutating effect even though this relationship is marked as viewonly=True.
  "viewonly=True." % (", ".join(sorted(non_viewonly)))
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
Called undefined __fields__ on HousekeeperAPI, please wrap
----------------- UPLOAD -----------------
----------------- GENOTYPES -------------------
/home/proj/stage/bin/miniconda3/envs/S_main/lib/python3.7/site-packages/sqlalchemy/orm/relationships.py:1998: SAWarning: Setting backref / back_populates on relationship Demux.samples to refer to viewonly relationship Sample.demuxes should include sync_backref=False set on the Demux.samples relationship.  (this warning may be suppressed after 10 occurrences)
  (rel_b, rel_a, rel_b),
/home/proj/stage/bin/miniconda3/envs/S_main/lib/python3.7/site-packages/sqlalchemy/orm/relationships.py:1998: SAWarning: Setting backref / back_populates on relationship Sample.demuxes to refer to viewonly relationship Demux.samples should include sync_backref=False set on the Sample.demuxes relationship.  (this warning may be suppressed after 10 occurrences)
  (rel_b, rel_a, rel_b),
Initializing UploadGenotypesAPI
Fetching upload genotype data for justhusky
Fetch latest version from bundle justhusky
Fetching files with tags in [genotype]
Fetching files from version 111220
Fetching files with tags in [qc-metrics,deliverable]
Fetching files from version 111220
loading VCF genotypes for sample(s): earlycasualcaiman, slowlycivilbuck, hugelymodelbat
Running command /home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml load /home/proj/stage/housekeeper-bundles/justhusky/2022-09-22/justhusky_gatkcomb.bcf
Running command /home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml add-sex earlycasualcaiman -s male
Running command /home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml add-sex earlycasualcaiman -a sequence male
Running command /home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml add-sex slowlycivilbuck -s female
Running command /home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml add-sex slowlycivilbuck -a sequence female
Running command /home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml add-sex hugelymodelbat -s male
Running command /home/proj/stage/bin/miniconda3/envs/S_genotype/bin/genotype --config /home/proj/stage/servers/config/hasta.scilifelab.se/genotype-stage.yaml add-sex hugelymodelbat -a sequence male

Deployed on Hasta:
θ71° [henrik.stranneheim@hasta:~] [P_main] $ bash /home/proj/production/servers/resources/hasta.scilifelab.se/update-genotype-prod.sh
on the host hasta.scilifelab.se, continue
Collecting git+https://github.com/clinical-genomics/genotype@master
  Cloning https://github.com/clinical-genomics/genotype (to revision master) to ./tmp/pip-req-build-k4_oyj6b
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: genotype
  Building wheel for genotype (PEP 517) ... done
  Created wheel for genotype: filename=genotype-4.1.1-py3-none-any.whl size=31298 sha256=6ec16b752159fb063a4b736926f32638972b35e9d9035028b29b32c286ca028f
  Stored in directory: /home/henrik.stranneheim/tmp/pip-ephem-wheel-cache-dm2j4qzf/wheels/63/d7/38/2d616f160ea626015965a94d5e26e4288d169a24a3f5151da1
Successfully built genotype
Installing collected packages: genotype
  Attempting uninstall: genotype
    Found existing installation: genotype 4.1.0
    Uninstalling genotype-4.1.0:
      Successfully uninstalled genotype-4.1.0
Successfully installed genotype-4.1.1
Collecting git+https://github.com/clinical-genomics/genotype@master
  Cloning https://github.com/clinical-genomics/genotype (to revision master) to ./tmp/pip-req-build-qm_qku_u
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Requirement already satisfied, skipping upgrade: pyyaml in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (5.3.1)
Requirement already satisfied, skipping upgrade: ruamel.yaml in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.16.12)
Requirement already satisfied, skipping upgrade: xlrd==1.2.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (1.2.0)
Requirement already satisfied, skipping upgrade: Flask-Login==0.5.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.5.0)
Requirement already satisfied, skipping upgrade: gunicorn in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (20.1.0)
Requirement already satisfied, skipping upgrade: Flask-Security in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (3.0.0)
Requirement already satisfied, skipping upgrade: SQLAlchemy<1.4 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (1.3.19)
Requirement already satisfied, skipping upgrade: pymysql in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.10.1)
Requirement already satisfied, skipping upgrade: Flask-Alchy in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.5.0)
Requirement already satisfied, skipping upgrade: wheel in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.35.1)
Requirement already satisfied, skipping upgrade: Flask==1.1.1 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (1.1.1)
Requirement already satisfied, skipping upgrade: cython in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.29.21)
Requirement already satisfied, skipping upgrade: itsdangerous==1.1.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (1.1.0)
Requirement already satisfied, skipping upgrade: jinja2==2.11.2 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (2.11.2)
Requirement already satisfied, skipping upgrade: Alchy in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (2.2.2)
Requirement already satisfied, skipping upgrade: markupsafe==1.1.1 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (1.1.1)
Requirement already satisfied, skipping upgrade: click in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (7.1.2)
Requirement already satisfied, skipping upgrade: cyvcf2 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.9.0)
Requirement already satisfied, skipping upgrade: werkzeug<1.0.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.16.1)
Requirement already satisfied, skipping upgrade: Flask-Dance==3.0.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (3.0.0)
Requirement already satisfied, skipping upgrade: pysam in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (0.15.2)
Requirement already satisfied, skipping upgrade: coloredlogs in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (14.0)
Requirement already satisfied, skipping upgrade: Flask-Reverse-Proxy in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (<IP_ADDRESS>)
Requirement already satisfied, skipping upgrade: numpy==1.19.2 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (1.19.2)
Requirement already satisfied, skipping upgrade: Flask-Bootstrap in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (<IP_ADDRESS>)
Requirement already satisfied, skipping upgrade: Flask-SQLAlchemy==2.1 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from genotype==4.1.1) (2.1)
Requirement already satisfied, skipping upgrade: ruamel.yaml.clib>=0.1.2; platform_python_implementation == "CPython" and python_version < "3.9" in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from ruamel.yaml->genotype==4.1.1) (0.2.2)
Requirement already satisfied, skipping upgrade: setuptools>=3.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from gunicorn->genotype==4.1.1) (49.6.0.post20200814)
Requirement already satisfied, skipping upgrade: Flask-BabelEx>=0.9.3 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.1) (0.9.4)
Requirement already satisfied, skipping upgrade: Flask-Principal>=0.3.3 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.1) (0.4.0)
Requirement already satisfied, skipping upgrade: passlib>=1.7 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.1) (1.7.2)
Requirement already satisfied, skipping upgrade: Flask-WTF>=0.13.1 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.1) (0.14.3)
Requirement already satisfied, skipping upgrade: Flask-Mail>=0.7.3 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Security->genotype==4.1.1) (0.9.1)
Requirement already satisfied, skipping upgrade: pydash>=3.4.7 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Alchy->genotype==4.1.1) (4.8.0)
Requirement already satisfied, skipping upgrade: six in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.1) (1.15.0)
Requirement already satisfied, skipping upgrade: oauthlib in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.1) (3.1.0)
Requirement already satisfied, skipping upgrade: requests>=2.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.1) (2.24.0)
Requirement already satisfied, skipping upgrade: urlobject in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.1) (2.4.3)
Requirement already satisfied, skipping upgrade: requests-oauthlib>=1.0.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Dance==3.0.0->genotype==4.1.1) (1.3.0)
Requirement already satisfied, skipping upgrade: humanfriendly>=7.1 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from coloredlogs->genotype==4.1.1) (8.2)
Requirement already satisfied, skipping upgrade: visitor in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Bootstrap->genotype==4.1.1) (0.1.3)
Requirement already satisfied, skipping upgrade: dominate in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Bootstrap->genotype==4.1.1) (2.5.2)
Requirement already satisfied, skipping upgrade: speaklater>=1.2 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-BabelEx>=0.9.3->Flask-Security->genotype==4.1.1) (1.3)
Requirement already satisfied, skipping upgrade: Babel>=1.0 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-BabelEx>=0.9.3->Flask-Security->genotype==4.1.1) (2.8.0)
Requirement already satisfied, skipping upgrade: blinker in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-Principal>=0.3.3->Flask-Security->genotype==4.1.1) (1.4)
Requirement already satisfied, skipping upgrade: WTForms in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Flask-WTF>=0.13.1->Flask-Security->genotype==4.1.1) (2.3.3)
Requirement already satisfied, skipping upgrade: chardet<4,>=3.0.2 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.1) (3.0.4)
Requirement already satisfied, skipping upgrade: certifi>=2017.4.17 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.1) (2020.6.20)
Requirement already satisfied, skipping upgrade: idna<3,>=2.5 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.1) (2.10)
Requirement already satisfied, skipping upgrade: urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from requests>=2.0->Flask-Dance==3.0.0->genotype==4.1.1) (1.25.10)
Requirement already satisfied, skipping upgrade: pytz>=2015.7 in /home/proj/bin/conda/envs/P_genotype/lib/python3.7/site-packages (from Babel>=1.0->Flask-BabelEx>=0.9.3->Flask-Security->genotype==4.1.1) (2020.1)
Building wheels for collected packages: genotype
  Building wheel for genotype (PEP 517) ... done
  Created wheel for genotype: filename=genotype-4.1.1-py3-none-any.whl size=31298 sha256=355b92d7302841cfc4b014a2075aef6ab8fe5f28fc483d2a1126ff8064ef63ee
  Stored in directory: /home/henrik.stranneheim/tmp/pip-ephem-wheel-cache-zyc_hqle/wheels/63/d7/38/2d616f160ea626015965a94d5e26e4288d169a24a3f5151da1
Successfully built genotype
Installing collected packages: genotype
  Attempting uninstall: genotype
    Found existing installation: genotype 4.1.1
    Uninstalling genotype-4.1.1:
      Successfully uninstalled genotype-4.1.1
Successfully installed genotype-4.1.1
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
repository is clean
Logging deploy ...
Getting deployer... done.
Getting last commit message and SHA... done.
Getting version of deploy scripts... /home/henrik.stranneheim
done.
Log deploy... done.
No broken requirements found.
genotype, version 4.1.1


[SPARK-14520][SQL] Use correct return type in VectorizedParquetInputFormat

What changes were proposed in this pull request?
JIRA: https://issues.apache.org/jira/browse/SPARK-14520
VectorizedParquetInputFormat inherits ParquetInputFormat and overrides createRecordReader. However, its overridden createRecordReader returns a ParquetRecordReader. It should return a RecordReader. Otherwise, ClassCastException will be thrown.
How was this patch tested?
Existing tests.

cc @nongli

Test build #55504 has started for PR 12292 at commit 961f117.

Test build #55504 has finished for PR 12292 at commit 961f117.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/55504/
Test PASSed.

Merged build finished. Test PASSed.

LGTM

cc @rxin

Thanks - merging in master.