Ability to specify a different stderr path

I have some tests that are generated in a build script.
They are run like so:
#[test]
fn ui() {
    let t = trybuild::TestCases::new();
    t.compile_fail(concat!(env!("OUT_DIR"), "/tests/*.rs"));
}

This however results in the *.stderr files being located somewhere in the env!(OUT_DIR) directory, which isn't commited into source control.
Now tests for which the output isn't commited into source control are pretty useless, so it would be nice to be able to do something like this:
#[test]
fn ui() {
    let t = trybuild::TestCases::new();
    t.compile_fail_with_stderr_dir("tests/ui/*.rs", "tests/ui/stderr");
}

Or maybe to allow for other additions in the future without having to add a new function for every addition:
#[test]
fn ui() {
    let t = trybuild::TestCases::new();
    t.compile_fail_with_options("tests/ui/*.rs", trybuild::TestOptions {
        stderr_dir: "tests/ui/stderr",
        ..Default::default()
    });
}

I would be willing to write a PR for either version, if you'd accept it.

I think I would prefer not to make a change for this, but some reasonable options would be:

Maintain this functionality in a fork
Make build script copy the stderr files to out dir, make test copy stderr files back if run with TRYBUILD=overwrite

Thanks, you gave me an idea.
In case anyone is curious and has a similar issue, this is what I came up with:
/// The variable, which enables writing of the tests in the source directory.
///
/// This is explicitly opt-in, because the cargo documentation states
///
/// > In general, build scripts should not modify any files outside of OUT_DIR.
/// > It may seem fine on the first blush, but it does cause problems when you use such crate as a
/// > dependency, because there's an implicit invariant that sources in `.cargo/registry` should be
/// > immutable. cargo won't allow such scripts when packaging.
///
/// However it should be noted, that trybuild with it's `TRYBUILD=overwrite` setting behaves in a
/// similar fashion, so it should be ok.
const MUTABLE_SOURCE_VARIABLE: &'static str = "GENERATE_TESTS";

println!("cargo:rerun-if-env-changed={}", MUTABLE_SOURCE_VARIABLE);

if let Ok(mut val) = std::env::var(MUTABLE_SOURCE_VARIABLE) {
    val.make_ascii_lowercase();
    if val == "yes" || val == "true" || val == "1" {
        generate_tests();
    }
}


Explicit support for Windows 10 Enterprise

Docker for Windows now supports Windows 10 Enterprise. We should be able to support it just fine if docker runs predictably there.

Test it out (we need to obtain WIndows Enterprise; can do that on an internet/test machine I think)
Update docs to reflect that we support it, add any necessary changes.

It looks like the Win 10 Enterprice 90-day eval download is free, https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise
And it's like $84/year/user, which we could also afford for eval, even though we don't really need it.

Yay, I'm running Win 10 Enterprise on Azure, and with Docker-for-windows it works fine. I'm pretty sure we can say that any Windows instance that will run Docker-for-Windows (Currently Win 10 Pro/Enterprise/Education) will work with ddev.
Also, since we can now support Docker Toolbox, people can really run Docker Toolbox on many different versions of Windows, including Home and Server. Probably Win 7 and 8 (any place Virtualbox will run).
Final steps for this one are just fixing the docs to not be so tight about Win 10 Pro.

We can add this little bit of docs to v0.20.0, this is working fine already.


Suggestion: Custom Type for ID and URI

The Problem
While beginning to work with the API, I stumbled several times over the fact that there are various ways of identifying an account:

an ID such as<PHONE_NUMBER>92335026
a URI such as<EMAIL_ADDRESS>there's also the acct but I'll ignore that for now

Both ID and URI are just string types right now. This leads to confusion when plugging an ID into a function that requires a URI and vice versa. There is no check against doing such a thing, because the Swift types are the same. Only during runtime will users encounter various 404 not found errors presented to them as exceptions.
Seemingly random exceptions are not very user friendly, and having to thing about what "kind" the string I'm passing around is, is not very Swifty. It decreases the enjoyment and ease of use of TootSDK (not by a lot, but somewhat).
The Proposal: Create a type AccountID and a type AccountURI
I think it would be very helpful if ID and URI were their own types.

It would prevent developers from accidentally passing one type into functions that require the other, preventing a whole class of exceptions from occurring.
It would allow documentation for the types, where the difference and finer points can be explained, allowing for easier onboarding.
It would reduce mental overhead when using the API, because developers would not have to keep in mind the different types of String they are passing around.
Depending on implementation, there could even be error checking and normalization, such as normalizing<EMAIL_ADDRESS>and https://social.telemetrydeck.com/@daniel to<EMAIL_ADDRESS>This can make the library even more user friendly, and is also helpful to apps that use it, because error checking and normalization happens at the library level instead of the app level.

The Implementation
Depending on how much effort we want to put into this, I can envision one of these strategies for implementation:
Strategy 1: Type Aliases
This is an implementation strategy that isn't much work but would yield the most important of the benefits by clearly marking functions regarding the kind of identifier they require, and keeping track of the type an identifier is. It also allows for documenting the type alias, so additional explanation can be given to developers at the code and code completion level regarding what is expected of them.
It is also very easy to implement because no functions would actually change their signature, and no client code would have to change its signature either.
The downside is that developers could still pass one type into functions that require the other without much warning. Also there is not a lot of semantics and no validity checking at all.
Strategy 2: StringProtocol Conformance
This strategy would try as much as possible to prevent code that depends on the affected types and functions to be rewritten. To this end it would create two new types that store semantic information about their content but try to present as much as a string to the outside world as possible, using conformance to the ExpressibleByStringLiteral and CustomStringConvertible protocols.
This adds all the semantics and validation checking, which is poggers.
Here's a sketch of an example:
public struct AccountURI: ExpressibleByStringLiteral, CustomStringConvertible {
    let domain: String
    let acct: String

    // normal initializer
    public init(acct: String, domain: String) {
        self.acct = acct
        self.domain = domain
    }

    // conformance to ExpressibleByStringLiteral
    public init(stringLiteral value: String) {
        // actual implementation here could
        // check for various representations
        // and extract the correct data, or throw
        let parts = value.split(separator: "@")
        self.acct = String(parts.first)
        self.domain = String(parts.last)
    }

    // conformance to CustomStringConvertible
    public var description: String {
        return "@\(acct)@\(domain)"
    }
}
let myAccount: AccountURI = "<EMAIL_ADDRESS>print(myAccount) // "<EMAIL_ADDRESS>
The main downside is that even with ExpressibleByStringLiteral and CustomStringConvertible, this strategy would still break people's code somewhat, and it is trying to do an awful lot of magic which might be confusing in the long run.
Strategy 3: Just break it all and go for proper structs
This strategy is the most disruptive. It would create new structs for URI and ID, same as Strategy 2, but not go for any conformance with pre-existing APIs. Code will just break and people would have to deal with it.

@winsmith this is an excellent write-up.
I agree that TootSDK should solve this for devs, especially when deciding which “identifier” to provide is usually unclear from the docs and also more confusing when you consider that different server types have different expectations. For example (plot twist), Pleroma /api/v1/accounts/:id and /api/v1/accounts/:id/statuses accept both ID and nickname!
From the listed options, I like options 2 (ExpressibleByStringLiteral, CustomStringConvertible) and 3 (proper struct) the most.
Pre-v1, we are not really looking for total API stability, especially when the gains are significant, which I think they are in this case. What I like is that in both options is that we get a proper struct, so we can implement flavour checks inside it, so we can handle any server-specific implementations.
For example, func getAccount(by id: AccountID) and an overload func getAccount(by nickname: AccountNickname) where in the latter, we can detect whether the flavour is Pleroma or not and resolve the nickname to an ID.
Another aspect I really like is that we can introduce a more refined naming for these parameters that's unified across server types (so the entire TootSDK will refer to AccountID and AccountNickname, AccountURI etc. We did a similar "unification" with the term Post for example (so you don't see a mix of post/toot/status).

Yup, what I really want is for the app not to have to care too much about this. I think option 2 with a few bit stops smooth things out, probably gets us there. Like @kkostov I don't care at this stage about breaking API stability, if it means we get something really good out of it!

Aight, I'll draft up a more refined suggestion! Thanks for your feedback!


Add docs for IndexVal and QN ITensor constructors

This adds documentation for IndexVal and various QN ITensor constructors.
In the process, it also made me start to think about some of the QN ITensor constructors, so this is a work in progress.

Codecov Report

Merging #348 into master will decrease coverage by 0.58%.
The diff coverage is 77.87%.

@@            Coverage Diff             @@
##           master     #348      +/-   ##
==========================================
- Coverage   86.01%   85.42%   -0.59%
==========================================
  Files          36       36
  Lines        3089     3102      +13
==========================================
- Hits         2657     2650       -7
- Misses        432      452      +20

Impacted Files
Coverage Δ

src/ITensors.jl
100.00% <ø> (ø)

src/qn/qnindex.jl
64.83% <ø> (ø)

src/qn/qnitensor.jl
56.25% <38.70%> (-30.24%)
:arrow_down:

src/itensor.jl
75.93% <70.58%> (-0.69%)
:arrow_down:

src/index.jl
76.00% <75.00%> (-0.77%)
:arrow_down:

src/mps/mpo.jl
98.12% <100.00%> (ø)

src/mps/mps.jl
95.88% <100.00%> (+0.02%)
:arrow_up:

src/physics/autompo.jl
91.68% <100.00%> (ø)

src/physics/site_types/electron.jl
81.45% <100.00%> (-0.15%)
:arrow_down:

src/physics/site_types/fermion.jl
90.47% <100.00%> (-0.23%)
:arrow_down:

... and 5 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 1a1d24f...506663f. Read the comment docs.

In the latest version of this PR, I've implemented the change proposed in #349.
This change meant that certain uses of ITensor(::QNIndex...) as an uninitialized ITensor was no longer valid. I introduced an initial version of zeroITensor(::Index...) which for QN indices it creates a BlockSparse storage without any blocks, and for non-QN indices it makes a Dense storage filled with zeros. This is in preparation for introducing a Zero storage.
I've also simplified and unified the ITensor constructor docstrings.

In that latest, I changed the name of zeroITensor to emptyITensor. emptyITensor still just constructs ITensors with Dense or BlockSparse storage (filled with zeros and with no blocks, respectively). We still need to create an Empty storage type in NDTensors, though I am waiting for the NDTensors package to get registered and will add it in that new package.

I've added an initial version for an emptyITensor() constructor. It is a little bit tricky, but it creates an ITensor of type ITensor{Any} with an IndexSet of type IndexSet{Any, Union{}, Tuple{}. This ITensor type is only used for the following case:
A = emptyITensor()
for i in 1:10
  A += randomITensor(i, j)
