text:
ci: Codebuild consolidation with Integ tests

Please note that while we are transitioning from travis-ci to AWS CodeBuild, some tests are run on each platform. Non-AWS contributors will temporarily be unable to see CodeBuild results. We apologize for the inconvenience.
Issue # (if available):
#1854
Description of changes:

Use a new buildspec setup to run multiple Integ tests together (group by libCrypto and runtime)
Improve install_default_deps script to check before installing
Add the GCC4.8 test to one of the other OpenSSL111 integ CodeBuild jobs

From the linked issue, these changes will:

Combine s2nIntegrationLibreSSLGcc9 with s2nIntegrationBoring
Combine s2nIntegrationOpenSSL111Gcc6Corked with s2nIntegrationOpenSSL111Gcc6
Combine s2nIntegrationOpenSSL102Gcc6FIPS with s2nIntegrationOpenSSL102Gcc6
Add Asan on OpenSSL102 to ValgrindOpenSSL102

Job names and Runtimes (from private fork)

s2nIntegrationBoringLibre - Runtime 22min
s2nIntegrationOpenSSL111Plus - Runtime 37min
s2nIntegrationOpenSSL102AsanValgrind - Runtime 29 min
s2nIntegrationOpenSSL102Plus - Runtime 22min

Rollout steps

Merge #1864
Merge #1889
Run ./create_project.py --config integ_codebuild.config
Configure source repo and webhooks on four new jobs
Cleanup travis (future PR)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I didn't see a buildspec for gnuTLS. Is that dependency used in a different way from the other crypto libraries?

From install_default_dependancies it looks like GnuTLS, OpenSSL0.9.8, tox,  linked python and sslyze are installed with every integration or integrationv2 run (and maybe this is a better pattern?).

Codecov Report

Merging #1889 into master will increase coverage by 0.50%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1889      +/-   ##
==========================================
+ Coverage   81.01%   81.52%   +0.50%
==========================================
  Files         230      229       -1
  Lines       17288    17014     -274
==========================================
- Hits        14006    13870     -136
+ Misses       3282     3144     -138

authors: codecov-commenter dougch


text:
Adds a proof harness for the s2n_blob_init function

Please note that while we are transitioning from travis-ci to AWS CodeBuild, some tests are run on each platform. Non-AWS contributors will temporarily be unable to see CodeBuild results. We apologize for the inconvenience.
Resolved issues:
N/A.
Description of changes:

Updates the s2n_blob_is_valid function to consider the case .data == NULL;
Updates the s2n_blob_init function to set .size == 0 if .data == NULL;
Adds a CBMC-proof harness for the s2n_blob_init function;
Adds a series of stubs for the OpenSSL (as part of the CBMC infrastructure).

Call-outs:
The stubs for the OpenSSL library are a copy from the AWS Encryption SDK for C and they are part of the CBMC proof infrastructure. They are essential for any CBMC proof that targets entry points using OpenSSL.
Testing:
N/A.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #1918 into master will decrease coverage by 19.36%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master    #1918       +/-   ##
===========================================
- Coverage   80.84%   61.47%   -19.37%
===========================================
  Files         229      224        -5
  Lines       17152    15686     -1466
===========================================
- Hits        13866     9643     -4223
- Misses       3286     6043     +2757

How many changes have we actually made to the openssl headers? Would it be better as a patch file? Also, I'm not sure what it has to do with s2n_blob_init. Could it instead be a separate PR?

@camshaft We completely replace the implementation of the openSSL functions, adding checks and non-deterministic statements design specifically to the CBMC-proof process. So I'd still keep it as a set of stubs, instead of a patch file (for maintainability). I could certainly add them on a separate PR and make this one depending on it. s2n_blob_init proof harness need some of the stubs as they are included in the building process by errno.h.

How many changes have we actually made to the openssl headers? Would it be better as a patch file? Also, I'm not sure what it has to do with s2n_blob_init. Could it instead be a separate PR?

@camshaft We completely replace the implementation of the openSSL functions, adding checks and non-deterministic statements design specifically to the CBMC-proof process. So I'd still keep it as a set of stubs, instead of a patch file (for maintainability). I could certainly add them on a separate PR and make this one depending on it. s2n_blob_init proof harness need some of the stubs as they are included in the building process by errno.h.

We had to do a similar thing when verifying the aws-encryption-sdk-c.  Longer term, we would like to make a separate git project for these stubs, and submodule it in.

We had to do a similar thing when verifying the aws-encryption-sdk-c. Longer term, we would like to make a separate git project for these stubs, and submodule it in.

Sounds good

source: gharchive/pull-request

authors: camshaft codecov-commenter danielsn feliperodri

license_type: permissive

license_source: github-api


text:
SimpleTable does not support parameterized ProvisionedThroughput r/w capacity

If you create a template that uses parameters to allow the user to specify read/write capacity, the template will fail validation:
SimpleTableExample:
    Type: 'AWS::Serverless::SimpleTable'
    Properties:
      PrimaryKey:
          Name: MyPrimaryKey
          Type: String
      ProvisionedThroughput:
        ReadCapacityUnits: !Ref ReadCapacityUnitsParam
        WriteCapacityUnits: !Ref WriteCapacityUnitsParam

Generates the error
Resource with id [SimpleTableExample] is invalid. Type of property 'ProvisionedThroughput' is invalid.
I suspect that this is due to the fact that !Ref-ed parameters are converted to string and the schema for the SimpleTable resource specifies the r/w capacity as a number. Hard-coding numbers in there works (but is not desired).
Is there a workaround for this?

@hoppersoft Sorry for the late reply. Things up to re:invent were crazy!
Anyways, to your issue. This is a result of our poor support (at the moment) for intrinsic functions. Currently, we are validating that the ReadCapacityUnits and WriteCapacityUnits' values are int. In your case, they are strings. We should totally be supporting intrinsics in this case. We started realizing this some time ago and have tried to make additions to the template compatible with intrinsics to start but we haven't yet gone back to all the existing ones (one of them being SimpleTable). Glancing at the code, this doesn't seem like a huge change at all. I can't promise I will get to it right away (juggling a couple different things at the moment) but will see how I can get this prioritized in the near future. I will comment back when I start to work on this.
As far as a workaround: Sadly, hardcoding the capacity as a number in the resource is the best I have to offer.

This support was added in the most recent update. Looks like it got missed in the Release Notes. But you can now use intrinsics for ReadCapacityUnits and WriteCapacityUnits.

source: gharchive/issue

authors: hoppersoft jfuss

repo: awslabs/serverless-application-model


text:
fix: ref for autopublish code sha

Issue #, if available:
#1536
Description of changes:
Description of how you validated changes:
Checklist:

[x] Write/update tests
[x] make pr passes
[ ] Update documentation
[x] Verify transformed template deploys and application functions as expected
[ ] Add/update example to examples/2016-10-31

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #1537 into develop will decrease coverage by 0.03%.
The diff coverage is 33.33%.

@@             Coverage Diff             @@
##           develop    #1537      +/-   ##
===========================================
- Coverage    94.10%   94.06%   -0.04%
===========================================
  Files           78       78
  Lines         4951     4953       +2
  Branches       999     1000       +1
===========================================
  Hits          4659     4659
- Misses         135      136       +1
- Partials       157      158       +1

Impacted Files
Coverage Δ

samtranslator/model/sam_resources.py
93.93% <33.33%> (-0.39%)
:arrow_down:

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 1b2d6f2...1b02cad. Read the comment docs.

authors: ShreyaGangishetty codecov-io


text:
[Python] Support event streaming trait

Support Smithy event streaming trait.

Plus one on this.
Yes please!

Now that union support have been merged (https://github.com/awslabs/smithy-rs/pull/2427) we are confident we can deliver event streaming support. I don't have a timeline, but should happen soon.

authors: XiangyangShi crisidev

repo: awslabs/smithy-rs


text:
Spring Cloud SQS only consume 10 messages in parallel even though maxConcurrentMessages have a greater value

Type: Bug
Component:
"SQS"
Describe the bug
I used the @SQSListener annotation and defined the maxConcurrentMessages parameter to 100. When consuming messages I first produced 100 messages and then consumed them via an spring cloud app. When looking at the logs and the threads involved I never noticed more than 10 threads consuming messages in parallel.
After further investigation I noticed that the threadPool created by the default listener has a core number of threads set to 10, the max number to 100,  and the queueCapacity to 100, but it never added more threads to the pool than the core number because it requires the queue to be full. That never happens because the logic to poll the sqs queue will never ask for more messages than permits and this will never be more than 100.
To work around that, I used a custom threadpool stack with the core number set to 100. With that it nicely consumed those 100 messages in parallel.

Thanks @dbeltranruiz, we're aware of this, and has been addressed in this PR:
https://github.com/awspring/spring-cloud-aws/pull/833
3.0.2 should be out soon with this fix.
cc: @maciejwalkowiak

authors: dbeltranruiz tomazfernandes

repo: awspring/spring-cloud-aws


text:
by default directly load xarray stacks

This greatly improves performance of netCDF user upload processing

Pull Request Test Coverage Report for Build 3984349064

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.03%) to 92.42%

Totals

Change from base Build 3975892611:
-0.03%

Covered Lines:
1581

Relevant Lines:
1690

💛  - Coveralls

authors: coveralls s-scherrer

license: MIT


text:
chore: add marketing form

Description
Closes AXE-3643
Supports #278
This PR simply adds a marketing typeform in the next line.

It's probably better to push these links live first, then spending time improve the ui later in a separate pr

@npty somehow this became merge conflicted, can you fix this in the branch?

authors: canhtrinh npty

repo: axelarnetwork/axelarjs


text:
🛑 Webhost prancer is down

In d63a327, Webhost prancer ($URL_BLITZEN) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Webhost prancer is back up in 91750f8 after 6 minutes.

repo: axinjanet/upptime


text:
fix(telescope): pass opts from direct func call

Let telescope opts priority order be:

opts arg from a function call
telescope table from the user defined config
default hbac.config.values.telescope opts

Say you want call the picker with a function call instead of using :Telescope hbac buffers e.g. require('telescope').extensions.hbac.buffers(opts) or require('hbac.telescope').pin_picker(opts).
The current parse_opts function overwrites opts.mappings with the merged default_mappings + telescope_opts.mappings tables.
opts.mappings = telescope_opts.use_default_mappings
  and vim.tbl_deep_extend('force', { i = default_mappings, n = default_mappings }, telescope_opts.mappings or {})
  or (telescope_opts.mappings or {})

The function prioritizes other options from a function call (e.g. if you set sort_lastused = false, it will override the config default), but it doesn't account for any potential value of opts.mappings before the assignment above.
In 610a604 the priority order was as described above and currently in the README, but I forgot to check for that when we switched to the Telescope extension. This PR should restore that:
local parse_opts = function(opts)
  -- by this point, user's config opts > default opts
  local telescope_opts = require("hbac.config").values.telescope
  if telescope_opts.use_default_mappings then
    default_mappings = { i = default_mappings, n = default_mappings }
    -- user defined mappings > default mappings
    telescope_opts.mappings = vim.tbl_deep_extend("force", default_mappings, telescope_opts.mappings)
  end
  -- opts/mappings from function args (if any) > config opts/mappings
  return vim.tbl_deep_extend("force", telescope_opts, opts)
end

I also set the default telescope.mappings value to {} instead of nil to spare some 'check for nil' conjunctions (lua_ls and luacheck aren't complaining about that, do I have a bad config?).

sample lazy.nvim config
return {
  -- "axkirillov/hbac.nvim",
  "al-ce/hbac.nvim",
  branch = "telescope/config-override",
  opts = {
    telescope = {
      mappings = {
        i = { ["<M-z>"] = function() print("Hello hbac") end, },
      }
    }
  },
  keys = {
    {
      ",ht",
      function()
        require('telescope').extensions.hbac.buffers({
          sort_lastused = false,  -- should override default
          mappings = {
            i = {
              ["<M-z>"] = function() print("Goodbye hbac") end,  -- should override above mappings
              ["<M-j>"] = function() print("Where am I?") end,
            },
          },
        })
      end,
      desc = "Hbac: Telescope",
    },
  }
}

@Nimjii could you take a look at this if you have time?

Yeah, it looks good to me. Didn't really consider that, my bad. ^^

Yeah, it looks good to me. Didn't really consider that, my bad. ^^

No worries, I forgot too and it's probably a rare case. Most everyone would just set their telescope opts in the setup config. But maybe you'd want this for per-project/per-filetype mappings

authors: Nimjii al-ce


text:
properly detect if "init" hasn't been run

The only reason you "must" run init is to ensure --profile=dist works. I don't think there's any way to ask cargo if that profile is defined, so there are three options:

parse the Cargo.tomls and try to find the definition (will erroneously fail if the profile is specified totally globally... but also that won't work when checked in anyway so they're still wrong?)
??? is there some info in cargo-metadata about defined profiles ???
parse the error message from rustc/cargo for the "hey the dist profile doesn't exist" to provide a better diagnostic

i think parsing the cargo-toml here feels right to me though i'll admit i didn't even consider that someone would define the profile globally. is that a thing people commonly do? regardless, if a globally defined profile won't work, it stands to reason that not being able to detect it by reading the cargo.toml is a feature.
as an aside "cargo-metaprofile" is available on crates.io

authors: Gankra ashleygwilliams

repo: axodotdev/cargo-dist


text:
refactor: impl Trie for MPTTrie

What this PR does / why we need it?

I want to add methods to MPTTrie<DB> in another crate.
Limit by the orphan rule, I have to use a trait to add methods to MPTTrie<DB>.

If I use a trait to add methods to MPTTrie<DB>, I could NOT write the following code:
pub trait TrieExt<BD>: MPTTrie<DB> {
    /* Use methods of `MPTTrie<DB>` in trait body. */
}

, since MPTTrie<DB> is a struct, but I can write the following code:
pub trait TrieExt: Trie {
    /* Use methods of `Trie` in trait body. */
}

Some methods of MPTTrie<DB> are not exposed, for example, get_proof(..) and verify_proof(..).

Another reason:
In fact, MPTTrie<DB> is a Trie, we should use it as Trie directly.
Trie is in a higher level of TrieDB in abstract.
Treat MPTTrie<DB> as as a TrieDB is not reasonable.

What is the impact of this PR?
No Breaking Change

CI Settings

CI Usage
Tip: Check the CI you want to run below, and then comment /run-ci.
CI Switch

[ ] Coverage Test
[x] E2E Tests
[x] Code Format
[x] Web3 Compatible Tests
[x] OCT 1-5 And 12-15
[x] OCT 6-10
[x] OCT 11
[x] OCT 16-19
[x] v3 Core Tests

CI Description

CI Name
Description

Chaos CI
Test the liveness and robustness of Axon under terrible network condition

Cargo Clippy
Run cargo clippy --all --all-targets --all-features

Coverage Test
Get the unit test coverage report

E2E Test
Run end-to-end test to check interfaces

Code Format
Run cargo +nightly fmt --all -- --check and cargo sort -gwc

Web3 Compatible Test
Test the Web3 compatibility of Axon

v3 Core Test
Run the compatibility tests provided by Uniswap V3

OCT 1-5 | 6-10 | 11 | 12-15 | 16-19
Run the compatibility tests provided by OpenZeppelin

The MPTTrie in wrapped.rs seems useless after this changes. Consider removing it.

The MPTTrie in wrapped.rs seems useless after these changes, consider removing it by the following:
pub type MPTTrie<DB: trie::DB> = trie::PatriciaTrie<DB, HasherKeccak>;

authors: KaoImin yangby-cryptape


text:
Follow the setup guide, but not work

the error is
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to chatgpt-api.xxx.workers.dev:443

Is there a step I've missed?

It is my network problem


text:
[feat] 功能建议

Describe the problem

现在软件为安装形式，数据库也保存在用户目录里
呼出菜单后的操作；

Describe the solution you'd like

希望软件做成绿色软件，数据库保存在软件目录里；
呼出菜单后希望鼠标点击选项上屏，点击哪个复制选项哪个就能输出到光标处；
感谢作者设计的软件。

Alternatives considered
No response
Additional context
No response

收到反馈
1、这个功能不会考虑，因为我们都是通过 ci 完成打包的，只能打包出 msi 的安装包，内置更新功能，方便许多！
2、Duplicate of #29 ，这个问题正在研究，敬请期待！

#169 回填功能已实现，期待下个版本！

authors: Norman-Jean ayangweb

repo: ayangweb/EcoPaste


text:
Change where this tool outputs build results (i.e. resulting files) to [Feature Request]

While using this tool, I have noticed that when building the files, the result (i.e. resulting files) of the build are outputted into a folder called "build" which is then stored in the output folder located at the path specified by the output argument.
As a result, I was wondering if the behavior of this tool could be updated such that the result (i.e. resulting files) of the build would be directly outputted into the output folder located at the path specified by the output argument?
If necessary, I can provide further elaborations and details regarding this feature request.

Hey, thanks for the feature request. Yes I can indeed add this option shouldn't be a problem.
Just wondering is this a duplicate of https://github.com/ayecue/greybel-js/issues/177 since the description sounds pretty similar or is there any difference?

Hey, thanks for the feature request. Yes I can indeed add this option shouldn't be a problem.
Just wondering is this a duplicate of #177 since the description sounds pretty similar or is there any difference?

Hi there, thank you.
This issue is not a duplicate of #177, in face, #177 is a separate issue which is why I had created a separate issue for it.
#177 is concerned with the fact that the tool currently outputs a folder called "build" in the specified output folder, instead of just placing the built files (i.e. the files resulting from the build such as the installer file and the minified source code file) directly into the specified output folder. Hence, this issue is not a duplicate of #177 and is instead a separate issue from #177.

Hey, thanks for the feature request. Yes I can indeed add this option shouldn't be a problem.
Just wondering is this a duplicate of #177 since the description sounds pretty similar or is there any difference?

Hi there, thank you and thanks for the response.
With regards to your question, in theory, this issue and #177 are not duplicates of one another. However, if this issue is resolved, then #177 would pretty much no longer be an issue.

In order to keep backwards compatibility I've decided instead to introduce a option called --no-build-folder instead. By using that option it will put the output directly into the destination folder without wrapping it into a build folder. It will be part of 3.2.16.

In order to keep backwards compatibility I've decided instead to introduce a option called --disable-build-folder. By using that option it will put the output directly into the destination folder without wrapping it into a build folder. It will be part of 3.2.16.

I see, thanks.

Should be available now with 3.2.16 released.

I see, thank you.

Since this issue has been resolved in 3.2.16, I will close it.
Thanks again for helping to resolve the issue.

repo: ayecue/greybel-js


text:
chore: fix typo in prompts.py

anaylze -> analyze

Good catch!
Such small typos can make a bigger difference than one might think. Thank you for your contribution!

authors: aymenfurter eltociear

repo: aymenfurter/microagents


text:
Update Frontend to use new project bounds

After https://github.com/azavea/raster-foundry/issues/999 we should be able to simplify some operations on the frontend.

Closed by #1149

authors: alkamin notthatbreezy

repo: azavea/raster-foundry

license_source: bigquery


text:
Disable the project upload functionality, if user doesn't have the right permissions.

Detailed changes:

Upload button is enabled only for admin users and users with UPLOADPROJECTS
permission when the property 'lockdown.upload.projects' is set to true.
New permission UPLOADPROJECTS is created
Handle the case for ajax upload as well
Tests included

Verified all changes against the azkaban-solo-server.

Does it allow admin to upload projects?

@ameyamk - It will!

It doesn't look like we have complete automated tests that would verify that this feature will work once all tests pass. Can you improve? I understand that you may have to build necessary supporting testing infrastructure to do so.

@HappyRay - I have added additional tests which checks for the permissions. Please review.

Thanks for the update.
If you use IDE to check the line coverage, you can see which lines you added have no test coverage.
e.g.
It seems that if we remove the check in the web server code all the tests will still pass.

@HappyRay - Have added tests for all the methods added - checked with the code coverage tool in IDE. Applied the 'Save Actions' plugin along with the recommended code style. Please review.

Could you update the relevant documentation after this change is merged?

@HappyRay - I have made the fixes that you suggested. I will update the documentation once the change is merged.

Could you update the change description?
"Upload button is disabled from the UI if 'lockdown.upload.projects' is set to true
or if the user doesn't have the necessary permissions." doesn't seem to be right.

@HappyRay - Updated with change description and other outstanding comments. Please merge if all looks good!

Thanks!

I updated the pull request description to match the commit message.

authors: HappyRay ameyamk rajagopr

repo: azkaban/azkaban


text:
🛑 Sukri Online is down

In 8a1b4fc, Sukri Online (https://discord-aklx.onrender.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sukri Online is back up in c0070cc after 14 minutes.

repo: azrielbsi/monitor


text:
🛑 Sukri Online is down

In 79ffb18, Sukri Online (https://discord-aklx.onrender.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sukri Online is back up in 657ea70 after 9 minutes.


text:
🛑 azuma doa: Mailing Service is down

In d2087a3, azuma doa: Mailing Service (https://pie.azuma-health.tech/health/doa-mailing) was down:

HTTP code: 0
Response time: 0 ms

Resolved: azuma doa: Mailing Service is back up in 4e188da after 57 minutes.

repo: azuma-healthtech-public/uptime-pie


text:
Add a batch analysis mode

Description
Add a batch analysis mode that scans multiple Solidity files and produces a combined report.
Implementation
I'm not 100% sure about how to best explore this feature to users. Some options are:

Accept multiple filename/contract, i.e.

$ sabre <file1.sol>[:contractName1] <file2.sol>[:contractName2]

This would allow the user to do bash stuff like find ./ -name "*.sol" | xargs sabre or save the a Sabre command line as a shell script to repeatedly analysis a whole repo.

Accept an input directory, traverse the directory recursively to find and analyze all .sol files.

This would be convenient but would cost the user some control. One question is how we would handle .sol files containing multiple contract classes. We'd probably also need a feature to exclude specific contracts etc.

I prefer the first option, it would allow doing things like sabre contracts/*.sol which is pretty typical.

Should we preserve polling delays, or should we reconsider this logic for batch mode?

authors: b-mueller blitz-1306 maurelian

repo: b-mueller/sabre


text:
flaky when used with gke clusters

First time I run this on 3 GKE clusters that are alive, I get 1 cluster. Second time I run it I get 3 clusters.
First time I run (with missing clusters) I saw this:
$ kubectl config-cleanup
E0813 10:11:17.775025    6318 round_trippers.go:174] CancelRequest not implemented by *gcp.conditionalTransport

I think this plugin has a wait timeout, and cancels after a while. GKE clusters use gcloud command to get a token (and cache it for an hour), so sometimes it can take several seconds to do something if you haven't used the cluster from that machine for a while.
I think the wait should be increased?

The default wait timeout is set to 3s. I opted to keep it low because users would have to wait the full duration if one of the clusters is going to timeout, though this doesn't seem to happen as often as I expected, so I'm open to increasing the default. How about 7s instead?
In the short term, there's a --timeout cli option to override the default
As for the error log, it looks like https://github.com/kubernetes/kubernetes/issues/73791 is still being investigated so I don't think I can fix that here

10s is actually much better if you print something to stderr  indicating progress.

authors: ahmetb dbkegley


text:
Test host process crashed : Stack overflow.

When the test runs on a server it crashes. (I have not seen it crash locally.)
The test makes a selection in a dropdown and verifies the proper effect. Then it makes a second selection in the same dropdown and verifies whether the page responds properly.
Here is the stack dump:
The active test run was aborted. Reason: Test host process crashed : Stack overflow.
at System.RuntimeFieldHandle.GetValue(System.Reflection.RtFieldInfo, System.Object, System.RuntimeType, System.RuntimeType, Boolean ByRef)
at System.Reflection.RtFieldInfo.GetValue(System.Object)
at System.ValueType.Equals(System.Object)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForAttributeFrame(DiffContext ByRef, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendAttributeDiffEntriesForRange(DiffContext ByRef, Int32, Int32, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForFramesWithSameSequence(DiffContext ByRef, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForRange(DiffContext ByRef, Int32, Int32, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForFramesWithSameSequence(DiffContext ByRef, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForRange(DiffContext ByRef, Int32, Int32, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForFramesWithSameSequence(DiffContext ByRef, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForRange(DiffContext ByRef, Int32, Int32, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForFramesWithSameSequence(DiffContext ByRef, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForRange(DiffContext ByRef, Int32, Int32, Int32, Int32)
at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.ComputeDiff(Microsoft.AspNetCore.Components.RenderTree.Renderer, Microsoft.AspNetCore.Components.Rendering.RenderBatchBuilder, Int32, Microsoft.AspNetCore.Components.RenderTree.ArrayRange1<Microsoft.AspNetCore.Components.RenderTree.RenderTreeFrame>, Microsoft.AspNetCore.Components.RenderTree.ArrayRange1<Microsoft.AspNetCore.Components.RenderTree.RenderTreeFrame>)
at Microsoft.AspNetCore.Components.Rendering.ComponentState.RenderIntoBatch(Microsoft.AspNetCore.Components.Rendering.RenderBatchBuilder, Microsoft.AspNetCore.Components.RenderFragment)
at Microsoft.AspNetCore.Components.RenderTree.Renderer.RenderInExistingBatch(Microsoft.AspNetCore.Components.Rendering.RenderQueueEntry)
at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()
at Bunit.Rendering.TestRenderer.ProcessPendingRender()
at Microsoft.AspNetCore.Components.RenderTree.Renderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at Bunit.Rendering.TestRenderer+<>c__DisplayClass15_0.b__0()
at Bunit.Rendering.TestRenderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at System.Linq.Enumerable+SelectListIterator2[[System.UInt64, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ToArray()    at Bunit.TriggerEventDispatchExtensions.TriggerBubblingEventAsync(Bunit.Rendering.ITestRenderer, AngleSharp.Dom.IElement, System.String, System.EventArgs)    at Bunit.FocusEventDispatchExtensions.FocusIn(AngleSharp.Dom.IElement, System.String)    at ICMD.Test.UI.Pages.PCOExtensions.CostCodeCount(Bunit.IRenderedComponent1<ICMD.Pages.PCO>)
at ICMD.Test.UI.Pages.PCOTests+<>c__DisplayClass14_0.<Story_1b>b__2()
at Bunit.Extensions.WaitForHelpers.WaitForAssertionHelper+<>c__DisplayClass7_0.<.ctor>b__0()
at Bunit.Extensions.WaitForHelpers.WaitForHelper.OnAfterRender(System.Object, System.EventArgs)
at Bunit.Rendering.RenderedFragment.Bunit.IRenderedFragmentBase.OnRender(Bunit.Rendering.RenderEvent)
at Bunit.Rendering.TestRenderer.UpdateDisplayAsync(Microsoft.AspNetCore.Components.RenderTree.RenderBatch ByRef)
at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()
at Bunit.Rendering.TestRenderer.ProcessPendingRender()
at Microsoft.AspNetCore.Components.RenderTree.Renderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at Bunit.Rendering.TestRenderer+<>c__DisplayClass15_0.b__0()
at Bunit.Rendering.TestRenderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at System.Linq.Enumerable+SelectListIterator2[[System.UInt64, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ToArray()    at Bunit.TriggerEventDispatchExtensions.TriggerBubblingEventAsync(Bunit.Rendering.ITestRenderer, AngleSharp.Dom.IElement, System.String, System.EventArgs)    at Bunit.FocusEventDispatchExtensions.FocusIn(AngleSharp.Dom.IElement, System.String)    at ICMD.Test.UI.Pages.PCOExtensions.CostCodeCount(Bunit.IRenderedComponent1<ICMD.Pages.PCO>)
at ICMD.Test.UI.Pages.PCOTests+<>c__DisplayClass14_0.<Story_1b>b__2()
at Bunit.Extensions.WaitForHelpers.WaitForAssertionHelper+<>c__DisplayClass7_0.<.ctor>b__0()
at Bunit.Extensions.WaitForHelpers.WaitForHelper.OnAfterRender(System.Object, System.EventArgs)
at Bunit.Rendering.RenderedFragment.Bunit.IRenderedFragmentBase.OnRender(Bunit.Rendering.RenderEvent)
at Bunit.Rendering.TestRenderer.UpdateDisplayAsync(Microsoft.AspNetCore.Components.RenderTree.RenderBatch ByRef)
at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()
at Bunit.Rendering.TestRenderer.ProcessPendingRender()
at Microsoft.AspNetCore.Components.RenderTree.Renderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at Bunit.Rendering.TestRenderer+<>c__DisplayClass15_0.b__0()
at Bunit.Rendering.TestRenderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at System.Linq.Enumerable+SelectListIterator2[[System.UInt64, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ToArray()    at Bunit.TriggerEventDispatchExtensions.TriggerBubblingEventAsync(Bunit.Rendering.ITestRenderer, AngleSharp.Dom.IElement, System.String, System.EventArgs)    at Bunit.FocusEventDispatchExtensions.FocusIn(AngleSharp.Dom.IElement, System.String)    at ICMD.Test.UI.Pages.PCOExtensions.CostCodeCount(Bunit.IRenderedComponent1<ICMD.Pages.PCO>)
at ICMD.Test.UI.Pages.PCOTests+<>c__DisplayClass14_0.<Story_1b>b__2()
at Bunit.Extensions.WaitForHelpers.WaitForAssertionHelper+<>c__DisplayClass7_0.<.ctor>b__0()
at Bunit.Extensions.WaitForHelpers.WaitForHelper.OnAfterRender(System.Object, System.EventArgs)
at Bunit.Rendering.RenderedFragment.Bunit.IRenderedFragmentBase.OnRender(Bunit.Rendering.RenderEvent)
at Bunit.Rendering.TestRenderer.UpdateDisplayAsync(Microsoft.AspNetCore.Components.RenderTree.RenderBatch ByRef)
at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()
at Bunit.Rendering.TestRenderer.ProcessPendingRender()
at Microsoft.AspNetCore.Components.RenderTree.Renderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at Bunit.Rendering.TestRenderer+<>c__DisplayClass15_0.b__0()
at Bunit.Rendering.TestRenderer.DispatchEventAsync(UInt64, Microsoft.AspNetCore.Components.RenderTree.EventFieldInfo, System.EventArgs)
at System.Linq.Enumerable+SelectListIterator`2[[System.UInt64, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=5.0.0.0, Culture=neu ...
The selection in the (project) dropdown is done like so:
public static void SelectProject(this IRenderedComponent<ICMD.Pages.PCO> cut, int projectID)
{
var projectSelectElement = cut.Find(ProjectSelector);
projectSelectElement.Change(new ChangeEventArgs() { Value = projectID.ToString() });
}
The verification of the effect (proper number of cost codes in a typeahead) is done like so:
public static int CostCodeCount(this IRenderedComponent<ICMD.Pages.PCO> cut)
{
try
{
// We need to give the Typeahead element focus for the Cost Codes to show up
var costCodeSelectElement = cut.Find($"{CostCodeSelector} > div.typeahead input");
costCodeSelectElement.FocusIn();
return cut.FindAll($"{CostCodeSelector} > div.typeahead div.typeahead-items ul li")?.Count ?? 0;
}
catch (ElementNotFoundException)
{
}
return 0;
}

Additionally:
The test seems to crash on the first dropdown selection because if I comment out the second, it still crashes (in the same spot).
Probably not important:
This is part of a suite of 223 tests. If I comment out 20 of these, the crash still happens (in the same spot).

Hi @mschluper
Please follow the "bug" issues template when submitting issues of this kind, otherwise it's close to impossible to help you. Make sure you answer all the relevant questions (os, versions etc.).
In this particular case, I will need a small sample project that reproduces the error, otherwise it will be hard to impossible for me to troubleshoot.
Ps. It's also improves readability of code significantly if you use but code and dumps into code blocks in markdown. Check out githubs markdown guide if you dont know how.

OK. Thank you.
I'll attempt to construct "a small sample project that reproduces the error" but as I said, I cannot reproduce this on localhost. It has to wait till the weekend.

I have not been able to reproduce this locally.
And even on the server it happens only once every 20 times.

Ok. Thanks for the update.
Judging from what is legible in the stack trace, your code is looping inside the Blazor renderer, out side of bunit's control, so you might have a component that continues to re render in a loop, e.g. because StateHasChanged is called, or similar.

authors: egil mschluper

repo: bUnit-dev/bUnit


text:
6.14.0

https://github.com/babel/babylon/blob/9043de97ea32ccadd172aa05eb71cbc906ec2302/CHANGELOG.md

Current coverage is 97.69% (diff: 100%)

Merging #221 into master will not change coverage

@@             master       #221   diff @@
==========================================
  Files            19         19
  Lines          3214       3214
  Methods         336        336
  Messages          0          0
  Branches        838        838
==========================================
  Hits           3140       3140
  Misses           30         30
  Partials         44         44

Powered by Codecov. Last update c30a556...9043de9

authors: codecov-io danez

repo: babel/babylon

license: mit


text:
Fix the saving of the description

At the API level, the title is called "description", and the description is called "extended". The library was placing the title in the API description (correct) and then overwriting it with the description, when it should have been placing it in "extended".

As soon as works for you, works for me. 🙂

@davep 2023.11.1 has been cut.

authors: bachya davep

repo: bachya/aiopinboard


text:
Test image resolution

Hello, I am confused about resolution recently.
When I limited the resolution of the test image, I found that different resolutions would bring different effects. I currently speculate that the influencing factors are the resolution of the original image and the parameter setting of resize（）
I wonder if you have any research experience in this kind of question？
Looking forward to your reply

Resize() will usually cause different outputs as the network's receptive field on the objects in the input image changes as well.
This can be avoided by :

zero-padding the images that are too small;
setting the parameter ceil_mode=True in torch.nn.AvgPool2d().

The 1st solution is easy to understand and use, while the 2nd one can solve the problem of 'input image is too small' permanently but you'd better re-train the network (my suggestion).

Resize() will usually cause different outputs as the network's receptive field on the objects in the input image changes as well.
This can be avoided by :

zero-padding the images that are too small;
setting the parameter ceil_mode=True in torch.nn.AvgPool2d().

The 1st solution is easy to understand and use, while the 2nd one can solve the problem of 'input image is too small' permanently but you'd better re-train the network (my suggestion).

Thanked your reply.If I have a higher resolution image, For resolution reduction solutions，Do you have any Suggestions？

You can try to resize the high-resolution image to lower ones and forward it to the network, or crop the image in a sliding-window manner and then stitch the patches.

repo: backseason/PoolNet


text:
Scaffolder API uses incorrect baseUrl to request parameter-schema in production build

Expected Behavior
When I click on the "CHOOSE" button of a template, it should fetch the template parameter schema and render the result in the UI.
Actual Behavior
I visit https://<our_staging_domain>/create?filters%5Bkind%5D=template&filters%5Buser%5D=all and can see templates.
When I click on the "CHOOSE" button of any of the templates, it shows a 500 Fetch error.
.
Steps to Reproduce

Install Backstage

Add code for scaffolder

packages/backend/src/plugins/scaffolder.ts
Nothing special, basically follow the Backstage doc but with some my custom actions:
imports ...

export default async function createPlugin({
  logger,
  config,
  database,
  reader,
  discovery,
}: PluginEnvironment): Promise<Router> {
  const catalogClient = new CatalogClient({ discoveryApi: discovery });
  const integrations = ScmIntegrations.fromConfig(config);
  const builtInActions = createBuiltinActions({
    integrations,
    config,
    catalogClient,
    reader,
  } as unknown as CreateBuiltInActionsOptions);
  const actions = [
    ...builtInActions,
    createFetchMpTemplateAction({ reader, integrations }),
    createRegisterMpBackendAction({ config }),
  ];

  return await createRouter({
    logger,
    config,
    database,
    catalogClient,
    reader,
    actions,
  });
}

packages/backend/src/plugins/catalog.ts
imports ...
export default async function createPlugin(
  env: PluginEnvironment,
): Promise<Router> {
  const builder = await CatalogBuilder.create(env);

  builder.addProcessor(new ScaffolderEntitiesProcessor());
  const { processingEngine, router } = await builder.build();
  await processingEngine.start();

  return router;
}

packages/backend/src/index.ts
function makeCreateEnv(config: Config) {
  ...
  const discovery = SingleHostDiscovery.fromConfig(config);
  ...
}
async function main() {
  const config = await loadBackendConfig({
    argv: process.argv,
    logger: getRootLogger(),
  });
  const createEnv = makeCreateEnv(config);

  const catalogEnv = useHotMemoize(module, () => createEnv('catalog'));
  const scaffolderEnv = useHotMemoize(module, () => createEnv('scaffolder'));
  ...
}

app-config.yaml
backend:
  baseUrl: https://engx.stg.linkedin.com
  https:
    certificate:
      cert:
        $file: var/identity.cert
      key:
        $file: var/identity.key
  listen:
    port: 17206
  csp:
    connect-src: ["'self'", 'http:', 'https:']
    img-src:
      - "'self'"
      - 'data:'
      - 'https://jira01.corp.linkedin.com:8443'
  cors:
    origin: ['https:localhost:17205','https://localhost:17206', 'https://engx.stg.linkedin.com/']
    methods: [GET, POST, PUT, DELETE]
    credentials: true
  database:
    client: pg
...
catalog:
  rules:
    - allow: [Component, System, API, Group, User, Resource, Location, Template]
  locations:
    - type: file
      target: ./scaffolder-templates/all-templates.yaml

Context
Backend Error
The scaffolder error happens in https://<our_staging_domain>/api/scaffolder/v2/templates/default/template/js-library/parameter-schema.
https://<our_staging_domain>/api/scaffolder/v2/templates/default/template/js-library/parameter-schema:
{
  "error": {
    "name": "FetchError",
    "message": "request to https://localhost:17206/api/catalog/entities/by-name/template/default/js-library failed, reason: unable to verify the first certificate",
    "type": "system",
    "errno": "UNABLE_TO_VERIFY_LEAF_SIGNATURE",
    "code": "UNABLE_TO_VERIFY_LEAF_SIGNATURE",
    "level": "error",
    "service": "backstage"
  },
  "request": {
    "method": "GET",
    "url": "/api/scaffolder/v2/templates/default/template/js-library/parameter-schema"
  },
  "response": {
    "statusCode": 500
  }
}

However, the actual paramter-schema record exists in https://<our_staging_domain>/api/scaffolder/v2/templates/default/template/js-library/parameter-schema
https://<our_staging_domain>/api/scaffolder/v2/templates/default/template/js-library/parameter-schema:
{
  "metadata": {
  "namespace": "default",
  "annotations": {
  "backstage.io/managed-by-location": "file:/export/content/lid/apps/engx-web/bf8320889add4c7fa513dc9515dd05f88cc8f9c9/scaffolder-templates/js-library-scaffolder-template.yaml",
"backstage.io/managed-by-origin-location": "file:/export/content/lid/apps/engx-web/bf8320889add4c7fa513dc9515dd05f88cc8f9c9/scaffolder-templates/all-templates.yaml"
  },
  "name": "js-library",
  "title": "js-library",
  "description": "JavaScript library creation template (js-library)",
  "tags": [
     "multiproduct"
  ],
  "uid": "c551d2cd-67bb-4906-8cd1-21599ded6016",
  "etag": "d7c5be207c2c435f5976f6de94f72065fb3794cb"
  },
"apiVersion": "scaffolder.backstage.io/v1beta3",
"kind": "Template",
....

I got a feeling that discoverApi did not return the correct baseUrl in scaffolder in https://github.com/backstage/backstage/blob/master/plugins/scaffolder/src/api.ts#L136. However, I'm not sure what is missing in my configurations / code.
Your Environment

Browser Information:

Output of yarn backstage-cli info:

node: v16.13.0
yarn: 1.22.17
cli:  0.16.0 (installed)

Dependencies:
  @backstage/app-defaults                    1.0.0
  @backstage/backend-common                  0.13.1
  @backstage/backend-tasks                   0.2.1
  @backstage/catalog-client                  0.6.0, 0.7.2, 1.0.0, 1.0.2
  @backstage/catalog-model                   0.10.1, 0.11.0, 0.9.10, 1.0.0, 1.0.2
  @backstage/cli-common                      0.1.8
  @backstage/cli                             0.16.0
  @backstage/config-loader                   1.0.0
  @backstage/config                          0.1.15, 1.0.0, 1.0.1
  @backstage/core-app-api                    1.0.0
  @backstage/core-components                 0.8.10, 0.9.3, 0.9.2, 0.9.4
  @backstage/core-plugin-api                 0.6.1, 0.7.0, 0.8.0, 1.0.0, 1.0.1, 1.0.2
  @backstage/dev-utils                       1.0.0
  @backstage/errors                          0.2.2, 1.0.0
  @backstage/integration-react               0.1.25, 1.0.0
  @backstage/integration                     0.7.5, 0.8.0, 1.1.0, 1.2.0
  @backstage/plugin-api-docs                 0.8.3
  @backstage/plugin-app-backend              0.3.30
  @backstage/plugin-auth-backend             0.12.3
  @backstage/plugin-auth-node                0.1.6
  @backstage/plugin-catalog-backend          1.0.0
  @backstage/plugin-catalog-common           1.0.0, 1.0.2
  @backstage/plugin-catalog-graph            0.2.10
  @backstage/plugin-catalog-import           0.8.1
  @backstage/plugin-catalog-react            0.6.15, 1.0.0, 1.1.0
  @backstage/plugin-catalog                  1.0.0
  @backstage/plugin-github-actions           0.5.3
  @backstage/plugin-home                     0.4.21
  @backstage/plugin-org                      0.5.3
  @backstage/plugin-permission-common        0.5.3, 0.6.1
  @backstage/plugin-permission-node          0.5.5
  @backstage/plugin-permission-react         0.3.4, 0.4.1
  @backstage/plugin-proxy-backend            0.2.24
  @backstage/plugin-scaffolder-backend       1.0.0
  @backstage/plugin-scaffolder-common        1.0.0
  @backstage/plugin-scaffolder               1.0.1
  @backstage/plugin-search-backend-module-pg 0.3.1
  @backstage/plugin-search-backend-node      0.5.2
  @backstage/plugin-search-backend           0.4.8
  @backstage/plugin-search-common            0.3.2, 0.3.4
  @backstage/plugin-search                   0.7.4
  @backstage/plugin-stack-overflow           0.1.1
  @backstage/plugin-tech-radar               0.5.5
  @backstage/plugin-techdocs-backend         1.0.0
  @backstage/plugin-techdocs-node            1.0.0
  @backstage/plugin-techdocs                 1.0.1
  @backstage/plugin-user-settings            0.4.2
  @backstage/release-manifests               0.0.2
  @backstage/search-common                   0.3.2, 0.3.4
  @backstage/test-utils                      1.0.0
  @backstage/theme                           0.2.15
  @backstage/types                           0.1.3, 1.0.0
  @backstage/version-bridge                  0.1.2, 1.0.0, 1.0.1
✨  Done in 1.49s.

After some investigation I found discoveryApi returns incorrect baseUrl for all of my backend clients somehow.
I believe the cause is the same as https://github.com/backstage/backstage/issues/4665. However I don't know the root cause because I'm not sure whether it should look for localhost.
Inspired by https://github.com/backstage/backstage/issues/4665#issuecomment-885688479 I created the following class which solves my issue on my staging instance.
import {
  PluginEndpointDiscovery,
  SingleHostDiscovery,
} from '@backstage/backend-common';
import { Config } from '@backstage/config';

/**
 * Patch the SingleHostDiscovery's getBaseUrl so it can return correct baseUrl in TLS mode
 */
export class PatchedSingleHostDiscovery implements PluginEndpointDiscovery {
/**
   * Initialize the discovery api and check whether we need to patch the baseUrl
   * @param config Backstage config
   * @param basePath The path prefix
   */
  static fromConfig(
    config: Config,
    options?: {
      basePath?: string;
    },
  ) {
    return new PatchedSingleHostDiscovery(
      SingleHostDiscovery.fromConfig(config, options),
      config.has('backend.https'),
    );
  }

  private constructor(
    private readonly singleHostDiscovery: SingleHostDiscovery, // Backstage's built-in Single Host Discovery API
    private readonly alwaysReturnExternalBaseUrl: boolean, // True when the app is served in TLS mode
  ) {}

  /**
   * When the app is served in TLS mode, always return external base url.
   * So Backstage would not look for localhost when we serve the content on remote hosts (such as staging or production) with TLS mode.
   * @param pluginId The plugin id
   * @returns The base url for the plugin
   */
  getBaseUrl(pluginId: string): Promise<string> {
    if (this.alwaysReturnExternalBaseUrl) {
      return this.getExternalBaseUrl(pluginId);
    }
    return this.singleHostDiscovery.getBaseUrl(pluginId);
  }

  /**
   * Returns the external HTTP base backend URL for a given plugin, without a trailing slash.
   * Check the type comment in PluginEndpointDiscovery for details
   * @param pluginId The plugin id
   * @returns The base url for the plugin
   */
  getExternalBaseUrl(pluginId: string): Promise<string> {
    return this.singleHostDiscovery.getExternalBaseUrl(pluginId);
  }
}

Yep local HTTPS is an interesting edge-case for PluginEndpointDiscovery. I think what you have there makes sense but could be nice to have a solution built-in. One possibility would be to simply default to using the external base URL if the backend is served over https. I think another possibility could be to allow a hostname to be configured for local access. In the end I think we might defer the solution slightly until we tackle multi-instance plugin discovery, at which point we'll need more powerful routing configuration anyway.

Closing this as I think this is now captured in #11064, and the current workaround is captured above

authors: Kuan-Ying Rugvip

repo: backstage/backstage


text:
Tweak typescript config: use Project References in local development

We can improve developer lint-iteration time by leveraging TypeScript Project References
Feature Suggestion
The fastest way to have TypeScript lint a large repository like backstage is to have it pretend everything is in "one big project", and lint it all in one go.
However, when developing locally, TypeScript is run more frequently - sometimes even iteratively when working on a change whose types won't quite fit together :)
Even when "incremental", TypeScript does a lot of work if it's scanning the entire repository to see what changes are needed.
If Project References are used, then TypeScript is much faster at "filtering out" already-compiled sub-projects, and only doing work on the changed pieces.
(I'd have to re-confirm my measurements, but) IIRC, the iteration time of a one-line change can be lowered from roughly ~10-15s to ~2s.
Possible Implementation
This isn't as simple as just porting to Project References, as "full, clean compiles" would be slower, which is bad for CI (though, perhaps we can cache and re-use Project Reference artifacts between jobs? That's out-of-scope :wink: ).
So, we'd need to be clever here and have essentially a dual-config situation:

Have as much common config as possible defined in-repo as conventionally as possible
Ensure when when a developer does TypeScript linting, it defaults to Project-References-style linting
When run in CI, use tsc CLI parameters/environment variables/manually specified "override config files/etc to do a "single pass" lint.

Finally, there's a tradeoff here: for developers, the first time they lint their repo, it will take longer - roughly 2.5x longer than with the existing setup. However, I'm estimating that this cost (where the developer can multitask elsewhere - heck, they just waited for a yarn install likely, what's another couple minutes) is much smaller than the current iteration time cost.

I'd be happy to push this forward sometime in the next few months when I have time.

👍
I wanna highlight another option here too, which is to do something similar to this, but for local dev:  https://github.com/backstage/backstage/blob/16889b6ea7e57c35fad5b652c42eab3aab1d85ce/scripts/api-extractor.ts#L268
It's a temporary TS config that focuses in on the part of the project, rather than including all packages

That's a good alternative option, though cleanup hooks can be less dependable such as if a process ends unexpectedly, system shutdown, etc: causing these files to appear as extra changes in the git working area, which devs would have to be aware of.
The other downside of that approach is that, if dependent projects are used (but not modified), it has the same issue as doing a top-level lint in that more files are being verified than necessary.

This is still valid, but needs some time to fully describe the alternative solution (which IIRC was something like "use project references for local dev, but 'single-project monolith builds' for CI, etc)

I looked further into doing a proof-of-concept of this within backstage-frontend, with two findings:

There's dependencies between packages within the monorepo, and this must be reflected twice within each dependent package: once within package.json and once within tsconfig.json. Fortunately, there's a utils-typescript-references tool which we could employ in git commit hooks / CI to ensure that these remain up-to-date.
Project references do not allow circular dependencies, and unfortunately there's still many of those within internal Backstage. Those will need to be resolved first before we can experiment there.

Bump.

authors: Rugvip mitchhentgesspotify


text:
🚀 Feature: Show logs when clicking step in Scaffolder UI

🔖 Feature description
The steps in the stepper component are clickable after task completion:

Or rather, there's the MUI feedback effect when clicking, but nothing happens.
A intuitive expectation may be that that step will show/expand to show the logs (both for success and failures).
Though all logs are available here...

...this could be a nice UX enhancement.
🎤 Context
It's a UX enhancement
✌ Possible Implementation
No response
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, I don't have time to work on this right now

Makes sense to me

This is free if anyone would like to help contribute :pray:

authors: benjdlambert efenner-cambia javoire


text:
🐛 Bug Report: invoking scaffolder task results in fetch error

📜 Description
When executing scaffolder steps for a software template, a TypeError ("Failed to fetch") occurs.  The error occurs immediately after clicking the "Create" button for a software template.
Once the error occurs, all requests to the backend process fail -- ERR_CONNECTION_REFUSED observed in the browser console for all requests to the :7007 port for the backend.  The Backstage backend process has to be restarted to get the app working again.
👍 Expected behavior
The UI should show "Run of {template name}" and progress of the scaffolder steps
👎 Actual Behavior with Screenshots
No errors are printed to the terminal console where Backstage was started.  The error shown in the UI is:
TypeError: Failed to fetch
    at eval (webpack-internal:///../../node_modules/@backstage/core-app-api/dist/index.esm.js:1916:16)
    at async ScaffolderClient.getTask (webpack-internal:///../../node_modules/@backstage/plugin-scaffolder/dist/esm/OngoingTask-87c6761c.esm.js:235:22)

Once this error occurs, all actions in the UI which communicate with the backend fail and show a "Failed to fetch" or "Failed to load xxx" error.
👟 Reproduction steps

Install Backstage 1.21.x (npx @backstage/create-app@latest)
start Backstage (cd backstage && yarn dev)
Navigate to "Create..." and select the "Example Node.js Template"
Provide input values for the template form and click "Create"

📃 Provide the context for the Bug.
This behavior is causing all of my software templates to fail to execute after updating with the latest yarn install
🖥 Your Environment
yarn run v1.22.21
$ /Users/x/tmp/backstage/node_modules/.bin/backstage-cli info
OS:   Darwin 23.2.0 - darwin/arm64
node: v20.10.0
yarn: 1.22.21
cli:  0.25.0 (installed)
backstage:  1.21.0

Dependencies:
  @backstage/app-defaults                                          1.4.6
  @backstage/backend-app-api                                       0.5.9
  @backstage/backend-common                                        0.20.0
  @backstage/backend-dev-utils                                     0.1.2
  @backstage/backend-openapi-utils                                 0.1.1
  @backstage/backend-plugin-api                                    0.6.8
  @backstage/backend-tasks                                         0.5.13
  @backstage/catalog-client                                        1.5.1
  @backstage/catalog-model                                         1.4.3
  @backstage/cli-common                                            0.1.13
  @backstage/cli-node                                              0.2.1
  @backstage/cli                                                   0.25.0
  @backstage/config-loader                                         1.6.0
  @backstage/config                                                1.1.1
  @backstage/core-app-api                                          1.11.2
  @backstage/core-compat-api                                       0.1.0
  @backstage/core-components                                       0.13.9
  @backstage/core-plugin-api                                       1.8.1
  @backstage/e2e-test-utils                                        0.1.0
  @backstage/errors                                                1.2.3
  @backstage/eslint-plugin                                         0.1.4
  @backstage/frontend-plugin-api                                   0.4.0
  @backstage/integration-aws-node                                  0.1.8
  @backstage/integration-react                                     1.1.22
  @backstage/integration                                           1.8.0
  @backstage/plugin-api-docs                                       0.10.2
  @backstage/plugin-app-backend                                    0.3.56
  @backstage/plugin-app-node                                       0.1.8
  @backstage/plugin-auth-backend-module-atlassian-provider         0.1.0
  @backstage/plugin-auth-backend-module-gcp-iap-provider           0.2.2
  @backstage/plugin-auth-backend-module-github-provider            0.1.5
  @backstage/plugin-auth-backend-module-gitlab-provider            0.1.5
  @backstage/plugin-auth-backend-module-google-provider            0.1.5
  @backstage/plugin-auth-backend-module-oauth2-provider            0.1.5
  @backstage/plugin-auth-backend-module-oauth2-proxy-provider      0.1.0
  @backstage/plugin-auth-backend-module-okta-provider              0.0.1
  @backstage/plugin-auth-backend                                   0.20.2
  @backstage/plugin-auth-node                                      0.4.2
  @backstage/plugin-catalog-backend-module-scaffolder-entity-model 0.1.5
  @backstage/plugin-catalog-backend                                1.16.0
  @backstage/plugin-catalog-common                                 1.0.19
  @backstage/plugin-catalog-graph                                  0.3.2
  @backstage/plugin-catalog-import                                 0.10.4
  @backstage/plugin-catalog-node                                   1.6.0
  @backstage/plugin-catalog-react                                  1.9.2
  @backstage/plugin-catalog                                        1.16.0
  @backstage/plugin-events-node                                    0.2.17
  @backstage/plugin-github-actions                                 0.6.9
  @backstage/plugin-org                                            0.6.18
  @backstage/plugin-permission-common                              0.7.11
  @backstage/plugin-permission-node                                0.7.19
  @backstage/plugin-permission-react                               0.4.18
  @backstage/plugin-proxy-backend                                  0.4.6
  @backstage/plugin-scaffolder-backend-module-azure                0.1.0
  @backstage/plugin-scaffolder-backend-module-bitbucket            0.1.0
  @backstage/plugin-scaffolder-backend-module-gerrit               0.1.0
  @backstage/plugin-scaffolder-backend-module-github               0.1.0
  @backstage/plugin-scaffolder-backend-module-gitlab               0.2.11
  @backstage/plugin-scaffolder-backend                             1.19.2
  @backstage/plugin-scaffolder-common                              1.4.4
  @backstage/plugin-scaffolder-node                                0.2.9
  @backstage/plugin-scaffolder-react                               1.7.0
  @backstage/plugin-scaffolder                                     1.17.0
  @backstage/plugin-search-backend-module-catalog                  0.1.12
  @backstage/plugin-search-backend-module-pg                       0.5.17
  @backstage/plugin-search-backend-module-techdocs                 0.1.12
  @backstage/plugin-search-backend-node                            1.2.12
  @backstage/plugin-search-backend                                 1.4.8
  @backstage/plugin-search-common                                  1.2.9
  @backstage/plugin-search-react                                   1.7.4
  @backstage/plugin-search                                         1.4.4
  @backstage/plugin-tech-radar                                     0.6.11
  @backstage/plugin-techdocs-backend                               1.9.1
  @backstage/plugin-techdocs-module-addons-contrib                 1.1.3
  @backstage/plugin-techdocs-node                                  1.11.0
  @backstage/plugin-techdocs-react                                 1.1.14
  @backstage/plugin-techdocs                                       1.9.2
  @backstage/plugin-user-settings                                  0.7.14
  @backstage/release-manifests                                     0.0.11
  @backstage/test-utils                                            1.4.6
  @backstage/theme                                                 0.5.0
  @backstage/types                                                 1.1.1
  @backstage/version-bridge                                        1.0.7
Done in 0.58s.

👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, I don't have time to work on this right now

Hi @awsjim, sorry your ran into issues. I noticed you are on Node 20, did you try the flag that was mentioned here: https://backstage.io/docs/features/software-templates/#getting-started ?

Note: if you're running Backstage with Node 20 or later, you'll need to pass the flag --no-node-snapshot to Node in order to use the templates feature. One way to do this is to specify the NODE_OPTIONS environment variable before starting Backstage: export NODE_OPTIONS=--no-node-snapshot

👏  Ah ha!  I did not notice that and really appreciate the pointer.
@awanlin  - thanks so much for the quick response and pointing out my error. 🙏
I'll go ahead and close out this issue

You're welcome @awsjim 🚀

authors: awanlin awsjim


text:
💬 RFC: Table component suggestions

🔖 Need
While utilizing the table component, we've identified areas where enhancements can be made to elevate the user experience.

Bulk actions:
Without bulk actions on tables, users may need to perform repetitive tasks individually, leading to inefficiency and frustration. It can also result in a cluttered interface if each action is displayed separately, making it harder to focus on important tasks. Additionally, users may expect the ability to perform bulk actions, so not providing them can lead to a mismatch in user expectations and functionality.

Menu for actions:
Displaying many icons as actions on a table view can clutter the interface, overwhelm users with repeated actions, reduce focus on the relevant content, create inconsistency in design, lead to usability issues on smaller screens, and make scalability challenging as the number of actions grows.

Non-alternating tables:
Integrating alternating row colors in a table view raises for us several concerns. While they can enhance visual appeal, they may also clutter the layout and potentially hinder accessibility for users with visual impairments. Additionally, their aesthetic alignment within the overall design could make the interface busy. Moreover, they could distract from the table's content especially if there are icons added to it, such as status colors or alerts.

🎉 Proposal
These proposals are made from discussions within our team and are informed by benchmarking against other design languages:

Bulk actions:
We aim to incorporate a bulk actions feature in instances where a table view is displayed, along with displaying all filters simultaneously. This will empower users to promptly execute actions in batches

Menu for actions:
Using a menu icon to gather actions on a table view offers a cleaner interface, conserves space, improves user focus, ensures consistency, optimizes for mobile, scales well, and allows for customization. In addition, it allows adding a text next to each icon to describe it and a description if needed for more information.

Non-alternating tables:
Non-alternating table designs offer simplicity, consistency, and accessibility benefits. By presenting data without alternating colors, they maintain a clean and straightforward visual appearance, aiding users in focusing on content. This design approach enhances accessibility for users with visual impairments, and allows for greater flexibility in customization. Adding a hover color to table rows improves usability by providing clear visual feedback on interactive elements.

〽 Alternatives
No response
❌ Risks
Currently, incorporating actions necessitates the creation of an additional column. However, by implementing the proposed solution, updating the table view to one featuring the actions will be essential to prevent inconsistencies.
👀 Have you spent some time to check if this RFC has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

@ShiranHi is it possible to reference the table component implementation here? (easier to navigate through the codebase)

Thank you for these suggestions! Looks good imo 👍
Curious if there are any thought on this from anyone else in the community, would this be something you want to see in your own Backstage instances?

@ShiranHi is it possible to reference the table component implementation here? (easier to navigate through the codebase)
Hey @aamnatayyab6  -Are you referring to this link?
https://backstage.io/storybook/?path=/story/data-display-table--default-table

@ShiranHi thank you for the link! Has this issue been decided upon yet and do we know already who will it be assigned to?

Has this issue been decided upon yet and do we know already who will it be assigned to?

We still don't know who will be assigned to it. The implementation will require assistance from the community here.

@ShiranHi is it possible to implement one of the three areas? If so, I would like to explore the "Menu for actions" item and be assigned to it.

I'm here with an update: we've successfully addressed the bulk actions and alternating row features outlined in this RFC by using the Material UI table component and the Backstage theme feature.
I believe it's worth revisiting how we present actions for each row, as this aspect remains open for discussion.

@ShiranHi is it possible to implement one of the three areas? If so, I would like to explore the "Menu for actions" item and be assigned to it.

@aamnatayyab6 could you let me know if you've had the opportunity to work on this? I'm uncertain about the progress or if it has been merged

authors: Rugvip ShiranHi aamnatayyab6


text:
Better implementation docs for Tech Radar plug-in

Feature Suggestion

The current "Getting Started" instructions suggest...

"...you can set a variety of configuration directly in your apis.ts", but never give any advice for how to configure "packages/app/src/apis.ts"
Talks about configuring routes with <TechRadarRouter ... while the default app template actually defines the route with <TechRadarPage ... instead
It briefly shows a specification of TechRadarPageProps, which could be used to configure the route's <TechRadarPage ..., including the getData() function, but without an example. Later, in the FAQ, it indirectly explains "How do I load in my own data" and talks about the "getData()" function, but instead references the <TechRadarComponent  ... (which is yet another component that is neither the <TechRadarRouter ... or <TechRadarPage ... mentioned earlier.)

Possible Implementation

Clean up component references and examples. Relate the documentation to how the Backstage app template sets things up initially.

Hi! Made a PR to address most of it, give it a look. I left out part of the potential confusion on the last point, at least it now doesn't talk about TechRadarRouter which indeed was wrong and confusing

authors: ericis freben


text:
[TechDocs] add GiveFeedback addon

Co-authored-by: Camila Belo camilaibs@gmail.com
Signed-off-by: Anders Näsman andersn@spotify.com
Hey, I just made a Pull Request!
Add GiveFeedback addon to TechDocs.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Closing this PR as its moved to the techdocs plugin over here https://github.com/backstage/backstage/pull/10733

authors: emmaindal realandersn


text:
Add Cloudify plugin

Add Cloudify plugin
Backstage plugin that connects with the Cloudify Manager instance and pulls all available blueprints.
Blueprints are listed in a table and accesible via a link to the Cloudify Manager.

Thanks for this fine contribution @jakubcierlik 🙌 Please let me know if you’d like some help to contribute further.

authors: jakubcierlik suuus


text:
change task lists created at column to use timestamp

Hey, I just made a Pull Request!
The tasks list created at column displays relative time in a format like:
8 months, 1 week, 19 hours, 46 minutes, 40 seconds
However, when you want to find a task that has ran near a date or time then rendering it this way makes this difficult since it is all relative to the current date.
This PR changes the created at column on tasks list page to show timestamp for easier visual searching. Example:
9/18/2024, 9:51:37 PM
Before:

After:

Feedback appreciated as always!
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

I agree that this is tricky to parse.
I wonder if there's a better luxon option to format the timestamp. I'm based in Europe but I also get AM/PM timestamps testing this in my browser which would be confusing as we're used to 24h and ISO(YYYY-MM-DD) for dates

Having the format like 9/18/2024  can be confusing for European, as day and month is reversed.
In this example it's clear where is the date. But in 9/7/2024 would be not 😅
If to switch to use time format, I'd suggest to use the month as a word Sep 18 2024

Just pushed an update to render the date time for the users locale. Check out the tests file where it's now formatting the time (24hrs) and date (mm/dd vs dd/mm) for European locales :) . Let me know if this works! Otherwise can go with option as @acierto  mentions

authors: acierto jhaals stephenglass


text:
Added  parameter for auth config. It will create new session if refre…

…sh failed
Hey, I just made a Pull Request!
Hi team! I encountered an issue where the refresh token action fails, causing all authorized requests afterward to stop working. It would be great if, in such cases, there is a way to recover the current session without a full page reload. I attempted to fix this issue, but I'm not entirely sure if my approach is correct. This issue is critical for our product, so I would appreciate it if you could review my changes and provide feedback. If my changes are not correct, I am open to resolving the issue differently based on your advice. Thank you!
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Hi folks, please have a look at this @jhaals @vinzscam. Thank you!

@Rugvip Hi, please have a look at this. Thanks!


text:
Version Packages (grafana)

Releases
@backstage-community/plugin-grafana@0.1.0
Minor Changes

48dbddf: Initial plugin version. It's a copy of its original repo

@ivangonzalezacuna, would it make sense for you to be added to https://github.com/backstage/community-plugins/blob/main/.github/CODEOWNERS for this plugin workspace?

Hi. I can't promise being able to always review all the possible MRs, but sure, you can add me to the list together with the community-plugins-maintainers. I think that way it should be doable :smile:

authors: backstage-service ivangonzalezacuna

repo: backstage/community-plugins


text:
Fix FilePath not flagging non spec files

Fixes #324

@Darhazer could you review?

repo: backus/rubocop-rspec


text:
Add suis pp_db; ggcaller to publications

Tidy and update other pages

@samhorsfield96 can you check you are happy with the ggcaller description I've added – please edit as necessary! We can also add a proper blog post after it's published

All good!

repo: bacpop/bacpop-website


text:
Int parse errors found with fuzzing

I've been spending entirely too much time playing with libfuzzer recently, and this crate was one of my victims.
It pretty quickly found src/helper.rs:10 – as you can imagine, as soon as you write unwrap anywhere, it'll come back to bite fuzz you ;)

[ ] called Result::unwrap() on an Err value: ParseIntError { kind: Empty }
with input b"164800."
[ ] called Result::unwrap() on an Err value: ParseIntError { kind: Overflow }'
with input b"04:05:06.1226001015632)*450"

See https://gist.github.com/killercup/8dd9ca721fc29cca5b4c8db51bba75b2 for full logs
cf. https://github.com/rust-fuzz/targets/pull/59

We should probably get rid of the unwraps to avoid all further warnings, but both examples turned up different bugs in the parser itself

While investigating this, the question about how to handle trailing things comes up again. Should we handle a trailing . (a dot) as .0 or should we handle it as an error?

1 fixed in https://github.com/badboy/iso8601/pull/13/commits/a538ae900e515f0c59195f54348867c9c075987a
2 fixed in https://github.com/badboy/iso8601/pull/13/commits/5e3723b1e46f133010cd77f4958b77506bc126bb
also fixed further bugs

authors: badboy killercup


text:
Is it possible to show the number of downloads WITHOUT having the asset name in brackets? -- downloads|34 (instead of) downloads|34 [filename.exe]

Example here: https://img.shields.io/github/downloads/atom/atom/latest/atom-amd64.deb.svg

Upon further inspection, it looks like the code sits at line 3862 in server.js
https://github.com/badges/shields/blob/master/server.js

Otherwise i may be able to look into it in the next few weeks.

Having just ran into this exact use case, any update on this?

authors: CookiePLMonster Tylemagne

repo: badges/shields


text:
Add [Docker] support for loong64 arch

Fixes #10224.

Wow, these tests were pretty stable and were working fine not so long ago (#9934), but we've now got a bunch a failures. Maybe best to take a look in a follow up?

The test failures are unrelated IMO, so I agree and I'd be fine giving this the :+1: to go ahead and fix #10224, and then address the failing tests separately.
Let me know if you'd like me to re-approve or if you change your mind and decide to try to fix the tests here

I've fixed one of the tests to use a better example.
The other ones seems to be getting 401 responses, they're all Docker Cloud examples. Our Docker badges support optional auth:
https://github.com/badges/shields/blob/0360ba3a1b193b25a03454e36b823aa20155d7fc/services/docker/docker-automated.service.js#L19-L25
As far as I can tell, we only ever configured dockerhub_username but not dockerhub_pat in our GitHub actions configuration. I'm wondering whether Docker Cloud started requiring auth, or whether the project we're testing against, pavics/magpie, moved to being a private one. @chris48s you're much more familiar with the service and reworked auth recently, do you have any insights?

So 2 things:

When you run service tests from a fork, we don't pass any secrets so on this PR (submitted from your fork) there are no credentials being used
Even when submit a PR from a local branch on this repo, the vars we pass are: https://github.com/badges/shields/blob/0360ba3a1b193b25a03454e36b823aa20155d7fc/.github/workflows/test-services.yml#L26-L36 dockerhub username (or PAT) isn't one of the things we set.

The docker credentials in the repo secrets (not prefixed with SERVICETESTS_) are used for pushing the images we build to DockerHub.
Looking at it, I think this is not just the service tests. I think the DockerCloud badges are just completely broken - with or without credentials. I think this is due to an upstream change. I'm also happy to punt this to another issue as it is unconnected to this PR, but does want fixing. Related: https://github.com/badges/shields/issues/9563
btw, I've been waiting for this fix to land for a looooong time :trollface:

authors: PyvesB calebcartwright chris48s


text:
add Opera Add-ons support

resolves #827

Don't merge yet, please. I'm going to switch from html-soup to cheerio. I didn't know such lib exists.

Please let us know when this is ready for review :)

It is already! :)

Now it's even more ready.

Nice, one step further to unified browser extensions 🎉

@Daniel15 Please let me know when you are ready for review.

Sorry for the delay, I've been pretty busy recently :( I'll try to view this soon, but someone else may get to it before I do.

Please also add test cases for this. See https://github.com/badges/shields/tree/master/service-tests for instructions on how to write tests.

@Daniel15 Thanks you for your comments. Give me some time, please.

No worries, feel free to take as long as you like! No pressure 😄

This seems very unmaintainable and will break if Opera ever change their HTML even slightly. Do Opera not have an API for retrieving this data?

There is no public API for Opera Add-ons, neither for Chrome Web Store.

Something as simple as Opera switching the order of the fields in the "about the extension" section (for example, displaying "size" above "version") will break this. If you really do need to parse the HTML, it might be worth making it smarter.

No need to worry. Tests will catch that. It's much more likely that store's layout changes completely than "size" goes above "version".

Please also add test cases for this.

Done.

I'd suggest pulling this out into a separate utility module (eg. lib/parseOperaExtensionPage.js) rather than putting all the code in here.

Parsing is just 4 lines of code. There's much more ceremony with badge construction: that's what should be improved in the first place. I'll be happy to take care of opera and chrome modules as soon as server.js becomes modular (in the sense of #948 and #963).
I did, however, some refactoring in color- and text-formatters. It was painful to replace all versionFormatter() calls but someone had to do this.

@espadrine has argued against parsing on the server because it's resource intensive. We've said no to badges like these before, and asked that contributors approach the vendor and ask them to create an API.
This PR has a bunch of unrelated changes / refactoring. Could those be cherry-picked into a new PR?

@paulmelnikow You also said yes to badges like this before, so I don't understand why this is so problematic now and it wasn't in case of Firefox and Chrome. After nearly 11 months I have no expectations really, but - at least be fair.
As for the question, I'll be happy to see that versionFormatter() is gone forever. Be my guest. Pick whatever you want.

As far as I know I haven't merged a badge that parses web pages. I did not realize the Chrome badge used a library that uses cheerio.
I don't have a problem with it from a maintainability perspective, as integration tests can catch the problem, with the caveat that our deploy cycles can be a bit long. If there's not a performance problem I am okay with it.
@Daniel15 it sounds like you are okay with it too. @espadrine what do you think?

I know you're frustrated about this. I apologize. There's not much else I can say, other than this (from https://github.com/badges/shields/issues/358#issuecomment-350093303):

We need more capacity, or confidence we can buy more capacity, before we add more scrapers.

Our OpenCollective is now open, which means we can start to collect $10 donations toward this fund. If you wanted an answer to "what can you do to make this happen," it's to spread that message, far and wide.


text:
Multi Vendor Marketplace Installation Issue

Bug report
Issue Description

I currently installing multi vendor marketplace extension following this tutorial https://webkul.com/blog/laravel-multi-vendor-marketplace/, i encounter a problem where the db cannot be seeded with error Class WebkulMarketplaceDatabaseSeedersDatabaseSeeder does not exist. I suppose i followed the tutorial thoroughly so i didn't notice what mistake i've made.
Preconditions

PHP 7.4.15
Laravel Framework 7.30.4
Composer 2.0.9

Bagisto version

[x] 1.3.1

Steps to reproduce

Following this tutorial
Enter the php artisan db:seed --class=Webkul\Marketplace\Database\Seeders\DatabaseSeeder command

Expected result

The database successfully seeded
Actual result

Error showed below

Hi @cerohawke88,
This is a paid extension, please raise a support ticket,
https://bagisto.uvdesk.com/en/

repo: bagisto/bagisto


text:
Fixed issue 2225

BUGS:

Fixed issue #2225

@mohdfaizdev thanks

authors: jitendra-webkul mohdfaizdev


text:
Backend validation for 0 quantity grouped product.

Issue Reference
https://github.com/bagisto/bagisto/issues/6429
Description
Back end validation for zero quantity grouped product.

@papnoisanjeev
I think the pr is already created for this issue. https://github.com/bagisto/bagisto/pull/6522
@devansh-webkul Please look into it

Closing as already default 1 quantity is going if someone bypass  0 anyway.

authors: Sanjaybhattwebkul papnoisanjeev


text:
import { Hooper, Slide } from 'hooper'; will make an error

When I want to import this import { Hooper, Slide } from 'hooper';
The vue cli will show this erorr:
error  in ./~/hooper/dist/hooper.esm.js
Module parse failed: D:\node\my-project\node_modules\hooper\dist\hooper.esm.js Unexpected token (336:23)
You may need an appropriate loader to handle this file type.
|     initDefaults () {
|       this.breakpoints = this.settings.breakpoints;
|       this.defaults = {...this.$props, ...this.settings};
|       this.$settings = this.defaults;
|     },
@ ./~/babel-loader/lib!./~/vue-loader/lib/selector.js?type=script&index=0!./src/components/Plan_a_trip_en.vue 156:0-39
@ ./src/components/Plan_a_trip_en.vue
@ ./src/router/index.js
@ ./src/main.js
@ multi ./build/dev-client ./src/main.js
Can somebody help me please

if you found this same problem simply you can open node moduls --> dist  --> hopper.esm.js go to the line  366 and change  this.defaults =  (...this.$props, ...this.settings} to  this.defaults =  this.$props, this.settings
I am not sure that it is correct, but its work for me

Hi,
I have the same issue using with vue.js then i solve with a similar quote:
import { Hooper, Slide } from 'hooper/dist/hooper';
So, the feature to read ...this.$props, ...this.settings is not supported on buggied browsers, rs.
The solution was use an pre-compiled code, and use it instead the npm package source.

This fixed in version 0.0.9

Hi @Abdelrahman3D , these commited changes  babel({ extensions: ['.js', '.vue'] }) will really make import from 'hooper´ get the final dist files with parsed to _objectSpread from Babel parse? If yes, you can discard my pull request #45. Thanks,

repo: baianat/hooper


text:
compiling problem

Hi,
I am comping the project but I have got the following error:

[  4%] Built target extern_leveldb
[  9%] Built target extern_jsoncpp
[ 13%] Built target extern_gtest
[ 18%] Built target extern_xgboost
[ 22%] Built target extern_eigen
[ 23%] Performing build step for 'extern_paddle'
[  1%] Built target extern_lib_any
[  2%] Built target extern_eigen3
[  2%] Built target extern_gflags
[  4%] Built target extern_threadpool
[  4%] Built target extern_snappy
[  4%] Built target extern_mklml
[  4%] Built target extern_zlib
[  5%] Built target extern_boost
[  6%] Built target profiler_py_proto_init
[  6%] Built target extern_warpctc
[  6%] Built target framework_py_proto_init
[  7%] Built target extern_glog
[  7%] Built target extern_snappystream
[  8%] Built target extern_protobuf
[  8%] Built target stringpiece
[  9%] Built target header
[  9%] Built target enforce
[  9%] Built target cblas
[ 10%] Built target memory_block
Copy generated python proto into directory paddle/fluid/proto.
[ 10%] Built target activation_functions
[ 10%] Generating ../paddle/python/paddle/proto/ParameterService_pb2.py
[ 10%] Generating ../paddle/python/paddle/proto/ParameterServerConfig_pb2.py
[ 10%] Generating ../paddle/python/paddle/proto/TrainerConfig_pb2.py
Copy generated python proto into directory paddle/fluid/proto/profiler.
[ 10%] Generating ../paddle/python/paddle/proto/OptimizerConfig_pb2.py
[ 10%] Generating ../paddle/python/paddle/proto/ParameterConfig_pb2.py
[ 10%] Generating ../paddle/python/paddle/proto/ModelConfig_pb2.py
[ 11%] Generating ../paddle/python/paddle/proto/DataFormat_pb2.py
[ 11%] Generating ../paddle/python/paddle/proto/DataConfig_pb2.py
[ 11%] Built target framework_proto
[ 12%] Built target paddle_proto
[ 12%] Built target chunk
[ 12%] Built target framework_py_proto
[ 12%] Built target ddim
[ 12%] Built target cpu_info
[ 12%] Built target profiler_py_proto
[ 13%] Built target dynamic_loader
[ 13%] Built target gen_proto_py
[ 15%] Built target threadpool
[ 15%] Built target prune
[ 16%] Built target writer
[ 16%] Built target place
[ 17%] Built target profiler_proto
[ 17%] Built target system_allocator
[ 17%] Built target scanner
[ 17%] Built target dynload_warpctc
[ 17%] Built target attribute
[ 17%] Built target scope
[ 18%] Built target buddy_allocator
[ 19%] Built target recordio
[ 19%] Built target var_handle
[ 19%] Built target memcpy
[ 19%] Built target device_tracer
[ 19%] Built target op_proto_maker
[ 19%] Built target op_info
[ 19%] Built target malloc
[ 19%] Built target memory
[ 19%] Built target device_context
[ 19%] Built target vol2col
[ 19%] Built target data_type
[ 20%] Built target sequence2batch
[ 20%] Built target maxouting
[ 20%] Built target sequence_scale
[ 20%] Built target blas
[ 20%] Built target concurrency
[ 20%] Built target pooling
[ 20%] Built target im2col
[ 20%] Built target lstm_compute
[ 20%] Built target sequence_padding
[ 20%] Built target profiler
[ 20%] Built target concat
[ 20%] Built target cos_sim_functor
[ 21%] Built target shape_inference
[ 21%] Built target cross_entropy
[ 22%] Built target unpooling
[ 23%] Built target math_function
[ 23%] Built target tensor
[ 23%] Built target softmax
[ 23%] Built target gru_compute
[ 23%] Built target data_type_transform
[ 23%] Built target data_layout_transform
[ 23%] Built target selected_rows
[ 24%] Built target lod_tensor
[ 24%] Built target context_project
[ 24%] Built target sequence_pooling
[ 25%] Built target data_device_transform
[ 25%] Built target op_handle_base
[ 26%] Built target feed_fetch_method
[ 26%] Built target variable_visitor
[ 26%] Built target reader
[ 26%] Built target lod_rank_table
[ 26%] Built target selected_rows_functor
[ 26%] Built target data_transform
[ 26%] Built target ssa_graph
[ 26%] Built target fetch_op_handle
[ 26%] Built target fuse_vars_op_handle
[ 26%] Built target broadcast_op_handle
[ 26%] Built target reduce_op_handle
[ 26%] Built target all_reduce_op_handle
[ 27%] Built target gather_op_handle
[ 28%] Built target operator
[ 28%] Built target scale_loss_grad_op_handle
[ 29%] Built target ssa_graph_builder
[ 29%] Built target ssa_graph_executor
[ 29%] Built target init
[ 29%] Built target proto_desc
[ 29%] Built target ssa_graph_printer
[ 29%] Built target threaded_ssa_graph_executor
[ 29%] Built target ssa_graph_checker
[ 29%] Built target scope_buffered_ssa_graph_executor
[ 29%] Built target op_registry
[ 29%] Built target scale_op
[ 29%] Built target top_k_op
[ 29%] Built target sigmoid_cross_entropy_with_logits_op
[ 29%] Built target shape_op
[ 29%] Built target sequence_concat_op
[ 30%] Built target executor
[ 30%] Built target smooth_l1_loss_op
[ 31%] Built target computation_op_handle
[ 32%] Built target split_lod_tensor_op
[ 32%] Built target roi_pool_op
[ 33%] Built target rpc_op_handle
[ 33%] Built target uniform_random_op
[ 33%] Built target split_ids_op
[ 33%] Built target split_op
[ 33%] Built target tensor_array_read_write_op
[ 33%] Built target rnn_memory_helper_op
[ 33%] Built target rmsprop_op
[ 33%] Built target reverse_op
[ 33%] Built target select_op
[ 33%] Built target precision_recall_op
[ 34%] Built target reorder_lod_tensor_by_rank_op
[ 34%] Built target reduce_sum_op
[ 34%] Built target norm_op
[ 34%] Built target prelu_op
[ 34%] Built target rank_loss_op
[ 35%] Built target proximal_gd_op
[ 35%] Built target positive_negative_pair_op
[ 35%] Built target split_byref_op
[ 35%] Built target pad_op
[ 35%] Built target sign_op
[ 35%] Built target modified_huber_loss_op
[ 35%] Built target nce_op
[ 35%] Built target minus_op
[ 36%] Built target mean_op
[ 37%] Built target scatter_op
[ 37%] Built target merge_ids_op
[ 37%] Built target mean_iou_op
[ 37%] Built target merge_lod_tensor_op
[ 37%] Built target lod_array_length_op
[ 37%] Built target margin_rank_loss_op
[ 37%] Built target lod_reset_op
[ 37%] Built target log_loss_op
[ 37%] Built target split_selected_rows_op
[ 37%] Built target logical_op
[ 37%] Built target lstm_unit_op
[ 37%] Built target row_conv_op
[ 37%] Built target linear_chain_crf_op
[ 38%] Built target lrn_op
[ 38%] Built target layer_norm_op
[ 38%] Built target spp_op
[ 39%] Built target adamax_op
[ 39%] Built target average_accumulates_op
[ 39%] Built target activation_op
[ 40%] Built target load_combine_op
[ 40%] Built target edit_distance_op
[ 40%] Built target channel_recv_op
[ 41%] Built target channel_send_op
[ 41%] Built target sequence_erase_op
[ 41%] Built target arg_min_op
[ 41%] Built target clip_op
[ 41%] Built target adadelta_op
[ 41%] Built target save_op
[ 41%] Built target save_combine_op
[ 41%] Built target dropout_op
[ 42%] Built target decayed_adagrad_op
[ 42%] Built target detection_map_op
[ 42%] Built target huber_loss_op
[ 42%] Built target fill_constant_batch_size_like_op
[ 42%] Built target while_op
[ 42%] Built target conv_op
[ 42%] Built target warpctc_op
[ 42%] Built target sequence_slice_op
[ 43%] Built target parallel_do_op
[ 43%] Built target elementwise_max_op
[ 43%] Built target softmax_op
[ 43%] Built target batch_norm_op
[ 43%] Built target sequence_conv_op
[ 43%] Built target lookup_sparse_table_op
[ 43%] Built target adam_op
[ 43%] Built target cumsum_op
[ 43%] Built target accuracy_op
[ 43%] Built target cos_sim_op
[ 43%] Built target transpose_op
[ 43%] Built target feed_op
[ 44%] Built target sum_op
[ 44%] Built target reduce_mean_op
[ 44%] Built target max_sequence_len_op
[ 45%] Built target reduce_max_op
[ 45%] Built target sequence_softmax_op
[ 45%] Built target gru_op
[ 45%] Built target l1_norm_op
[ 45%] Built target maxout_op
[ 45%] Built target conv_transpose_op
[ 45%] Built target ctc_align_op
[ 45%] Built target cross_entropy_op
[ 45%] Built target cast_op
[ 45%] Built target auc_op
[ 45%] Built target gaussian_random_batch_size_like_op
[ 45%] Built target mul_op
[ 45%] Built target softmax_with_cross_entropy_op
[ 46%] Built target sequence_pool_op
[ 46%] Built target lookup_table_op
[ 46%] Built target expand_op
[ 46%] Built target recurrent_op
[ 48%] Built target assign_value_op
[ 48%] Built target momentum_op
[ 48%] Built target label_smooth_op
[ 48%] Built target is_empty_op
[ 48%] Built target arg_max_op
[ 48%] Built target print_op
[ 48%] Built target lod_rank_table_op
[ 49%] Built target one_hot_op
[ 49%] Built target concat_op
[ 49%] Built target lstm_op
[ 49%] Built target assign_op
[ 49%] Built target load_op
[ 49%] Built target channel_create_op
[ 49%] Built target sequence_expand_op
[ 49%] Built target pool_op
[ 49%] Built target squared_l2_distance_op
[ 49%] Built target sequence_reshape_op
[ 49%] Built target elementwise_pow_op
[ 49%] Built target sgd_op
[ 49%] Built target fake_dequantize_op
[ 49%] Built target random_crop_op
[ 49%] Built target beam_search_decode_op
[ 49%] Built target elementwise_sub_op
[ 49%] Built target pool_with_index_op
[ 50%] Built target beam_search_op
[ 50%] Built target bilinear_interp_op
[ 50%] Built target slice_op
[ 50%] Built target unpool_op
[ 50%] Built target get_places_op
[ 50%] Built target elementwise_add_op
[ 50%] Built target adagrad_op
[ 50%] Built target shrink_rnn_memory_op
[ 50%] Built target channel_close_op
[ 50%] Built target clip_by_norm_op
[ 50%] Built target fill_zeros_like_op
[ 50%] Built target chunk_eval_op
[ 50%] Built target multiplex_op
[ 50%] Built target compare_op
[ 50%] Built target conditional_block_op
[ 50%] Built target bilinear_tensor_product_op
[ 50%] Built target read_op
[ 50%] Built target lstmp_op
[ 50%] Built target crf_decoding_op
[ 50%] Built target reduce_prod_op
[ 50%] Built target crop_op
[ 50%] Built target gru_unit_op
[ 51%] Built target conv_shift_op
[ 51%] Built target proximal_adagrad_op
[ 51%] Built target increment_op
[ 51%] Built target uniform_random_batch_size_like_op
[ 51%] Built target delete_var_op
[ 51%] Built target fill_constant_op
[ 52%] Built target elementwise_mul_op
[ 52%] Built target gather_op
[ 52%] Built target elementwise_min_op
[ 52%] Built target elementwise_div_op
[ 52%] Built target squared_l2_norm_op
[ 52%] Built target ftrl_op
[ 53%] Built target fill_op
[ 53%] Built target reshape_op
[ 53%] Built target reduce_min_op
[ 53%] Built target gaussian_random_op
[ 53%] Built target fetch_op
[ 53%] Built target hinge_loss_op
[ 53%] Built target im2sequence_op
[ 53%] Built target matmul_op
[ 54%] Built target iou_similarity_op
[ 54%] Built target go_op
[ 54%] Built target target_assign_op
[ 54%] Built target reader_op_registry
[ 54%] Built target mine_hard_examples_op
[ 54%] Built target polygon_box_transform_op
[ 54%] Built target multiclass_nms_op
[ 54%] Built target bipartite_match_op
[ 54%] Built target prior_box_op
[ 54%] Built target box_coder_op
[ 54%] Built target multi_devices_graph_builder
[ 54%] Built target lod_tensor_to_array_op
[ 54%] Built target array_to_lod_tensor_op
[ 54%] Built target create_recordio_file_reader_op
[ 54%] Built target create_shuffle_reader_op
[ 54%] Built target open_files_op
[ 55%] Built target create_threaded_reader_op
[ 55%] Built target create_random_data_generator_op
[ 55%] Built target create_double_buffer_reader_op
[ 55%] Built target create_multi_pass_reader_op
[ 55%] Built target create_batch_reader_op
[ 56%] Built target create_custom_reader_op
[ 56%] Built target ssa_graph_builder_factory
[ 56%] Built target paddle_fluid_api
[ 56%] Built target parallel_executor
make[5]: *** No rule to make target third_party/install/zlib/lib/libz.a', needed by paddle/fluid/inference/libpaddle_fluid.so'.  Stop.
make[4]: *** [paddle/fluid/inference/CMakeFiles/paddle_fluid_shared.dir/all] Error 2
make[4]: *** Waiting for unfinished jobs....
[100%] Built target paddle_fluid
make[3]: *** [all] Error 2
make[2]: *** [third_party/paddle/src/extern_paddle-stamp/extern_paddle-build] Error 2
make[1]: *** [CMakeFiles/extern_paddle.dir/all] Error 2
make: *** [all] Error 2

What shall I do to solve it? Thank you.

What are the versions of your gcc and cmake ? The building log you provided is only printed in 'stdout'.  We also need to see the log printed in 'stderr' so that we can  track and locate this error.  In order for us to see the complete log， you can build with the instrunction 'make 1>stderr.log 2>&1 ', and send the file 'stderr.log' to zhanghan17@baidu.com. Thank you!

my gcc is 4.8.5 and my cmake is 3.6.2

hi,i also have this problem ,how can i solve it? Thank you!

What's your cmake command and compile command?

No rule to make target third_party/install/zlib/lib/libz.a

Maybe the network is not good to download the zlib library.

Ummmm, seems I did what exactly the readme file asked me to do.

Please make sure that the source code of zlib is on the path 'build/third_party/install/paddle/third_party/zlib/src/extern_zlib'. And if not, the error might be caused by network problem.

Your gcc is missing yacc. Install yaccc before build this project.

Thank you very much.it's ok.Execute the following command
yum install byacc
yum install flex

repo: baidu/AnyQ


text:
A component required a bean of type 'com.github.wujun234.uid.impl.CachedUidGenerator' that could not be found.

运行环境：springboot 3.0.1
Description:
A component required a bean of type 'com.github.wujun234.uid.impl.CachedUidGenerator' that could not be found.
Action:
Consider defining a bean of type 'com.github.wujun234.uid.impl.CachedUidGenerator' in your configuration.

容器内没有找到这个类型的 Bean ,将 CachedUidGenerator 注册到 Spring 容器即可.

authors: mhiStrat uxfix

repo: baidu/uid-generator