end

Making it type ITensor{Any} is meant to emphasize that it is quite a special ITensor, and the interpretation is that it can take on "any" order, based on the context (like addition).
I also realized with the current design where the ITensor type is parametrized by the order, this is not possible:
A = emptyITensor()
A[i => 1, j => 2] = 2.0  # This would give the ITensor A the indices (i, j)

since it would require changing the ITensor's type in-place (from type ITensor{Any} or whatever it is initially to type ITensor{2}). I don't think this is a big loss, since setting elements requires that you have access to the indices to begin with, so we can just require that you do:
A = emptyITensor(i, j)
A[i => 1, j => 2] = 2.0

Also the current version is failing because of an issue in NDTensors (https://github.com/ITensor/NDTensors.jl/issues/3). NDTensors just got registered and I would prefer to fix that issue there instead of in the ITensors version. I may go ahead and remove the NDTensors module in this PR and add it as a dependency, so then the fix over there can be used here (and also we can use the Empty storage type being developed over there).

Good to see how this is progressing. That’s too bad about the inability to infer the indices from setindex!, but I agree it’s not a big loss. The tradeoff of having the tensor order in the type definitely pays some dividends in other places.
That would be neat if you could go ahead and finish splitting off NDTensors in this PR, since I saw it’s now registered. (Congrats!) I’m not sure if that’s a rather easy thing to do, or pretty complicated.

Also, just to clarify, the other use of emptyITensor besides for summations is for optimizing code, correct? Like where you don't want to allocate any memory because the code immediately after will start changing the tensor anyway?

The other use case besides addition is what you said, and more generally having a generic way to create an uninitialized ITensor of any type. Basically, with the current design ITensor(i, i') for QN indices makes an ITensor of type Float64 with flux QN(), so emptyITensor(i, i') would be the canonical way to create an ITensor with no blocks and undefined flux, where the flux gets determined once elements are set. So it basically is interpreted as an ITensor with the specified indices, but no storage yet. So the main use case is in functions like op where you want a generic way to initialize the ITensor at the beginning.
I am still deciding on some design choices, like if you call getindex on and emptyITensor, does it return 0.0? I think we want to treat it as an additive zero, so I would say yes, but for now I'll only define setindex!.

In the latest few commits, I removed the NDTensors module from ITensors.jl and added NDTensors.jl as a dependency. I set the compat version of NDTensors up to v0.1.1 since this PR is now using the Empty storage type which I introduced in NDTensors v0.1.1 (and is the latest registered version of that package).
This branch is ready to go, as long as we are good with the interface for emptyITensor. In the latest version, the current syntax for constructing an ITensor with Empty storage and Any number of indices is:
A = emptyITensor(Any)
order(A) == Any
# A[] = 2.0  # This would fail
i = Index(2)
for _ in 1:4
  A += randomITensor(i, i')
end

The Any represents that it is making an ITensor with Any number of indices. The reason I picked that interface was to distinguish between that usage of emptyITensor and creating an ITensor with Empty storage of order 0 (i.e. 0 indices, instead of Any number of indices). For example:
A = emptyITensor()
order(A) == 0
# A + randomITensor(i, i') # This fails, since they have different numbers of indices
A[] = 2.0  # Creates a scalar ITensor (which has Dense storage of length 1)

My reasoning is that an emptyITensor(Any) has quite exotic behavior and I expect will have very narrow use cases, so I wanted to make that very clear. Perhaps it is a strange abuse of notation, however.

Great. I think this design makes sense, because it differentiates between the case of just wanting to delay creating an expensive storage (this is the use case I foresee for emptyITensor(i,i’); are there others?) versus wanting the kind of “Any” behavior.
For people who want to be lazy about typing empyITensor(Any), we could make an alias
anyITensor() = emptyITensor(Any)

Only half-joking!
The only other thing I’d want to be sure about is whether using the Any type creates some kind of inefficiency with Julia’s type system or something like that. But I doubt it does in this case; I guess it mainly just defines another type of ITensor, alongside ITensor{0}, ITensor{1}, etc.

I can't think of other uses of emptyITensor(i, i') besides a generic constructor where you don't know information about the storage you want yet (i.e. the element type or quantum number flux).
Another alias we could use for emptyITensor(Any) could be ITensor{Any}() (very similar to your suggestion anyITensor()). Additionally, we could consider defining ITensor{3}() as a way to create an ITensor with Empty storage of order 3 where you don't know what the indices are yet (or alternatively emptyITensor(Val{3})). I just realized this could allow us to get around the in-place operations limitation I had mentioned, for example this would work:
A = ITensor{2}() # ITensor with Empty storage and 2 unspecified indices
i = Index(2)
A[i => 1, i' => 2] = 2.5   # This makes an ITensor with indices (i, i')

Also, this would allow us to do loops with in-place addition, where you don't want to specify the indices beforehand:
A = ITensor{3}()
i = Index(2)
for _ in 1:5
  A .+= randomITensor(i,i',i'')
end

which wouldn't be possible starting from an emptyITensor(Any)/ITensor{Any}(). Just some food for thought, no rush to add it right now.
I was also wondering if there are any efficiency issues. I believe just using Any as a type parameter should be no different from using a number (or any other type) as a type parameter, since it is used purely as a type parameter for dispatch and the storage of the IndexSet is not abstract (if you look at the new definition of the IndexSet type you can see what I mean by that). If it is purely used as a type parameter, then it is just used in dispatch and I think is even treated as a "concrete" type, i.e.:
julia> isconcretetype(Any)
false

julia> struct T{N} end

julia> isconcretetype(T{Any})
true

An alternative is that we could make our own simple internal type struct AnyOrder end for this purpose instead of using Julia's Any. But Any already represents a very similar concept to what we are using it here for, i.e. it is like ITensor{<:Any} = ITensor{N} where {N<:Any}. However, that is an abstract type, so you can't make an instance of an ITensor of that type so the closest you can get is the type ITensor{Any}.


Zhaoyu/doc

the doc for etcd service.

It's better add dependency introduction to tell user which service use etcd (The service dependency).

sure, add a new section to describe the data store on etcd. done


Update README.md

I resolved conflict and I’m gonna merge this PR.
Thank you for your contribution :)


Build boost and openssl libraries for Android

Added new repos:

https://github.com/BeamMW/boost-android.git
https://github.com/BeamMW/openssl-android.git

They were integrated to beam builder for android.

checked


Finalize UG v1.2

Summary

Finalize User Guide, some changes in format to make them uniform, Resolves #49
Resolve the bug that TOC not working, Resolves #73

Detail

some parameter format change, including how to add patient
some minor comment changes in the tagging
change all optional parameter using [OPTIONAL_PARAMETER]
change all flags into parameters (naming)

Checks

[x] Link PR to issue
[x] Add Reviewer
[ ] Pass CI

The section on suggestions and help looks fine, ill get round to fleshing it out with mockups later. Waiting on the rest to check their parts.

The section on suggestions and help looks fine, ill get round to fleshing it out with mockups later. Waiting on the rest to check their parts.

Yup sure, by the way @ngsengleng I have changed the image for help to reflect our site, unless you wanna change the design for help window

Codecov Report

Merging #74 (5af337d) into master (e3c39f5) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #74   +/-   ##
=========================================
  Coverage     72.18%   72.18%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1233     1233
  Branches        125      125
=========================================
  Hits            890      890
  Misses          311      311
  Partials         32       32

Impacted Files
Coverage Δ

src/main/java/gomedic/ui/HelpWindow.java
0.00% <ø> (ø)

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 e3c39f5...5af337d. Read the comment docs.


Python: Dependencies are looked up from incorrect urls

When running component-detection on one of my projects I am seeing output like the following.
[INFO] Getting Python data from https://pypi.org/pypi/pywinpty>=1.1.0/json
[WARN] Received 404 Not Found from https://pypi.org/pypi/pywinpty>=1.1.0/json
[WARN] Dependency Package pywinpty>=1.1.0 not found in Pypi. Skipping package

It seems like component-detection is in some situations passing an incorrect url which contains the version specifier and obviously does not resolve. This seems to happen for transitive dependencies that are constrained to a specific version by some other direct or transitive dependency.

This is handled by this regex:
https://github.com/microsoft/component-detection/blob/17a1fb2bd96f3757c4b032fbb7f161f16f049550/src/Microsoft.ComponentDetection.Detectors/pip/PipDependencySpecification.cs#L32-L35
Testing this regex on pywinpty>=1.1.0 works, but requirements with optional dependencies like PyJWT[crypto]<3,>=1.0.0 will match as PyJWT[crypto] which is incorrect. We probably need to add
|(?=\[)

to this regex and create a separate issue that tracks us not fetching the transitive dependencies of the optional depenedency.

Additionally, there are some Require-Dists in this format:
Requires-Dist: numpy<1.27.0,>=1.19.5

that do not match this Regex:
https://github.com/microsoft/component-detection/blob/17a1fb2bd96f3757c4b032fbb7f161f16f049550/src/Microsoft.ComponentDetection.Detectors/pip/PipDependencySpecification.cs#L13-L16

This is also likely a combination of custom packaging index feeds - #1129 should have support for this now.


new dataframe with three dataframe

re-design the DataPack~

Codecov Report

Merging #321 into 2.0 will not change coverage.
The diff coverage is 100%.

@@         Coverage Diff         @@
##            2.0   #321   +/-   ##
===================================
  Coverage   100%   100%
===================================
  Files        28     28
  Lines       734    769   +35
===================================
+ Hits        734    769   +35

Impacted Files
Coverage Δ

matchzoo/datapack.py
100% <100%> (ø)
:arrow_up:

matchzoo/models/dssm_model.py
100% <100%> (ø)
:arrow_up:

matchzoo/preprocessor/dssm_preprocessor.py
100% <100%> (ø)
:arrow_up:

matchzoo/models/cdssm_model.py
100% <100%> (ø)
:arrow_up:

matchzoo/engine/base_preprocessor.py
100% <100%> (ø)
:arrow_up:

matchzoo/generators/point_generator.py
100% <100%> (ø)
:arrow_up:

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 86b6512...10cbff3. Read the comment docs.


Sounds over a certain length do not play properly.

I originally posted this on the HaxeFlixel repository, but it turned out to be an issue with OpenFL and lime.
Sounds over a certain length, seemingly around 25 minutes, do not play properly. An acquaintance discovered the details regarding the reason for this, and how to fix it:

Read below for additional details:
https://github.com/HaxeFlixel/flixel/issues/2899

An acquaintance discovered the details regarding the reason for this, and how to fix it:

Unfortunately, this screenshot does not make clear "how to fix it" at all. If I had to guess, the "how to fix it" part is in the thumbnails that are cropped? Please ask your acquaintance to explain in a bit more detail (without images) what needs to be changed, or to submit a pull request with the necessary changes.

Alright, I'll do a pull request.

Pull requests are open:
https://github.com/openfl/openfl/pull/2667
https://github.com/openfl/lime/pull/1716

Apparently, the fix has been merged.


Parsing a dck file now looks for xml proformas in the location specified in the file

When parsing a dck file, the Deck constructor will now look for proformas in the path specified by the *$MODEL attribute produced by TRNSYS Visual Studio (also produced by trnsystor) only if the proforma_root path is not specified.
Note that only xml format is supported at the moment. TMF is not.

Codecov Report

Merging #60 (63b7725) into main (9136893) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #60      +/-   ##
==========================================
- Coverage   94.50%   94.40%   -0.11%
==========================================
  Files          49       49
  Lines        1984     1984
==========================================
- Hits         1875     1873       -2
- Misses        109      111       +2

Impacted Files
Coverage Δ

trnsystor/deck.py
92.67% <100.00%> (-1.13%)
:arrow_down:

trnsystor/trnsysmodel.py
98.06% <0.00%> (+0.77%)
:arrow_up:

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 9136893...63b7725. Read the comment docs.


DOCK-2507: Add "Discover Existing Tools/Notebooks"

Description
Previously, we discovered that the "Discover Existing Notebooks" button was missing from the UI. Also, "Discover Existing Tools" (disabled in https://github.com/dockstore/dockstore-ui2/pull/1919) wasn't behaving as expected: when clicked, bioworkflows were displayed instead of tools.
This PR should fix/add the functionality for tools and notebooks respectively. To display the correct entries, the UI should now re-request entries of the desired type after calling addUserToDockstoreWorkflows (which appears to only return bioworkflows).
"Discover Existing Tools" buttons and tooltip (restored the HTML that was removed in https://github.com/dockstore/dockstore-ui2/pull/1919):

"Discover Existing Notebooks" buttons and tooltip:

Review Instructions
A "More" button should be visible in the sidebar accordion for private workflows, tools, and notebooks, which should reveal the appropriate "Discover Existing [Workflows/Tools/Notebooks]" button on click.
In terms of the syncing functionality, clicking "Discover Existing" for each of my-workflows, my-tools, and my-notebooks should display synced entries of the correct type.
Issue
https://github.com/dockstore/dockstore/issues/5798
Security
If there are any concerns that require extra attention from the security team, highlight them here.
Please make sure that you've checked the following before submitting your pull request. Thanks!

[x] Check that your code compiles by running npm run build
[x] Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
[x] If this is the first time you're submitting a PR or even if you just need a refresher, consider reviewing our style guide
[x] Do not bypass Angular sanitization (bypassSecurityTrustHtml, etc.), or justify why you need to do so
[x] If displaying markdown, use the markdown-wrapper component, which does extra sanitization
[x] Do not use cookies, although this may change in the future
[x] Run npm audit and ensure you are not introducing new vulnerabilities
[x] Do due diligence on new 3rd party libraries, checking for CVEs
[x] Don't allow user-uploaded images to be served from the Dockstore domain
[x] If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.
[x] Check whether this PR disables tests. If it legitimately needs to disable a test, create a new ticket to re-enable it in a specific milestone.

Looks like this line https://github.com/dockstore/dockstore/blob/develop/dockstore-webservice/src/main/java/io/dockstore/webservice/resources/UserResource.java#L1112 is why the endpoint only returns BioWorkflow entries:
return convertWorkflowSummariesToWorkflows(this.bioWorkflowDAO.findUserBioWorkflows(user.getId()), BioWorkflow::new);
If we were to solve the bug through the web service instead of the UI, the endpoint would need to know the entry type/page that the user is currently on (e.g. return findUserBioWorkflows for my-workflows, return findUserNotebooks for my-notebooks). I assume my-tools would involve returning an array of workflows combining both AppTool and Container entries. (Unless the endpoint were to return all workflows, for the UI to filter by entry type? Would that be even more load/network calling?)

I'd propose that we [eventually?] change the addUserToDockstoreWorkflows endpoint to not return anything.

Personally I think I might agree, since the endpoint's return value seems like a separate call, which doesn't really contribute to the "adding users to Dockstore workflows". Also, when the GET request is issued through the UI (let's say it calls getMyBioWorkflows from getMyEntries), I believe it reaches the same return value/functionality anyways. So it seems okay to remove the return statement, and let the UI handle the GET separately from the PATCH endpoint. (but agreed that this is probably a future concern)


Feature request: class support and stats

First things first: thank you for such a beautiful piece of code. Amazing!
I have a shared network where I define some classes to ease management, like this:
On dhcpd.conf:
# Class Desktop
class "clsDesktop" {
    match pick-first-value (option dhcp-client-identifier, hardware);
}

On an included file:
# Host boss-notebook
subclass "clsDesktop" 1:c4:6e:1f:ab:cd:ef;

Would be nice to have stats about how many devices are defined by class and how many have an active lease by class.
Side note, I define the clients on includes, so include support would be also nice.
Best regards.

This is references in my requested list of featuers, #35


transfer_enrollment command is not properly transferring enrollment

Steps to Reproduce

Register two users
Enroll one user in a course
Now, try to transfer this enrollment to the other user e.g.

./manage.py transfer_enrollment --from-user=<username or email>--to-user=<username or email> --run=<courseware_id>

Expected Behavior

The enrollment gets transferred to the other user and doesn't show on the dashboard of --from-user

Actual Behavior

The command succeeds but?
The enrollment only gets transferred on edX, This means that the new user sees a course enrollment on edX dashboard but not on MITxOnline dashboard.
Because this new enrollment doesn't get created in MITxOnline. It's only created on edX. Also, The previous user also sees the enrollment on both MITxOnline and edX. However, the enrollment status for the previous user is successfully set to transferred for the previous user.

Note
I noticed this issue while testing https://github.com/mitodl/mitxonline/pull/1761, But It's worth putting some time on testing this command independently.

As far as I know, we haven't had need for this management command yet. It's more revelant in situations where we are doing a lot of B2B bulk purchases.


DRILL-3724 - added javadoc for core classes for storage plugin development.

Changes are only to the javadoc. Code is not affected.

Fixed. Review please.

Looks good to me +1.  I'll get this merged

This has been merged. However, I forgot to include the "merged in" message so @ebegoli , can you please close?

Closing.


Compatability issues with Angular 10

Demonstration

Upgraded the CLI to latest Angular 10.
Created a new Angular project
Ran the ng add single-spa-angular schematics
I kept both using Routing and Browser Animations options
Added the APP_BASE_HREF and EmptyRouteComponent in AppModule
Served the application using the npm script npm run serve:single-spa

Outcome
Once we run the the serve comnand, the compiler throws in this error:
ERROR in ./src/main.single-spa.ts
Module build failed (from ./node_modules/@ngtools/webpack/src/index.js):
Error: /home/adithya/Desktop/Code/Angular/micro-apps/navbar/src/main.single-spa.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
    at AngularCompilerPlugin.getCompiledFile (/home/adithya/Desktop/Code/Angular/micro-apps/navbar/node_modules/@ngtools/webpack/src/angular_compiler_plugin.js:935:23)
    at /home/adithya/Desktop/Code/Angular/micro-apps/navbar/node_modules/@ngtools/webpack/src/loader.js:42:31
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

Looks like the main.single-spa.ts file is not picked up by TypeScript. So I added it along in the tsconfig.app.json file like so:
{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "outDir": "./out-tsc/app",
    "types": []
  },
  "files": ["src/main.ts", "src/main.single-spa.ts", "src/polyfills.ts"],
  "include": ["src/**/*.d.ts"]
}

Now the error seems to be fixed. But it throws in a new one:
ERROR in node_modules/single-spa-angular/lib/browser-lib/extra-providers.d.ts:3:10 - error TS2305: Module '"../../../@angular/platform-browser/platform-browser"' has no exported member 'ɵBrowserPlatformLocation'.

import { ɵBrowserPlatformLocation } from '@angular/platform-browser';

Looks like ɵBrowserPlatformLocation should be imported from @angular/common.
Ref: Angular Github

I guess the issue is because ng add single-spa-angular instead of installing the version 4, is installing v3. So the schematic is failing to identify the Angular version I guess.

Why was this issue closed? I am reopening. We should discuss what is needed for Angular 10 support and then implement it.

Looks like ɵBrowserPlatformLocation should be imported from @angular/common.

It is:
https://github.com/single-spa/single-spa-angular/blob/a4cc1633bf0b8f39c57484a51e7895561818c37b/src/src/extra-providers.ts#L2-L7

I guess the issue is because ng add single-spa-angular instead of installing the version 4, is installing v3

I guess the issue is because ng add single-spa-angular instead of installing the version 4, is installing v

Interesting, that's true.

I guess the issue is because ng add single-spa-angular instead of installing the version 4, is installing v3. So the schematic is failing to identify the Angular version I guess.

That seems like it is related to the following code? I'm not sure why that code would stop working in Angular 10.
https://github.com/single-spa/single-spa-angular/blob/a4cc1633bf0b8f39c57484a51e7895561818c37b/schematics/ng-add/dependencies.ts#L27

I have actually tried again and it is still installing single-spa-angular: ^3.5.3.

Created a new angular project with Angular CLI v10.0.0
Ran the ng add single-spa-angular

Here is the dependencies list from package.json:
{
 "dependencies": {
    "@angular-builders/custom-webpack": "^8",
    "@angular/animations": "~10.0.0",
    "@angular/common": "~10.0.0",
    "@angular/compiler": "~10.0.0",
    "@angular/core": "~10.0.0",
    "@angular/forms": "~10.0.0",
    "@angular/platform-browser": "~10.0.0",
    "@angular/platform-browser-dynamic": "~10.0.0",
    "@angular/router": "~10.0.0",
    "rxjs": "~6.5.5",
    "single-spa-angular": "^3.5.3",
    "tslib": "^2.0.0",
    "zone.js": "~0.10.3"
  }
}

We didn't fix anything related to this, so it is not surprising that it isn't working yet. My comments above were to help brainstorm a solution - if anyone would like to send in a pull request with a fix, that would be appreciated.

We didn't fix anything related to this, so it is not surprising that it isn't working yet. My comments above were to help brainstorm a solution - if anyone would like to send in a pull request with a fix, that would be appreciated.

Yup..I was just trying to confirm the issue and add some additional info if needed.

Hey guys I made exactly the same process for my project (described in Demonstration part of the issue).
Am I the only one that had to do these moves :
Update the main.single-spa.ts file
import singleSpaAngular, { getSingleSpaExtraProviders } from 'single-spa-angular';

->
import { getSingleSpaExtraProviders, singleSpaAngular } from 'single-spa-angular';

Updated the single-spa version
    "single-spa-angular": "^3.6.0",

    "single-spa-angular": "^4.2.0",
    "single-spa": "^4.4.4",

I think that's pretty all I remember on my side in addition to what you already did of course.
Ah yes I updated as well the version of custom-webpack "@angular-builders/custom-webpack": "^10.0.0-beta.0", but I think it's not mandatory.

Hi @celian-garcia, the changes to the imports were part of the Angular 8 to Angular 9 migration and are documented in https://github.com/single-spa/single-spa-angular/releases/tag/v4.0.0. Angular 10 also uses<EMAIL_ADDRESS>so anybody upgrading from Angular <= 8 to Angular 10 will need to make those changes.

Okay thanks for the info. I didn't really migrate actually I just made ng new + ng add single-spa-angular but maybe I should have explicitely mention the version of single-spa-angular somehow.

Why was this issue closed? I am reopening. We should discuss what is needed for Angular 10 support and then implement it.

Yes, we would like to upgrade our single-spa apps to Angular 10, and resolving this issue would be great. Happy to contribute my time if needed.

Hey guys I made exactly the same process for my project (described in Demonstration part of the issue).
Am I the only one that had to do these moves :
Update the main.single-spa.ts file
import singleSpaAngular, { getSingleSpaExtraProviders } from 'single-spa-angular';

->
import { getSingleSpaExtraProviders, singleSpaAngular } from 'single-spa-angular';

Updated the single-spa version
    "single-spa-angular": "^3.6.0",

    "single-spa-angular": "^4.2.0",
    "single-spa": "^4.4.4",

I think that's pretty all I remember on my side in addition to what you already did of course.
Ah yes I updated as well the version of custom-webpack "@angular-builders/custom-webpack": "^10.0.0-beta.0", but I think it's not mandatory.

I did exactly the same.

Hi @helumalai, yes if you have time and would like to contribute any changes needed for Angular 10 support, that would be greatly appreciated! @Den-dp has made a lot of progress on some related issues, as reported in https://github.com/single-spa/single-spa-angular/issues/249. I am happy to review pull requests to address the issues.

Hi, I'm using the single-spa CLI to create an angular app. I have made some changes to build and run the code (@celian-garcia thanks 😄 ) but I found this little problem when acessing the url playground:
Cannot read property 'injector' of undefined - at single-spa-angular.js:198
Have anyone faced this point?
Angular version: 10
Single Spa Angular: 4.2.0

Hi @maximillianfx I don't remember such an error. What is your main.single-spa.ts ?
Mine is like this :
import { enableProdMode, NgZone } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { Router } from '@angular/router';
import { AppModule } from './app/app.module';
import { environment } from './environments/environment';
import { getSingleSpaExtraProviders, singleSpaAngular } from 'single-spa-angular';
import { singleSpaPropsSubject } from './single-spa/single-spa-props';

if (environment.production) {
  enableProdMode();
}

const lifecycles = singleSpaAngular({
  bootstrapFunction: singleSpaProps => {
    singleSpaPropsSubject.next(singleSpaProps);
    return platformBrowserDynamic(getSingleSpaExtraProviders()).bootstrapModule(AppModule);
  },
  template: '<abilities-root />',
  Router,
  NgZone,
});

export const bootstrap = lifecycles.bootstrap;
export const mount = lifecycles.mount;
export const unmount = lifecycles.unmount;

Oh :/, my main.single-spa.ts:
import { enableProdMode, NgZone } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { Router } from '@angular/router';
import { ɵAnimationEngine as AnimationEngine } from '@angular/animations/browser';
import { AppModule } from './app/app.module';
import { environment } from './environments/environment';
import { singleSpaAngular, getSingleSpaExtraProviders } from 'single-spa-angular';
import { singleSpaPropsSubject } from './single-spa/single-spa-props';

if (environment.production) {
  enableProdMode();
}

const lifecycles = singleSpaAngular({
  bootstrapFunction: singleSpaProps => {
    singleSpaPropsSubject.next(singleSpaProps);
    return platformBrowserDynamic(getSingleSpaExtraProviders()).bootstrapModule(AppModule);
  },
  template: '<app-root />',
  Router,
  NgZone: NgZone,
  AnimationEngine: AnimationEngine,
});

export const bootstrap = lifecycles.bootstrap;
export const mount = lifecycles.mount;
export const unmount = lifecycles.unmount;

I've read on the single spa docs the support for Angular 9. I will make a project using Angular CLI 9 and re-test.

Hello! Using this approach and using angular in 9.1.7 the project is running!

Hello! Using this approach and angular in 9.1.7 the project is running!

It works on Angular 9 without any issues. Only problem is with 10. The schematic is somehow installing the version 3 of single-spa-angular instead of version 4

Hello, here is an example of a working project https://github.com/milobella/application-web, the project in itself is still in construction but the spa part is functional, with Angular 10.0.3 and single-spa-angular 4.2.0.
@joeldenning I would be happy to contribute to ameliorate but I don't really get what is needed at the end. Maybe there is some gaps in the schematic ? I will create soon a new component from scratch, I should see at this moment if anything is missing.

Hey guys. I've checked the ng add single-spa-angular command with Angular 10, it installed the latest version:

For me it works perfectly now.

Thanks for clarifying @celian-garcia
@adisreyaj was this issue resolved? Can it be closed?

@arturovt Looks like the issue is solved.


Access raw error message

The various error types exposed in the temporal workflows do not provide access to the raw error message.
The .Error() method on these error types adds a bunch of details along with the error message.
The .message() method on them is private as well.
Is there a way to access the raw error message from these error structs?

Can you give the specific errors you cannot get the underlying errors out of via errors.Unwrap()? We try to stick to proper Unwrap() convention but we miss some.

We're passing a custom error type from worker which gets wrapped inside a ApplicationError.
When trying to get the error message from the ApplicationError it formats the string with error type and non-retryable bool. I need the raw error message from the Application Error to pass it on to the UI.

Ah, the raw message. We have just solved this in #766 and it is in master and will be released with the next release (a week or two).

Awesome! thanks @cretz


Throw informative errors when backends are not loaded

When forgetting to load a backend package, most operators error at either prepare_pullback_aux or prepare_pushforward_aux, resulting in an uninformative MethodError:
julia> gradient(f, backend, x)
ERROR: MethodError: no method matching prepare_pushforward_aux(::typeof(f), ::AutoForwardDiff{…}, ::Vector{…}, ::FillArrays.OneElement{…}, ::DifferentiationInterface.PushforwardFast)

This PR adds these missing methods, throwing an informative error that suggests loading the respective backend.
New errors
julia> gradient(f, AutoEnzyme(), x)
ERROR: Failed to prepare pullback for Enzyme (forward/reverse) backend.
This usually due to the backend not being loaded. To fix, specify

    using Enzyme

Stacktrace:
 [1] prepare_pullback_aux(f::Function, backend::AutoEnzyme{Nothing}, x::Vector{Float64}, dy::Float64, ::DifferentiationInterface.PullbackFast)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pullback.jl:98
 [2] prepare_pullback(f::Function, backend::AutoEnzyme{Nothing}, x::Vector{Float64}, dy::Float64)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pullback.jl:68
 [3] prepare_gradient(f::typeof(f), backend::AutoEnzyme{Nothing}, x::Vector{Float64})
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/gradient.jl:48
 [4] gradient(f::Function, backend::AutoEnzyme{Nothing}, x::Vector{Float64})
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/gradient.jl:73
 [5] top-level scope
   @ REPL[21]:1

julia> gradient(f, AutoForwardDiff(), x)
ERROR: Failed to prepare pushforward for ForwardDiff (forward) backend.
This usually due to the backend not being loaded. To fix, specify

    using ForwardDiff

Stacktrace:
 [1] prepare_pushforward_aux(f::Function, backend::AutoForwardDiff{…}, x::Vector{…}, dy::FillArrays.OneElement{…}, ::DifferentiationInterface.PushforwardFast)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pushforward.jl:87
 [2] prepare_pushforward(f::Function, backend::AutoForwardDiff{…}, x::Vector{…}, dx::FillArrays.OneElement{…})
    Use `show(err)` to see complete types.

Previous errors

julia> gradient(f, backend, x)
ERROR: MethodError: no method matching prepare_pushforward_aux(::typeof(f), ::AutoForwardDiff{…}, ::Vector{…}, ::FillArrays.OneElement{…}, ::DifferentiationInterface.PushforwardFast)

Closest candidates are:
  prepare_pushforward_aux(::Any, ::Any, ::Any, ::Any, ::Any, ::DifferentiationInterface.PushforwardSlow)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pushforward.jl:70
  prepare_pushforward_aux(::Any, ::Any, ::Any, ::Any, ::DifferentiationInterface.PushforwardSlow)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pushforward.jl:63

Stacktrace:
 [1] prepare_pushforward(f::Function, backend::AutoForwardDiff{…}, x::Vector{…}, dx::FillArrays.OneElement{…})
    Use `show(err)` to see complete types.

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

Project coverage is 95.90%. Comparing base (e549302) to head (6816fcf).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #214      +/-   ##
==========================================
- Coverage   96.40%   95.90%   -0.50%
==========================================
  Files          65       15      -50
  Lines        3558     1562    -1996
==========================================
- Hits         3430     1498    -1932
+ Misses        128       64      -64

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

Can we check that these exceptions are indeed thrown? i.e. by defining a fake backend with no operators

You can use 'check_available' before throwing the exception to confirm the "unloaded" diagnosis. Otherwise the user should probably open an issue, cause I can't think of any other situation where we hit that missing method on purpose

Update with MissingBackendError and using check_available before printing the suggestion to load the backend package:
julia> gradient(f, AutoEnzyme(), x)
ERROR: failed to use Enzyme (forward/reverse) backend.
Backend package is not loaded. To fix, run

  using Enzyme

Stacktrace:
 [1] prepare_pullback_aux(f::Function, backend::AutoEnzyme{Nothing}, x::Vector{Float64}, dy::Float64, ::DifferentiationInterface.PullbackFast)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pullback.jl:88
 [2] prepare_pullback(f::Function, backend::AutoEnzyme{Nothing}, x::Vector{Float64}, dy::Float64)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pullback.jl:68
 [3] prepare_gradient(f::typeof(f), backend::AutoEnzyme{Nothing}, x::Vector{Float64})
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/gradient.jl:48
 [4] gradient(f::Function, backend::AutoEnzyme{Nothing}, x::Vector{Float64})
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/gradient.jl:73
 [5] top-level scope
   @ REPL[13]:1

julia> gradient(f, AutoBrokenReverse(), x)
ERROR: failed to use AutoBrokenReverse (reverse) backend.
Please open an issue: https://github.com/gdalle/DifferentiationInterface.jl/issues/new
Stacktrace:
 [1] prepare_pullback_aux(f::Function, backend::AutoBrokenReverse, x::Vector{Float64}, dy::Float64, ::DifferentiationInterface.PullbackFast)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pullback.jl:88
 [2] prepare_pullback(f::Function, backend::AutoBrokenReverse, x::Vector{Float64}, dy::Float64)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pullback.jl:68
 [3] prepare_gradient(f::typeof(f), backend::AutoBrokenReverse, x::Vector{Float64})
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/gradient.jl:48
 [4] gradient(f::Function, backend::AutoBrokenReverse, x::Vector{Float64})
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/gradient.jl:73
 [5] top-level scope
   @ REPL[14]:1

julia> gradient(f, AutoForwardDiff(), x)
ERROR: failed to use ForwardDiff (forward) backend.
Backend package is not loaded. To fix, run

  using ForwardDiff

Stacktrace:
 [1] prepare_pushforward_aux(f::Function, backend::AutoForwardDiff{…}, x::Vector{…}, dy::FillArrays.OneElement{…}, ::DifferentiationInterface.PushforwardFast)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pushforward.jl:77
 [2] prepare_pushforward(f::Function, backend::AutoForwardDiff{…}, x::Vector{…}, dx::FillArrays.OneElement{…})
    Use `show(err)` to see complete types.

julia> gradient(f, AutoBrokenForward(), x)
ERROR: failed to use AutoBrokenForward (forward) backend.
Please open an issue: https://github.com/gdalle/DifferentiationInterface.jl/issues/new
Stacktrace:
 [1] prepare_pushforward_aux(f::Function, backend::AutoBrokenForward, x::Vector{…}, dy::FillArrays.OneElement{…}, ::DifferentiationInterface.PushforwardFast)
   @ DifferentiationInterface ~/Developer/DifferentiationInterface.jl/DifferentiationInterface/src/first_order/pushforward.jl:77
 [2] prepare_pushforward(f::Function, backend::AutoBrokenForward, x::Vector{Float64}, dx::FillArrays.OneElement{Float64, 1, Tuple{…}, Tuple{…}})
    Use `show(err)` to see complete types.


[#2537] Fix LP to pull groupBy ahead of non-mapping operations in arbitrary reduction.

Corrects LogicalPlan by pulling GroupBy ahead of non-mapping operations in an Arbitrary reduction.
Fixes #2537.

Nice, all builds passed except for marklogic_xml, which failed because groupByFlatten.test is passing now! @wemrysi I'll push the change enabling that test tomorrow, if you don't get to it first.

@alissapajer I enabled the test for marklogic_xml, it may also pass for marklogic_json with ignoreFieldOrder, but I didn't have time to try.
Glad we were able to solve this one, thanks for working on it with me!

The test does not pass for marklogic_json. It errors with:
[error] ! flatten a grouped object with filter [./flattenGroupedObject.test] (4 seconds, 638 ms)
[error]  quasar.physical.marklogic.xcc.DefaultImpl$XccXQueryException: XDMP-ARGTYPE: (err:XPTY0004) fn:matches(object-node{"name": text{"Greg Pfeil"}, "email"<EMAIL_ADDRESS>"^http.*$", "m") -- arg1 is not of type xs:string? on line 111


IPC SinkStream Doesn't Propagate Close to the Underlying Writer

Hi,
I came across this issue while working with a writer that writes data to the network. When I call close on the IPC SinkStream, I discovered that the underlying writer wasn't closed, which prevented the underlying writer from flushing its data to the network and cleaning itself up.
If I'm misunderstanding how to use the SinkStream, let me know, and I can correct my usage. If this is an actual issue, I'm happy to contribute a fix PR.
Thanks!

I also don't seem to have the permissions to add a label, but based on the contribution guide, this label should be no-changelog


Fixes output of wrong input variable in reusable

github.event.inputs.tag is never set but .tags is.
I changed the output text from singular to plural and changed the used input variable to the correct one

Why:
Closes https://github.com/github/docs/issues/16282

What's being changed:
I changed the job's output to use the correct input variable and reworded it from singular to plural.

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@SpraxDev
Thanks so much for opening a PR! I'll get this triaged for review :zap:


Godot Soft Shadows are Looking Weird

Tested versions
-4.2.stable
System information
Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce GT 1030 (NVIDIA; <IP_ADDRESS>42) - AMD Ryzen 3 1300X Quad-Core Processor (4 Threads)
Issue description
Godot's soft shadows are looking bad and i think it is a good point to fix it.

even in max settings:

you can notice the grainy shadow
Steps to reproduce
-Open Godot
-Check shadows
Minimal reproduction project (MRP)
N/A

These are limitations if the rendering methods and occur in any real time lighting, also I can't see any graininess in the max settings screenshot
Have you read this?

These are limitations if the rendering methods and occur in any real time lighting, also I can't see any graininess in the max settings screenshot
What are your suggestions for improvements? What methods should be used? 🙂
Have you read this?

idk too much about lighting but in other engines (flax unreal unity) shadows are looking soft and smooth. also if you look very closely you can see the grain

Can you actually see the graininess from in actual usage? And did you read the instructions for how to modify and tweak shadows?
Generally improvements are welcome, but without any solid ideas it's not much that can be done, right? We aren't neglecting shadow quality, so some suggestions to how to fix it would be welcome, as you point out that "it is a good point to fix it" 🙂, assumed you had ideas for how to accomplish that

Can you actually see the graininess from in actual usage? And did you read the instructions for how to modify and tweak shadows?
Generally improvements are welcome, but without any solid ideas it's not much that can be done, right? We aren't neglecting shadow quality, so some suggestions to how to fix it would be welcome, as you point out that "it is a good point to fix it" 🙂, assumed you had ideas for how to accomplish that

i think better softing algorithms can be used like Variance Shadow Mapping (idk too much about it just did some research)

I'm sure this is and has been researched by the rendering team, I'd suggest opening a discussion about this, as this is for bugs and there's not really a bug here, just a particular result quality, improvements can be done but without more concrete ideas of how to do it (and considering the results aren't especially bad) I'd say this is the wrong place for it 🙂

I'm sure this is and has been researched by the rendering team, I'd suggest opening a discussion about this, as this is for bugs and there's not really a bug here, just a particular result quality, improvements can be done but without more concrete ideas of how to do it (and considering the results aren't especially bad) I'd say this is the wrong place for it 🙂
Also while I get the limitations, the visual example is not entirely fair and realistic, as very uniform and flat surfaces show a lot of the imperfections in ways more usual rendering situations do, not to mention the very zoomed in image, that's not to say there aren't areas we can possibly improve, but in real application cases the rendering is very much competivtive, though it's very hard to compete with the AAA, closed source, proprietary engines (though we do dream)
Rendering has been a major focus during the 4.x cycle, compare with 3.x and you will see how far these improvements have come, so any ideas are welcome, but this isn't, in my opinion, very helpful 🙂

okay thanks for letting me know! see you

For reference, this was already reported in https://github.com/godotengine/godot/issues/53534 and there are PRs to address it when TAA is enableD.


add request id on call to playbook-dispatcher

LGTM :+1:
Merge away once the tests are done running. :)


Liveness and Readiness probes fail with recommended certificate setup

Expected Behavior
Expected that tekton-results-api pod would become healthy.
Actual Behavior
The tekton-results-api pod does not become healthy. Readiness and Liveness probes fail with 503 response. Doing a port-forward on the tekton-results-api's  api container and doing a curl to the /healthz endpoint returns the following error:
{"code":14,"message":"connection error: desc = \"transport: authentication handshake failed: x509: certificate is valid for tekton-results-api-service.tekton-pipelines.svc.cluster.local, not localhost\"","details":[]}

I am using self-signed certificates managed by certman. Adding localhost to the dnsNames list results in the Liveness and Readiness probes passing. As per prerequisites this is not the recommended config.
Steps to Reproduce the Problem

Install Certman
Install Tekton Pipelines (v0.38.4)
Create Certificate and Certificate issuer as below:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: tekton-results-selfsigned-issuer
  namespace: tekton-pipelines
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: tekton-results-tls-cert
  namespace: tekton-pipelines
spec:
  dnsNames:
  - tekton-results-api-service.tekton-pipelines.svc.cluster.local
  # - localhost # uncomment this to make probes pass
  issuerRef:
    kind: Issuer
    name: tekton-results-selfsigned-issuer
  secretName: tekton-results-tls

Install Tekton Results following all install instructions besides certificate generation (v0.7.0)
Observe unhealthy tekton-results-api pod

Additional Info

Kubernetes version:

Server Version: v1.23.17-eks-c12679a

Tekton Pipeline version:

v0.38.4

Readiness/Liveness probe don't check certificate verification .
You should curl with --insecure option, and see what happened.
Normally it should be like this:
> curl --insecure  https://localhost:8080/healthz
{"status":"SERVING"}

If not, I suspect something else went wrong, like some configuration problem.

I have indeed used the insecure option for curl. It looks like the actual go http server is returning the body i showed because the certificate loaded does not have localhost as a dns name. In the example above are you using a cert generated using the instructions here or are you also including localhost in the subject alternate names?

In the example above are you using a cert generated using the instructions here or are you also including localhost in the subject alternate names?

I followed the instructions, which not include  localhost in the subject alternate names.

It looks like the actual go http server

Yes, I think so after carefully reading the error message.
Have no idea right now. Maybe you could turn on debug logging to see what is happening in Results API Server .

Change logging level to debug.
kubectl -n tekton-pipelines edit cm tekton-results-config-logging
set as below

zap-logger-config: |
    {
      "level": "debug",
      "development": true,
     .....
    }

curl again
check Results API Server logs

So interestingly, if i port forward to the service as you have done, I do not get the error. If I port forward to the pod, i do.
So example of what I was doing which returns a 503 code and the error response I showed earlier:
kubectl port-forward -n tekton-pipelines pods/tekton-results-api-57845986d9-8lrfw 8080:8080

Regardless, I bumped the logging level, and I tried again. The curls do not actually correlate to anything in the logs. There are a bunch of tls errors which seem to match the cadence of the probes:
2023/07/12 13:10:45 maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined
{"level":"warn","ts":1689167445.1729739,"caller":"api/main.go:116","msg":"Kubernetes RBAC authorization check disabled - all requests will be allowed by the API server"}
{"level":"info","ts":1689167445.3304975,"caller":"api/main.go:195","msg":"Prometheus server listening on: 9090"}
{"level":"info","ts":1689167445.3309426,"caller":"api/main.go:237","msg":"gRPC and REST server listening on: 8080"}
2023/07/12 13:10:54 http: TLS handshake error from <IP_ADDRESS>:34026: remote error: tls: bad certificate
2023/07/12 13:11:04 http: TLS handshake error from <IP_ADDRESS>:33524: remote error: tls: bad certificate
2023/07/12 13:11:09 http: TLS handshake error from <IP_ADDRESS>:33542: remote error: tls: bad certificate
2023/07/12 13:11:14 http: TLS handshake error from <IP_ADDRESS>:44222: remote error: tls: bad certificate
2023/07/12 13:11:24 http: TLS handshake error from <IP_ADDRESS>:33502: remote error: tls: bad certificate

Here the events shown from a describe on the pod:
Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Normal   Scheduled  6m20s                  default-scheduler  Successfully assigned tekton-pipelines/tekton-results-api-57845986d9-8lrfw to ip-10-123-123-12.af-south-1.compute.internal
  Normal   Pulled     4m40s (x2 over 6m19s)  kubelet            Container image "gcr.io/tekton-releases/github.com/tektoncd/results/cmd/api:v0.7.0@sha256:08aea538dc699c27715523fc89115cc805a0b5838c924868907189fcc99099b9" already present on machine
  Normal   Created    4m40s (x2 over 6m19s)  kubelet            Created container api
  Normal   Killing    4m40s                  kubelet            Container api failed startup probe, will be restarted
  Normal   Started    4m39s (x2 over 6m19s)  kubelet            Started container api
  Warning  Unhealthy  70s (x31 over 6m10s)   kubelet            Startup probe failed: HTTP probe failed with statuscode: 503

Note the 503 - which assumed meant the result was the same as that from the curl I was doing.

I dig a little.
Background:
Results API Server took a little trick to server as  GRPC server and RESTful server: on port 8080, it register both grpc service and http service and process request base on http protocol version and Content-Type.
So one health check flow like this: (1)Kubelet probe -> (2)Results Server RESTful service -> (3)Results Server GRPC service.
Why Results API Server complained tls: bad certificate?
Problem  occur when (2)->(3) happened. Results Server need to dial itself and forward this health check request with  in GRPC format. Because original http request do not have authority header and the path  Kubelet request is simply http://localhost:8080,  so TLS handshake failed.
Workaround
Add environment variable TLS_HOSTNAME_OVERRIDE as tekton-results-api-service.tekton-pipelines.svc.cluster.local to Results API Server pod configuration.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: tekton-pipelines
    spec:
      serviceAccountName: api
      containers:
        - name: api
          image: ....
          env:
            - name: TLS_HOSTNAME_OVERRIDE
              value: tekton-results-api-service.tekton-pipelines.svc.cluster.local

@sayan-biswas  Is here something wrong here?
As document says:

TLS_HOSTNAME_OVERRIDE   Override the hostname used to serve TLS. This should not be set (or set to the empty string) in production environments.

But it seems even in production environment, TLS_HOSTNAME_OVERRIDE need to be set to make liveness probe working.

@xinnjie This is not happening because of the multiplexing of the gRPC and REST traffic to one port. But this is happening because the REST service in this is a proxy to the gRPC server, which is provide by the package gRPC gateway. So, in code generated by the gRPC gateway I passed an instance of the gRPC client conn.
https://github.com/tektoncd/results/blob/e85794158c43defca77deb2b63201497dca9f45d/cmd/api/main.go#L206C72-L206C93
Ad if I leave that field blank it will default to localhost and the certificate generated externally only contains the FQDN of the service in CNAME. That why when @kbristow as both the CNAMEs it was working. In production environment this will be behind an ingress which should re-encrypt the traffic with the generated certificate.
And I also think the document is a little unclear or outdated.

@kbristow The health probe logs are filtered out here.
https://github.com/tektoncd/results/blob/e85794158c43defca77deb2b63201497dca9f45d/cmd/api/main.go#L146
Because it will spam the log. But maybe for debug we can enable this.

@kbristow The health probe logs are filtered out here.
https://github.com/tektoncd/results/blob/e85794158c43defca77deb2b63201497dca9f45d/cmd/api/main.go#L146
Because it will spam the log. But maybe for debug we can enable this.

@sayan-biswas
How to explain 2023/07/12 13:10:54 http: TLS handshake error from <IP_ADDRESS>:34026: remote error: tls: bad certificate this kind of log still exist?
Looks like somewhere of http server do not use zap logger.

@xinnjie This is not happening because of the multiplexing of the gRPC and REST traffic to one port. But this is happening because the REST service in this is a proxy to the gRPC server, which is provide by the package gRPC gateway. So, in code generated by the gRPC gateway I passed an instance of the gRPC client conn.
https://github.com/tektoncd/results/blob/e85794158c43defca77deb2b63201497dca9f45d/cmd/api/main.go#L213
Ad if I leave that field blank it will default to localhost and the certificate generated externally only contains the FQDN of the service in CNAME. That why when @kbristow as both the CNAMEs it was working. In production environment this will be behind an ingress which should re-encrypt the traffic with the generated certificate.
And I also think the document is a little unclear or outdated.
Surely in Production env it works fine.
What I am afraid is that a user want to try out Results demo encounter this"pod is being unhealthy constantly" behavior.

@kbristow The health probe logs are filtered out here.
https://github.com/tektoncd/results/blob/e85794158c43defca77deb2b63201497dca9f45d/cmd/api/main.go#L146
Because it will spam the log. But maybe for debug we can enable this.

@sayan-biswas How to explain 2023/07/12 13:10:54 http: TLS handshake error from <IP_ADDRESS>:34026: remote error: tls: bad certificate this kind of log still exist? Looks like somewhere of http server do not use zap logger.

Yes, this comes from the http internal libraries IG.

@xinnjie This is not happening because of the multiplexing of the gRPC and REST traffic to one port. But this is happening because the REST service in this is a proxy to the gRPC server, which is provide by the package gRPC gateway. So, in code generated by the gRPC gateway I passed an instance of the gRPC client conn.
https://github.com/tektoncd/results/blob/e85794158c43defca77deb2b63201497dca9f45d/cmd/api/main.go#L213
Ad if I leave that field blank it will default to localhost and the certificate generated externally only contains the FQDN of the service in CNAME. That why when @kbristow as both the CNAMEs it was working. In production environment this will be behind an ingress which should re-encrypt the traffic with the generated certificate.
And I also think the document is a little unclear or outdated.

@sayan-biswas Thanks for your explanations. I understood in production env it works fine now. What I am afraid is that a user wants to try out Results demo but encounter this"pod is being unhealthy constantly" behavior. Something needs to be done here.

In that case I guess we can default the TLS_HOSTNAME_OVERRIDE to tekton-results-api-service.tekton-pipelines.svc.cluster.local

Yes, agreed.

@sayan-biswas
Sorry~
I am still wondering after thinking twice. In production env without meshing service, how could the request from RESTful service to GRPC service to be re-encrypted with address being "localhost" and without authority header

Add environment variable TLS_HOSTNAME_OVERRIDE valued as tekton-results-api-service.tekton-pipelines.svc.cluster.local to Results API Server pod configuration

@xinnjie Thanks. I did see this environment variable but like you say, it says not for use in production and the only use I saw in the repo itself was for the e2e tests. The documentation is certainly not clear on how to use it/when to use it. I will use for my setup for now though.

In production environment this will be behind an ingress which should re-encrypt the traffic with the generated certificate.

@sayan-biswas Im not sure I understand how having the service behind an ingress will help with the k8s probes, which have no knowledge of that ingress.

@kbristow Health probe is not related to ingress comment. What I meant is normally the service will be used in that way. So the cert manager can generate certificate with have multiple cnames and the ingress can use that cert to re-encrypt the traffic.
We have faced the same issue, but not with health probes, but for normally usage of the REST APIs.
If we leave the tls override blank, it will default to 'localhost' in the internal libraries and we have no control over that.
Since the TLS is already validated in the HTTP listener, there's no need to validate it again at the gRPC server listener. So we can stop verifying the authority hearder there.
I'll try this out and open a PR if it works, else I'll default the TLS_HOSTNAME_OVERRIDE config to the service FQDN and update the document.

Thanks. I understand.

@kbristow Can you checkout PR #536 and see if that solves your issue?

I will have a look when I can 👍

before:
Results API Server complains about TLS handshake error from <IP_ADDRESS>:35826: remote error: tls: bad certificate
> kubectl kustomize config/overlays/logs-local-db" | ko delete  -f -
> kubectl kustomize config/overlays/logs-local-db" | ko apply  -f -
... apply successfully
> k -n tekton-pipelines get pods
NAME                                           READY   STATUS    RESTARTS        AGE
tekton-dashboard-69bfd6b5ff-b4pbc              1/1     Running   0               45h
tekton-events-controller-697685d976-6kmqw      1/1     Running   14 (99s ago)    21d
tekton-pipelines-controller-76d89b568d-n8fdl   1/1     Running   10 (99s ago)    15d
tekton-pipelines-webhook-7c86c9f9b4-m7r7r      1/1     Running   12 (100s ago)   21d
tekton-results-api-7964ff94f6-df6b6            0/1     Running   0               13s
tekton-results-postgres-0                      1/1     Running   0               13s
tekton-results-watcher-6c87f7bfd4-g99dk        1/1     Running   0               13s

> k -n tekton-pipelines logs tekton-results-api-7964ff94f6-df6b6
2023/07/20 12:58:44 maxprocs: Leaving GOMAXPROCS=5: CPU quota undefined
{"level":"warn","ts":1689857925.068253,"caller":"api/main.go:103","msg":"Error connecting to database (retrying in 10s): failed to connect to `host=tekton-results-postgres-service.tekton-pipelines.svc.cluster.local user=postgres database=tekton-results`: dial error (dial tcp <IP_ADDRESS>:5432: connect: connection refused)"}
{"level":"info","ts":1689857935.189105,"caller":"api/main.go:119","msg":"Kubernetes RBAC authorization check enabled"}
{"level":"info","ts":1689857935.2092667,"caller":"api/main.go:131","msg":"Kubernetes RBAC impersonation enabled"}
{"level":"info","ts":1689857936.332291,"caller":"api/main.go:198","msg":"Prometheus server listening on: 9090"}
{"level":"info","ts":1689857936.376498,"caller":"api/main.go:240","msg":"gRPC and REST server listening on: 8080"}
2023/07/20 12:58:57 http: TLS handshake error from <IP_ADDRESS>:35302: remote error: tls: bad certificate
2023/07/20 12:58:57 http: TLS handshake error from <IP_ADDRESS>:35300: remote error: tls: bad certificate
2023/07/20 12:58:57 http: TLS handshake error from <IP_ADDRESS>:35298: remote error: tls: bad certificate
2023/07/20 12:58:58 http: TLS handshake error from <IP_ADDRESS>:35308: remote error: tls: bad certificate
2023/07/20 12:58:58 http: TLS handshake error from <IP_ADDRESS>:35310: remote error: tls: bad certificate
2023/07/20 12:58:59 http: TLS handshake error from <IP_ADDRESS>:35316: remote error: tls: bad certificate
2023/07/20 12:59:01 http: TLS handshake error from <IP_ADDRESS>:35820: remote error: tls: bad certificate
2023/07/20 12:59:01 http: TLS handshake error from <IP_ADDRESS>:35822: remote error: tls: bad certificate
2023/07/20 12:59:02 http: TLS handshake error from <IP_ADDRESS>:35826: remote error: tls: bad certificate

After checkout to issue-521
> kubectl kustomize config/overlays/logs-local-db  | ko apply  -f -

> k -n tekton-pipelines get pods
NAME                                           READY   STATUS    RESTARTS         AGE
tekton-dashboard-69bfd6b5ff-b4pbc              1/1     Running   0                46h
tekton-events-controller-697685d976-6kmqw      1/1     Running   14 (7m10s ago)   21d
tekton-pipelines-controller-76d89b568d-n8fdl   1/1     Running   10 (7m10s ago)   15d
tekton-pipelines-webhook-7c86c9f9b4-m7r7r      1/1     Running   12 (7m11s ago)   21d
tekton-results-api-76b7559d7b-rkvrs            1/1     Running   0                23s
tekton-results-postgres-0                      1/1     Running   0                5m44s
tekton-results-watcher-598d6b4c9-clbd4         1/1     Running   0                23s

> k -n tekton-pipelines logs tekton-results-api-76b7559d7b-rkvrs
2023/07/20 13:04:08 maxprocs: Leaving GOMAXPROCS=5: CPU quota undefined
{"level":"info","ts":1689858248.6841698,"caller":"api/main.go:120","msg":"Kubernetes RBAC authorization check enabled"}
{"level":"info","ts":1689858248.7065732,"caller":"api/main.go:132","msg":"Kubernetes RBAC impersonation enabled"}
{"level":"info","ts":1689858250.0390294,"caller":"api/main.go:199","msg":"Prometheus server listening on: 9090"}
{"level":"info","ts":1689858250.114967,"caller":"api/main.go:240","msg":"gRPC and REST server listening on: 8080"}

Thanks, that looks great 👍


Source controller fails to create some helm package from git repository

Following #194 : after upgrade to 0.7.5 (that includes source-controller 0.7.2 that include #269), it seems not yet working properly:
With a chart layout in git like that
Chart.yaml # <= reference to `dependency` with a conditional
Chart.lock
charts/
   dependency/
      templates/
templates/

Source controller generates a package like that:
 Chart.yaml
 Chart.lock
 charts/
    <parent-chart-name>/
        charts/
           dependency/
               templates/
    dependency/
       templates/
templates/

Parent chart looks included as dependency, which cause an already exists in helm reconciliation
Note: a helm dep build <chart-path> in the git repository is not doing such a thing.

Can you please create a minimal (dummy) example in a public Git repository that triggers this issue?

https://github.com/Zempashi/docker-jitsi-meet/tree/k8s-helm/examples/helm is still relevant but not quite minimal (beside it will fail after creating 2 serviceaccount, so be ensure your cluster will not be overflooded).
I'll work on a small reproducer

Reproduced on my cluster with https://github.com/Zempashi/flux-helm-git-bug
(One parent created with helm create dummy and one dependency created with helm create dependency, I removed all template except serviceaccounts, and added an entry in Chart.yaml for the dependency)

I used your provided configuration (minus the HelmRelease) using a build from main:
---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: dummy
spec:
  interval: 10m0s
  ref:
    branch: master
  url: https://github.com/Zempashi/flux-helm-git-bug
---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmChart
metadata:
  name: dummy-chart
spec:
  chart: ./chart/dummy
  sourceRef:
    kind: GitRepository
    name: dummy
  interval: 5m0s

This did not result in any errors from the source-controller:
$ kubectl describe gitrepository dummy
...
Status:
  Artifact:
    Checksum:          a0490b2815ea9f2f3c3cfcd04be229496ec23f3a
    Last Update Time:  2021-02-02T12:10:51Z
    Path:              gitrepository/default/dummy/c9ed0e68ebf372c0382d9dcc6b6ce0795076b87f.tar.gz
    Revision:          master/c9ed0e68ebf372c0382d9dcc6b6ce0795076b87f
    URL:               http://source-controller.source-system.svc.cluster.local./gitrepository/default/dummy/c9ed0e68ebf372c0382d9dcc6b6ce0795076b87f.tar.gz
  Conditions:
    Last Transition Time:  2021-02-02T12:10:51Z
    Message:               Fetched revision: master/c9ed0e68ebf372c0382d9dcc6b6ce0795076b87f
    Reason:                GitOperationSucceed
    Status:                True
    Type:                  Ready
  Observed Generation:     1
  URL:                     http://source-controller.source-system.svc.cluster.local./gitrepository/default/dummy/latest.tar.gz
Events:
  Type    Reason  Age   From               Message
  ----    ------  ----  ----               -------
  Normal  info    13m   source-controller  Fetched revision: master/c9ed0e68ebf372c0382d9dcc6b6ce0795076b87f

$ kubectl describe helmchart dummy-chart
...
Status:
  Artifact:
    Checksum:          126fe3b05c02332adbb43c73e9e81f0727724b39
    Last Update Time:  2021-02-02T12:10:51Z
    Path:              helmchart/default/dummy-chart/dummy-0.1.0.tgz
    Revision:          0.1.0
    URL:               http://source-controller.source-system.svc.cluster.local./helmchart/default/dummy-chart/dummy-0.1.0.tgz
  Conditions:
    Last Transition Time:  2021-02-02T12:10:51Z
    Message:               Fetched and packaged revision: 0.1.0
    Reason:                ChartPackageSucceeded
    Status:                True
    Type:                  Ready
  Observed Generation:     1
  URL:                     http://source-controller.source-system.svc.cluster.local./helmchart/default/dummy-chart/dummy-latest.tgz

Is the error you are running into produced by the helm-controller (and reflected on the HelmRelease), or by the GitRepository and/or HelmChart?

Sorry for being not clear: yes the package is available from the source-controller and helm-controller is able to fetch it. But as it is "malformed", helm-controller failed to install it (so testing with helm-release was important to trigger the bug). But I guess you found it

@Zempashi would you be able to confirm hiddeco/source-controller:main-ec05e0e solves the issue for you?

I still get the error of already exists when I try to reconcile both dummy and my jitsi helmrelease, but I can confirm that packages looks good. I tried deleting the helm-controller pods in a hope of flushing some sort of cache, but no luck. Still investigating

Can you provide me the lengthy version of the already exists error message?

I suspect Keyboard-chair problem on my side, but can't find where

Ah !
Deleting the helmrelease and recreated it solved the issue. (Still confuse, why sometimes flux reconcile helmrelease isn't even trying to act on a helmrelease, but that is another story)


Force Close

I Start the app and if i use the live quiz link it was forced closed

As said in: #2
But I will also add an alert, that the URL is wrong, rather than just close the program


not show cart when i cart  1 or more product

hi.
in product page, i have 3 grid table of product by top sale, new product & preloved product.
but when i cart 1 from top sale, new product & preloved product, every cart inserted into DB. but when i click Cart to show product cart. It shows error like below:
ErrorException in CartController.php line 53:
Trying to get property of non-object
in CartController.php line 53
But when i cart nothing, it shows the page total 0 like what it actually does.
Error for localhost/cart:
at HandleExceptions->handleError('8', 'Trying to get property of non-object', 'C:\www\eshop_laravel\app\Http\Controllers\CartController.php', '53', array('cart' => object(Cart), 'items' => object(Collection), 'total' => '0', 'item' => object(CartItem))) in CartController.php line 53
at CartController->showCart()
at call_user_func_array(array(object(CartController), 'showCart'), array()) in Controller.php line 55
at Controller->callAction('showCart', array()) in ControllerDispatcher.php line 44
at ControllerDispatcher->dispatch(object(Route), object(CartController), 'showCart') in Route.php line 189
at Route->runController() in Route.php line 144
at Route->run(object(Request)) in Router.php line 653
at Router->Illuminate\Routing{closure}(object(Request)) in Pipeline.php line 53
at Pipeline->Illuminate\Routing{closure}(object(Request)) in SubstituteBindings.php line 41
at SubstituteBindings->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in Authenticate.php line 43
at Authenticate->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in VerifyCsrfToken.php line 65
at VerifyCsrfToken->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in ShareErrorsFromSession.php line 49
at ShareErrorsFromSession->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in StartSession.php line 64
at StartSession->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in AddQueuedCookiesToResponse.php line 37
at AddQueuedCookiesToResponse->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in EncryptCookies.php line 59
at EncryptCookies->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in Pipeline.php line 104
at Pipeline->then(object(Closure)) in Router.php line 655
at Router->runRouteWithinStack(object(Route), object(Request)) in Router.php line 629
at Router->dispatchToRoute(object(Request)) in Router.php line 607
at Router->dispatch(object(Request)) in Kernel.php line 268
at Kernel->Illuminate\Foundation\Http{closure}(object(Request)) in Pipeline.php line 53
at Pipeline->Illuminate\Routing{closure}(object(Request)) in CheckForMaintenanceMode.php line 46
at CheckForMaintenanceMode->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in Pipeline.php line 104
at Pipeline->then(object(Closure)) in Kernel.php line 150
at Kernel->sendRequestThroughRouter(object(Request)) in Kernel.php line 117
at Kernel->handle(object(Request)) in index.php line 53
at require_once('C:\www\eshop_laravel\public\index.php') in server.php line 21
pls help me. very big thanks for any helpers

Please share the code of your CartController


Icons for Vehicles

Suggestion / feature request
Suggestion / feature request
Hey,
I need an icon to represent driver/vehicle/road for our project, I couldn't find anything close in the icon library.
Can you add some that you think might also help other/future projects?
Thanks!
Examples: All examples are from Tabler Icons
Truck:

Car:

Steering wheel:

Road:

Route:

Hi @CagatayCanK, thanks for your request. On a first sight these icons look very domain specific. We usually add icons to the iX library only if they are obviously helpful for a wide area of domains. But we will discuss this internally and let you know.

After internal discussion we agreed, the icons will be integrated.

Hey @silviowolf ,
Yep, they are very specific, I just need something to represent a truck/driver so just gave some generic icon examples that may be useful for other projects. There is no need to add all of them.
Thanks!

Car/truck driver 😁. Sorry for the confusion.

Following car/driving related icons will be added:


Period Over Period Difference - First Period Should Be Null?

Description
When using the secondary calculation period_over_period and the difference comparison strategy, the first period should most likely be NULL because there is no value that it is being previously compared to. In the current implementation, we coalesce that value to 0 and potentially incorrectly display the value as equal to itself.

Fix
This logic comes from line 27 in secondary_calculation_period_over_period.sql.
{% macro default__metric_comparison_strategy_difference(metric_name, calc_sql) %}
    coalesce({{ metric_name }}, 0) - coalesce({{ calc_sql }}, 0)
{% endmacro %}

We should potentially find some way to determine if it is the first value and, if so, exclude the coalesce from the subtraction.

Closing out this issue as it is not priority and no community members have raised it as a bug. If anyone spots this in the future and wants to re-open this issue, please feel free to do so!


Change expected issuer from retired X3 to active R3

Hey so I think this would indeed fix https://github.com/tozny/rancher-lets-encrypt/issues/42, however,
It seems like this issuer is liable to change at anytime, see https://letsencrypt.org/certificates/ so maybe hardcoding this in isn't the best idea?
We could either look for a more general issuer string like "lets encrypt" or we could make it an ENV variable that maybe contains a comma separated list.
The other thing that comes to mind is that maybe the code should check to see if it IS a lets encrypt certificate, rather than if it IS NOT.  This would make the logic a bit less brittle

:+1

Hey so I think this would indeed fix #42, however,
It seems like this issuer is liable to change at anytime, see https://letsencrypt.org/certificates/ so maybe hardcoding this in isn't the best idea?
We could either look for a more general issuer string like "lets encrypt" or we could make it an ENV variable that maybe contains a comma separated list.
The other thing that comes to mind is that maybe the code should check to see if it IS a lets encrypt certificate, rather than if it IS NOT. Alternatively we could check to see if it is a rancher self signed cert, then otherwise assume it is a lets encrypt cert. This would make the logic a bit less brittle so it doesn't just fall through and create certificates if it doesn't find "R3"

@talecK excellent points, for our use case this is good enough, but if you want to submit a PR with a more robust solution we are happy to review and merge


feat: update as controller board to use EdgeX-3.0

Closes: #132
PR Checklist

[x] Added label to the Pull Request for easier discoverability and search
[x] Commit Message meets guidelines as indicated in the URL https://github.com/intel-retail/automated-vending/blob/main/.github/CONTRIBUTING.md
[x] Every commit is a single defect fix and does not mix feature addition or changes
[ ] Unit Tests have been added for new changes
[ ] Updated Documentation as relevant to the changes
[ ] All commented out code has been removed
[ ] If you've added a dependency, you've ensured license is compatible with repository license and clearly outlined the added dependency.
[ ] PR change contains code related to security
[ ] PR introduces changes that breaks compatibility with other modules (If YES, please provide details below)

What are you changing?

Issue this PR will close
close: #132
Anything the reviewer should know when reviewing this PR?
Test Instructions if applicable

If the there are associated PRs in other repositories, please link them here (i.e. intel-retail/automated-vending )

Remove -tags no_zmq from makefile

Removed


Update revit.md

Update the incorrect hyperlink in the document

Hey @Zhuangkh these changes are not needed, hyperlinks are working.

Hey @Zhuangkh these changes are not needed, hyperlinks are working.

Hi @teocomi, hyperlinks are work in doc website but not in Github or read markdown directly. Internal links should use with file suffix github docs.

I found same issue in other documents, I will modify the others in this PR if you think it is necessary.


Limit output during Charm build (i.e. 'quiet' build)

Original author: Nikhil Jain
Original issue: https://charm.cs.illinois.edu/redmine/issues/408

Currently, during building Charm, almost everything is dumped onto stdout, which may not be necessary. Instead, we can limit what is directed to stdout and print useful info that may help user; rest can go to a log file.

Original date: 2017-10-25 18:31:04

already implemented as --quiet.  Unclear that this should be made a default.


Set auto-complete by default

My team wants to enable auto-complete for all our PR's. We require Product Owner as a PR reviewer and one other developer, and we want the PR to auto-complete when both of these people have approved it.

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

ID: 7cd986e0-608c-1d8c-6faf-ecdb12e10bc6
Version Independent ID: d60c996e-187e-dd6b-7f3a-dd056a1603f4
Content: Protect your Git branches with policies - Azure Repos
Content Source: docs/repos/git/branch-policies.md
Product: devops
Technology: devops-code-git
GitHub Login: @apawast
Microsoft Alias: sdanie

How do we go about configuring this?

@jknapp25  Thank you for the question.
What you describe is a good candidate for service hooks, that are basically web service endpoints triggered by things such as a PR update.
From there you need to handle the endpoint, such as a PowerShell server script combined with Azure CLI commands using the pipelines extension.  The extension allows you to query PR reviewers and update the PR with auto-complete.


Angular Material 2 not loading after install

Bug, feature request, or proposal:
I have followed the GETTING STARTED guide but get the following error:

What is the expected behavior?
I think the @angular/material directory structure should be similar to others such as @angular/common with the directories /bundles, /src, /testing, and with the elements under @angular/material/src, e.g.
@angular/material/src/button
@angular/material/src/button-toggle
What is the current behavior?
The directories /bundles, /src, /testing are missing and the elements are under @angular/material, e.g.
@angular/material/button
@angular/material/button-toggle
What are the steps to reproduce?
Look at the directory @angular/material after npm install --save @angular/material
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: http://plnkr.co/edit/o077B6uEiiIgkC0S06dd
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, browsers are affected?
Is there anything else we should know?
I'm wondering if I need to do something within @angular/material to create the src directory.

I just had to add this to systemjs.config.js
'@angular/material': <EMAIL_ADDRESS>


libuwac/window: Fix memory leak / SIGBUS

UwacWindowShmAllocBuffers() allocates memory with mmap and never frees it
resulting in SIGBUS errors and running out of memory after some time.
Adding a corresponding munmap fixes this issue.
Note that the bus error ist usually triggered later while accessing the mmaped memory, e.g.
#0  __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:419
#1  0x00007ffff7626e46 in  () at /lib/x86_64-linux-gnu/libasan.so.5
#2  0x000055555555fa2f in wlf_copy_image (src=0x7fffd0fdb820, srcStride=15360, srcWidth=3840, srcHeight=2129, dst=0x7ffec1da9000, dstStride=15360, dstWidth=3840, dstHeight=2129, area=0x7fffffffe120, scale=0) at ./client/Wayland/wlfreerdp.c:671
#3  0x000055555555c487 in wl_update_buffer (context_w=0x619000001980, ix=0, iy=0, iw=3840, ih=2129) at ./client/Wayland/wlfreerdp.c:103
#4  0x000055555555cce5 in wl_refresh_display (context=0x619000001980) at ./client/Wayland/wlfreerdp.c:154
#5  0x000055555555e21f in handle_uwac_events (instance=0x616000000380, display=0x612000001b40) at ./client/Wayland/wlfreerdp.c:391
#6  0x000055555555e858 in wlfreerdp_run (instance=0x616000000380) at ./client/Wayland/wlfreerdp.c:468
#7  0x000055555555f6b8 in main (argc=15, argv=0x7fffffffe738) at ./client/Wayland/wlfreerdp.c:633

@freerdp-bot can you test ?

@SaschaWessel check out https://ci.freerdp.com/job/code-quality-checker/582/console for code style changes.

@freerdp-bot test


Move AFFiNE.stable 0.13.1 to Toeverything.AFFiNE 0.13.1

Microsoft Reviewers: Open in CodeFlow

Hash matches, skipping verification.

https://github.com/microsoft/winget-pkgs/pull/153813


Fixes #276 - better messages for typos in rc file

History now reports the field name or bundle name requested if not
found.

This is the commit message #2:

Description

Related Issue

Motivation and Context

How Has This Been Tested?

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)
[X] Trivial change (affects only documentation or cleanup)

Checklist:

[X] I have tested this change with a run of GEOSgcm (if non-trivial)
[X] I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
[X] I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

@tclune I've re-requested reviews from @atrayano and @bena-nasa for this one. I think the updates to develop we've been doing dismissed the stale reviews.


Add image subviews to each tile?

Is it possible to have 2 layers of tile image for each tile?
Each tile in TileView would have 2 views that would use different image depending on its zoom scale.
From: (Normal usage of TileView)
TileView
  - Tile0
      - View A0
  - Tile1
      - View A1
  - Tile2
      - View A2
    ...

To:
TileView
  - Tile0
      - View A0
      - View B0
  - Tile1
      - View A1
      - View B1
  - Tile2
      - View A2
      - View B2
    ...

Your bitmap can be whatever you want, it does not need to be a single file from assets.  Look into the BitmapDecoder interface and how it works - it's totally up to you what Bitmap is returned.
That said, there are no "subviews" - a tile is not an ImageView, and in fact the container is a single view that draws each bitmap to it's canvas.


Some tracks repeats last seconds once the track has ended

Describe the bug
This library is used in a project to play tracks in m3u8 format (HLS). For some reason some tracks is repeating the last seconds once more after the track has ended. In most cases it is the 10 last seconds, which would also be the chunk size of the HLS-chunks.
To Reproduce
Play a track in HLS format. The problem seems to occur most often when a track is not seeked in, it should be played from start to finish for this to occur.
Environment (please complete the following information):
System:
OS: macOS 10.15.5
CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
Memory: 211.06 MB / 16.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 10.6.0 - ~/.nvm/versions/node/v10.6.0/bin/node
Yarn: 1.7.0 - /usr/local/bin/yarn
npm: 6.1.0 - ~/.nvm/versions/node/v10.6.0/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 13.5, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
IDEs:
Android Studio: 4.0 AI-193.69<IP_ADDRESS>14223
Xcode: 11.5/11E608c - /usr/bin/xcodebuild
npmGlobalPackages:
react-native-yunolink: 2.0.2
Using react-native-track-player latest master.
Occurs only on iOS devices and the iOS simulator.

Updated the issue and removed Android as this seems to only be an issue on iOS devices.

Same here, sometimes its stop for a second then start again