Improvement to 'Change Windows Terminal default: powershell 5 -> powershell 7'

Main Idea
Change the Start Menu Button Right Click from PowerShell to Windows Terminal (by default on windows 10, it'll be CMD and you can change it to PowerShell (version 5), but not Windows Terminal through settings app).
So "in a nutshell", have the Right Click Context Menu behave like Windows 11.
Screenshots

Windows 11 Start Menu Button
Credits
This idea was provided by @Marterich

You just need a 22H2 build of Windows 10 and Windows Terminal installed, huh? 🤔

Seems to be a bit more complicated than anticipated.
https://github.com/PowerShell/PowerShell/issues/12872
An idea to try to find out how the implementation differs from win10 to win11 would probably be a quite tedious comparison of the registry

I have used this feature, and my right click menu link is broken for it. win 10 ltsc 21h2.

check this out
https://stackoverflow.com/questions/66447566/how-to-set-powershell-7-as-default-and-remove-other-versions


revive CODEOWNERS

📝 Description
This PR uses the previous CODEOWNERS to allow each team to be pinged on specific part of the code.
If some of the rules are not necessary for your team, please provide a fix on this PR directly.
⚠ Right  now this CODEOWNERS just serves as a notification status. No PR will be  blocked by the codeowner status
❓ Context

Impacted projects: monorepo
Linked resource(s):  LedgerHQ/ledger-live-issues#3

✅ Checklist

[x] Test coverage
[x] Atomic delivery
[x] No breaking changes

📸 Demo
No Demo
🚀 Expectations to reach
Allows team to be pinged when specific part of code is changed.
Closes https://github.com/LedgerHQ/ledger-live-issues/issues/3
Please make sure you follow these Important Steps.
Pull Requests must pass the CI and be internally validated in order to be merged.

Also assigning ledger-live as a reviewer since (unlike most PRs) this change is relevant to the full team. :slightly_smiling_face:

Exceptionally assign the whole ledger-live team for changes on @ledgerhq/types-live because they're relevant to everyone

@haammar-ledger No please, they are not relevant to the devx team and I would like not to get pinged.

Exceptionally assign the whole ledger-live team for changes on @ledgerhq/types-live because they're relevant to everyone

@haammar-ledger No please, they are not relevant to the devx team and I would like not to get pinged.

@jelbaz-ledger Got it, sorry for not thinking about your use-case. Fixed :+1: please re-review.


Issue Processing Descendant Selectors

Let me start by saying that I am unsure whether this is a true issue, or whether there is a gap in my understanding of how CSS Modules should be implemented.
I am using Gulp and postcss-modules, working with a very basic set of CSS and sample HTML files. I also have a small Gulp task that simply replaces instances of class="xxx" with css-module="xxx" in the HTML.
Original HTML:
Lorem ipsum

Converted HTML:
Lorem ipsum

This process works great, and without any issues at all. But I did notice that when trying to process descendant selectors, there was a (silent) error. The following does not work as expected:
Original HTML:
Lorem ipsum

Converted HTML:
Lorem ipsum

Are descendant selectors not meant to be supported?

Yes, each tag could have only one CSS module. So css-module="one two" is invalid.
Though, in your CSS file you can combine them:
.one-two {
    composes: one two;
}

In your HTML you'd have css-module="one-two" then. Consider this just as a syntax example. Concatenating automatically all CSS classes into one CSS module name probably isn't a good idea.

@avoision sorry, I was wrong. One tag could have multiple CSS modules. A new plugin version that supports it would be released soon (check also #7).


generate: do not dereference symlinks in link target

Fixes: https://github.com/sclorg/s2i-python-container/issues/272

thanks


Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # module.apply_aws_sat_location.null_resource.createIfNotExists will be destroyed
  - resource "null_resource" "createIfNotExists" {
      - id = "8409264704357310651" -> null
    }

  # module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location will be destroyed
  - resource "null_resource" "satellite_location" {
      - id       = "2014765997865129552" -> null
      - triggers = {
          - "API_KEY"        = "NEbVeyabM26IvMkS-Xxw2hrhZqkpVxah7wA8m8aTm_RX"
          - "ENDPOINT"       = "cloud.ibm.com"
          - "LOCATION"       = "aws-us-east-1-nvirginia-test-z-2"
          - "PROVIDER"       = "aws"
          - "REGION"         = "us-east"
          - "RESOURCE_GROUP" = "Default"
        } -> null
    }

Plan: 0 to add, 0 to change, 2 to destroy.

  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

   Resources: 2 destroyed.

But when I look in the IBM Cloud Satellite locations GUI, I see this

Subsequent tf destroy runs show this:
Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

Destroy complete! Resources: 0 destroyed.

Expected
The satellite location isn't hanging after tf destroy

@Zman94
It's an issue with satellite SDK. CLI failed to call the delete function.
In order to reduce the risk of CLI failure, Added retry logic in the script which will allow the operation to be re-executed if it fails.
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location (local-exec): Removing location aws-us-east-1-nvirginia-test-z-2...
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location: Still destroying... [id=2014765997865129552, 10s elapsed]
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location: Still destroying... [id=2014765997865129552, 20s elapsed]
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location: Still destroying... [id=2014765997865129552, 30s elapsed]
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location (local-exec): FAILED
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location (local-exec): Could not complete request:
module.apply_aws_sat_location.module.satellite-location.null_resource.satellite_location (local-exec): Unable to connect to https://containers.cloud.ibm.com/global/v2/satellite/removeController

Ok. Thanks for the response. I raised an issue in GHE and I'll report these findings back there. Perhaps we can get an issue opened on the SDK side

I tagged you in the issue to get a bit more clarification on the SDK  issue

@Zman94  confirmed that the fix is working.


Hash Id values to reduce size of translation files

To enable consistently short id values to be generated, provide an option that will hash each message id.
This could be designed to support multiple algorithms, but initially I suggest the murmur3 algorithm due to its low collision rate and 32bit output. An example configuration:
{
  "plugins": [
    ["react-intl-auto", {
      "idHash": "murmur3",
      ...other config
    }]
  ]
}

When used with #13, it allows id hash values to be consistent across builds unless:

The object key name is changed in the original javascript message file
The variable name used to generate the id value changes

Id hash values will not change if the file is renamed or moved, this is good in scenario's where translations have already been performed.
Essentially, its just:
var murmurhashJs = require("murmurhash-js");

// Function to converta 32 bit integer to an array
// https://stackoverflow.com/questions/15761790/convert-a-32bit-integer-into-4-bytes-of-data-in-javascript
function toBytesInt32 (num) {
    arr = new ArrayBuffer(4); // an Int32 takes 4 bytes
    view = new DataView(arr);
    view.setUint32(0, num, false); // byteOffset = 0; litteEndian = false
    return arr;
}

// Generate a short hash for each message id value
const idHash = murmurhashJs('message_identifier');
console.log(Buffer.from(toBytesInt32(idHash)).toString('base64'));

You can run that here with a quick copy & paste.
Would you accept this as a PR?
Adam.

Umm...
I think it complicates key management.
And I don't want to increase options anymore.
However you can create new library for this :)

For anyone looking for a way to reduce the length of the id values, and thereby reduce you're bundled application size, you can use babel-plugin-react-intl-id-hash with this plugin.
This reduces the id value of each message to 8 characters.
@akameco, not sure if you'd be interested in adding 1 line about this to the readme?

Sure.
PR Welcome 😀


executeWithSigner, different IMPL from different Wallet Providers?

We have received reports from various DApps integrating WalletConnect, experiencing different behaviors between different wallet providers when using .executeWithSigner().
The official WalletConnect implementation does not wait for the receipt. However, it appears that the implementation in HashPack waits for the receipt, while the Kabila Wallet returns the TransactionResponseJSON directly. This discrepancy is causing issues, such as the Davinci team encountering "Contract Revert" or "SUCCESS" responses in HashPack but not receiving any response in other wallet providers.
The official WalletConnect implementation only performs: await signer.call(body).toJSON(). Could you give us some light in this issue @teacoat
Thanks.

As a dapp development team, all we really need is to get an error from the wallets when a smart contract call is reverted. I’m not sure why this isn’t standard. The hedera-wallet-connect package docs don’t explain how a dapp can tell when a call has been reverted, which means either the wallet should tell us or we have to handle it on our backend. This seems like a missed opportunity for making things easier on our end.
I must mention I don't have a full understanding of how Walletconnect ecosystem works.

@AdrianKBL HashPack returns the standard message, hashconnect takes care of getting the receipt on the dapp side.

@AdrianKBL I see what you mean, apparently we should only be returning precheck codes rather than any error response code, will update


Update eu_central_bank.gemspec

Keeping it compatible with money-rails, which already refers to money 6.6

Checks are failing.

Awww. True, have to update a code as well. Will ping you once it's done :)

Thank you for PR.
I will close this PR because money is upgrade in https://github.com/RubyMoney/eu_central_bank/commit/63782a7b90d2f1cbad0169b618175444dbfb2ec8 .


Feature/Programming-Exercises/Visualize build process for students

Checklist

[x] I tested the changes and all related features on the test server https://artemistest.ase.in.tum.de.
[x] I documented my source code using the JavaDoc / JSDoc style.
[x] I added integration test cases for the server (Spring) related to the features
[x] I added integration test cases for the client (Jest) related to the features
[x] I added screenshots/screencast of my UI changes
[x] I translated all the newly inserted strings

Motivation and Context

Currently in the Artemis client, there is no feedback that a build for a programming exercise is running.
However we do have the information about a running build as there is a submission without a linked result (the submission is created after commit, the result after the build is finished).
Description

A new service provides information about pending submissions in the client:

Initially checks for a pending submission via http call
After that listens on the ws for new submissions
If there is a pending submission, a spinning circle is shown in the updating-result comp
When no result is created within 1 minute, an error message will be displayed (see screenshots)

The last pending submission is defined by the following criteria:

Is the newest submission for a participation based on submissionDate
Does not have a result yet
Is not older than 1 minute

:information_source: Known bug: When a test repository commit is made: :information_source:

No submission is created for the template & solution participation
The submissions created for the student participations can't be connected to the incoming results as for the submission creation the test repo commitHash is used and for the result the student assignment repo commit is used.
Both issues are fixed in: https://github.com/ls1intum/Artemis/pull/695

This feature works on all pages that show the updating-result component!

[x] Notify the client when the Artemis Server retrieves a new submission over websocket "/topic/participation/" + participation.getId() + "/newSubmission"
[x] Handle this websocket notification on the client in updating-result.component.ts.
[x] Display an animation with e.g. "Building and Testing" in the result updating-result.component.html or result.component.html instead of showing the last result. Typically this animation will be shown around 5s.
[x] When the client finally receives the new result over websocket "/topic/participation/" + participation.getId() + "/newResults", the animation is stopped and the new result is displayed.
[x] When the client does not receive a new result in less than e.g. 30s or 60s, the client should display an error message that the result was not received and that the user should push some changes again (in the future, we can work on this scenario and try to further improve it)
[x] Include jhi-alert in course-exercise page so that error can be shown.
[x] Bug: Buttons in code-editor need to be renabled when the result did not come in in time.

Steps for Testing

Log in to ArTEMiS
Open the code-editor
Submit code
=> Check that the building process is visualized

Screenshots

Until a result is returned OR the timer runs out:

When the result timer runs out (after 1 min):

In other areas as e.g. the course-exercise-list:

There were issues with the spring tests that came from the merge with https://github.com/ls1intum/Artemis/pull/695:

The dynamic tests did not properly reset the database as they couldn't use the BeforeEach hook properly -> I know use Parameterized tests: https://blog.codefx.org/libraries/junit-5-parameterized-tests/
The programming exercise participations were not properly deleted on resetDatebase, I changed the order of the deletion operations.

Another general note: I was wondering, whether we should increase the timeout from 60s for scenarios in-class to e.g. 120s or whether we can somehow use a more dynamic value.
If 1000 students submit at the same time and we have 25 build agents which need around 10s to compile & test, then students might need to wait around 6-7 minutes in the worst case. This would mean that a lot of students would immediately trigger another build, which would make the situation worse.
We could think about a dynamic timeout, but then we would need to know the server load. Can we determine this easily?
One option would be that we ask Bamboo about the build status after 60s. I don't think we can do that directly from the Artemis Angular client (because we don't have the permission rights), and when we go through the Artemis server, we need to make sure, that it is not very performance intensive.
Another option could be to regularly check the build queue (see https://developer.atlassian.com/server/bamboo/bamboo-rest-resources/#build-queue-service, would be basically https://bamboobruegge.in.tum.de/rest/api/latest/queue) on the Artemis server (using a cron job, e.g. every 10s). This value could be stored in a cache and could be returned together with the submission that does not have a result. We could use this as indicator.

If many builds are waiting in the queue, we increase the timeout.
If the queue is empty, we decrease the timeout.

Do you have any other ideas?
@sleiss what do you think about this case?

Another general note: I was wondering, whether we should increase the timeout from 60s for scenarios in-class to e.g. 120s or whether we can somehow use a more dynamic value.
If 1000 students submit at the same time and we have 25 build agents which need around 10s to compile & test, then students might need to wait around 6-7 minutes in the worst case. This would mean that a lot of students would immediately trigger another build, which would make the situation worse.
We could think about a dynamic timeout, but then we would need to know the server load. Can we determine this easily?
One option would be that we ask Bamboo about the build status after 60s. I don't think we can do that directly from the Artemis Angular client (because we don't have the permission rights), and when we go through the Artemis server, we need to make sure, that it is not very performance intensive.
Another option could be to regularly check the build queue (see https://developer.atlassian.com/server/bamboo/bamboo-rest-resources/#build-queue-service, would be basically https://bamboobruegge.in.tum.de/rest/api/latest/queue) on the Artemis server (using a cron job, e.g. every 10s). This value could be stored in a cache and could be returned together with the submission that does not have a result. We could use this as indicator.

If many builds are waiting in the queue, we increase the timeout.
If the queue is empty, we decrease the timeout.

Do you have any other ideas?
@sleiss what do you think about this case?

Increasing the timeout is no problem, but the rest is imo out of scope for this PR.

Another general note: I was wondering, whether we should increase the timeout from 60s for scenarios in-class to e.g. 120s or whether we can somehow use a more dynamic value.
If 1000 students submit at the same time and we have 25 build agents which need around 10s to compile & test, then students might need to wait around 6-7 minutes in the worst case. This would mean that a lot of students would immediately trigger another build, which would make the situation worse.
We could think about a dynamic timeout, but then we would need to know the server load. Can we determine this easily?
One option would be that we ask Bamboo about the build status after 60s. I don't think we can do that directly from the Artemis Angular client (because we don't have the permission rights), and when we go through the Artemis server, we need to make sure, that it is not very performance intensive.
Another option could be to regularly check the build queue (see https://developer.atlassian.com/server/bamboo/bamboo-rest-resources/#build-queue-service, would be basically https://bamboobruegge.in.tum.de/rest/api/latest/queue) on the Artemis server (using a cron job, e.g. every 10s). This value could be stored in a cache and could be returned together with the submission that does not have a result. We could use this as indicator.

If many builds are waiting in the queue, we increase the timeout.
If the queue is empty, we decrease the timeout.

Do you have any other ideas?
@sleiss what do you think about this case?

Increasing the timeout is no problem, but the rest is imo out of scope for this PR.
I do however see the concern and think this would be a good feature! 👍 I also agree to the general approach on how to handle this by going over the Artemis server.

I agree this is out of scope. Let’s brainstorm on a good but easy to implement solution and let’s implement this then in another PR

@krusche
Thanks for your review. I made 2 changes to improve the feature:

Increase result timeout to 2 minutes
Remove submissionDate filtering from server. Instead the last submission is sent to the client if it does not have a result regardless of the submissionDate. The client will then show an error when the received submission is older than 2 minutes. I agree this is the best solution :+1:


Heritage picker doesn't show Kholo heritages when Kholo Ancestry is selected

Freshly made table on the latest version, no modules installed.

They may still be marked with gnoll in the data. Tripkee may have the same problem.


Fix values responsive

What did you do?
Fix accessibility issue and response issue on the value page.
add your description here
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas

Many false positives on this page related to table layout

Hidden accessibility issue in report above are from the nuxt dev tools. The dev tools are not part of the live site.

iPad air version of values page

@yrabun @eveandsn see comments above.


Bump analyzers and use C#12 syntax

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (57cc176) 94.36% compared to head (e030e13) 94.37%.

Files
Patch %
Lines

src/PublicApiGenerator/ApiGenerator.cs
87.50%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #338   +/-   ##
=======================================
  Coverage   94.36%   94.37%
=======================================
  Files          17       17
  Lines        1172     1174    +2
  Branches      214      214
=======================================
+ Hits         1106     1108    +2
  Misses         39       39
  Partials       27       27

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


Add Owin extension for convenience

IApplicationBuilder has a very convenient extension that we can add a middleware like
app.Use((context, next) =>
{
    // do something
    return next();
});

rather than
app.Use(next =>
{
    return context =>
    {
        // do something
        return next(context);
    }
});

The former one is much more straightforward and easier to understand and to use.
Asp.Net Owin (Project Katana) also has a similar extension, but Asp.Net Core Owin doesn't. Therefore, I propose to add a similar extension to Asp.Net Core Owin so that we can align them and write code easier like:
app.UseOwinEx(addToPipeline =>
{
    addToPipeline((env, next) =>
    {
        // do something
        return next();
    });
});

Here is the pull request including test case.

@kchanlee,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@kchanlee Thanks for the PR. Closing it as it became a stale one.  Please file a bug to bring the discussion back on track if you'd still like to pursue this. Thank you.


Toggle of .grde1 not working

Im typing in the command to toggle turning on and off greet/bye msgs but its not working. I toggled it on so it deletes the msgs but i wanna toggle it off and its not working. im typing in the command .grde1 but its not turning the message delete off. Sorry complete noob when it comes to this. I wanna see the msgs so i know who is leaving and entering the server. thanks for help!

Easy. It's not .grde1, it's .grdel. Small "L", not 1 at the end.


reintegrate music and add jukebox variants

Adds the original music back into the pack.
Adds optifine textures for the jukebox for the new music discs.
Adds variants to the vanilla jukebox for each of the music discs.
Adds 2 new songs for music disc's 5 and pigstep.
Updates the license to reference the copyright holders of the music in the pack.

[x] I have made and am willing to license my contribution under the MIT license, or have permission from the original author to license it under MIT.

shouldn't the music disks be mono? (tested pigstep, but the rest am not sure

I don't know.

I believe making them mono enables the direction-ness of the juke box (it sounds like its coming behind you, etc)


[Improve][feature][Bug] Add Tooltip and  Fix Design Issue In the Task Definition

[Bug]
When screen height is reduced or more items added in the task synchronization definition sidebar, tiles are falls out of the task synchronization definition sidebar.

Purpose of this pull request
This PR aims to enhance user experience by improving navigation through the task synchronization process and Fixed the above mentioned bug.
Changes Introduced:
Tooltips for Task Tiles : Added tooltips to the Source, Sink, and Transform tiles in the task synchronization definition sidebar. The tooltips provide guidance on dragging and configuring the tiles.
Bug Fix : Addressed a bug that affected the display of the sidebar when the screen height was reduced or when more items were added.
How It Works:
Hover Over Info Icon : When hovering over the Info icon added to the right side of the task synchronization definition sidebar tiles, a tooltip will appear with helpful instructions.
After Dragging Tiles : When dragging Source, Sink, or Transform tiles onto the canvas and selecting them, hovering over the tile will display a tooltip with additional instructions.
Additional Notes:
This is my first pull request. I would appreciate any comments, suggestions, or advice to improve it.
Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs

cc @arshadmohammad

Hi @Hisoka-X,
I'm unable to address this Issue. Could please explain what is happening? How Can I Overcome this Issue?
cc @arshadmohammad

Please try merge from dev.

Hi @Hisoka-X, I've merged from main. Could you please rerun the checks.

Thanks @Hisoka-X

Thanks @SachinS10-lab for raising this PR. I will review it.
Meanwhile can you please remove the extra commit from your PR.

cc @baicie

@arshadmohammad. Sorry for the delay. Is it really needed to remove one commit?

@arshadmohammad. Sorry for the delay. Is it really needed to remove one commit?

IMO, unnecessary. We will execute squash and merge when merge to dev.


fix: test_dist_table_scan block

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?
test_dist_table_scan could be blocking for multiple reasons:

the tasks that were producing the RecordBatch result items ignored the sending error

test_dist_table_scan uses CoalescePartitionsExec to merge partitions data
CoalescePartitionsExec will spawn multiple tasks that each of which gathers one partition's RecordBatch result to a final output stream, through a mpsc channel
the task ignores the sending error, thus even if the receiver has decided to quit, the sender(the task) don't care (fixed in this PR: https://github.com/apache/arrow-datafusion/pull/3276/files)
the task thus keeps polling the stream, in a while let Some loop

the stream being polled always returns Some if the stream is failed to init

never return None means we have an infinite loop in the above task
casuing tokio runtime busy, other tasks like heartbeats are not likely to proceed (hence the many error backtrace logs)

The fix is simple, upgrade to newer version of DataFusion(done), and make the stream able to emit None.
Checklist

[ ]  I have written the necessary rustdoc comments.
[x]  I have added the necessary unit tests and integration tests.

Refer to a related PR or issue link (optional)

@waynexia all comments resolved, PTAL


position offsets

In the paper, you said "We use the same scale factor σ as described in Section 3.4 to normalize the position offsets within a sensible range". But in your code you used pos_std=[.5, .36, .5] to do normalization ? How did this pos_std come from ? Thank you.

@Jiayi719 Any updates on this issue?


Consider changing insert(records).into(table) to insert_into(table).values(records)

There are two main things that got me thinking about this change. The first is this code. It's a papercut, but I don't like the fact that if you get the argument to insert wrong, the message is going to be that you passed the wrong number of arguments to into. Maybe this isn't a big deal (I don't think it's ever come up in gitter), but it's a paper cut I'd like to avoid, and I think it will be easier to run into once #789 is done.
The second is that I've been thinking about an API to represent INSERT INTO table (column_list) SELECT .... The best idea I've seen based on our current API is insert(select_statement).into(column_list), but that feels a little implicit to me. If we changed the insert API, I could see something like insert_into(table).columns(column_list).values(select_statement) or insert_into(table).from_select(column_list, select_statement) being much more reasonable.

@diesel-rs/contributors WDYT?

I like it.


Keywords for management of components

LGTM, one proposal for an improvement would be to unify the code - so these two keywords would use one common implementation by addition also the operation parameter. WDYT @jiripetrlik ?

I was able to successfully run this with Jenkins. @sutaakar @jstourac @jgarciao Can we merge now?


Update kmart_inhale

@danielmlow this and the other 2 PRs are irrelevant now I think, right? Can I close them?

@danielmlow this and the other 2 PRs are irrelevant now I think, right? Can I close them?

Yes. But the final version has to have "Coke" and "Coca Cola" instead of lower-case "coke" and "coca cola". Thanks!

can we address these PRs or close them.


Introduce Basic Staging Capabilities Utilizing the Policy Staging Ref

Introduce basic staging capabilities utilizing the policy staging ref

listr-ules is being modified only for the purpose of seeing the difference between the policy staging ref and the policy ref.

Rebased the code with main 👀 @adityasaky

FYI: I think we should also think about having the ability to stage and merge changes to different policy files independently.

@adityasaky @JustinCappos Does each RSL entry only change one policy file at a time, since if not, staging policy files seperatly would be impossible, since we could not stage a commit that changes both file a and b if we only want commits that change file a

I have rolled back the changes to the simple version of policy staging

@patzielinski: I tried out the policy-staging for serial signing. Can you build off this branch and kick the tyres some more? I primarily stayed on the happy path FWIW.
@neilnaveen , @wlynch: I've added some helper commands such as the ability to just sign the root metadata as well as bump the root role's threshold. Neil, can you take a look at my commits? Billy, I think the whole PR could use a review by you.
Also, this functionality is still marked developer-mode only, which I think is fine to keep as is for now.

I think the commits look good, and having the functionality under developer mode also seems to be a good idea, since should not be a regularly used feature at the moment

there are a bunch of new commands included here that look to be unrelated to this change.

yep! I added some commands to allow users to add their extra signatures, which is one of the primary motivations to have a staging area (add root.json with all root keys, sign serially, then apply). This did muck up the PR a bit but it allowed for IRL testing of the staging bits.

@wlynch could you take a look at https://github.com/gittuf/gittuf/pull/260/commits/1c6c2a5088682cc443c35aebfdde28d846e13550 and https://github.com/gittuf/gittuf/pull/260/commits/93da1fc46e185efec141cd198bb8b41903ca8809? I noticed that root threshold wasn't being verified on apply and realized we needed to handle a couple more edge cases with apply. In my playground, I'm seeing expected behavior both in success and failure cases.


adjustment of updating node

Codecov Report

Merging #353 (b887e1d) into master (9ff7158) will not change coverage.
The diff coverage is 64.70%.

:exclamation: Current head b887e1d differs from pull request most recent head 0adfc0a. Consider uploading reports for the commit 0adfc0a to get more accurate results

@@           Coverage Diff           @@
##           master     #353   +/-   ##
=======================================
  Coverage   65.39%   65.39%
=======================================
  Files          94       94
  Lines        6423     6423
=======================================
  Hits         4200     4200
  Misses       1627     1627
  Partials      596      596

Impacted Files
Coverage Δ

api/node.go
65.10% <33.33%> (ø)

plugin/database/cron.go
66.66% <50.00%> (ø)

facade/application.go
87.50% <100.00%> (ø)

Continue to review full report at Codecov.

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


chore: fix typo

Pull Request Title
Description
Please include a summary of the change or the feature being introduced. Include relevant motivation and context. List any dependencies that are required for this change.
Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings

Related Issue(s)
This PR addresses issue #X
Screenshots
If relevant, please add screenshots.
Notes
Please add any relevant notes if necessary.

Thanks for the typo update @studystill
To register as a contributor of our repo, please read the contributing guidelines (here) and open a separate PR where you will add yourself to our contributors list. (an example PR can be found here)

Hi @studystill ,
We just updated our policy to contribute to the repo.
This change requires all commits to be signed off with your name and email. You can find out more about the change in this commit.
Please read through the change, squash your commits and sign them like this:
git rebase -i HEAD~X where X is the number of commits
git commit --amend --signoff

Signoff will automatically include the signature required to be a contributor to Daytona.
Let me know if you have any questions about this process or need any help.


Merge branch 'master' into cognitive-services-integration

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: DavidGrob-V-MS sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Face API integration module


Proposal: Move Shields to Heroku and inaugurate a new ops team

From time to time I’ve proposed some changes to our hosting, in particular migrating to a PaaS.
Our current hosting setup has a couple of advantages:

It’s extremely inexpensive.
SSH and VPS are common technologies and many developers are familiar with them.

But it also has some significant disadvantages:

Access to deployment is bottlenecked on one person (@paulmelnikow).
Our three servers have been struggling to sustain the current request load and we don’t have a reproducible process for adding new ones. There is a custom git post-receive hook which installs the code. It’s not documented. It’s missing features, like the ability to omit dev dependencies (#1988), or update the npm or node version without rebuilding the server. This has become a huge concern lately and has prevented us from updating dependencies, as Node 8 has reached EOL (#3403).
On regular occasions our service provider OVH experiences downtime in one datacenter or another. Nothing picks up the slack, and the entire service becomes slow and unstable. (#4878 #1568 et alia)
Adding servers, re-deploying servers, and accessing the service provider’s dashboard is bottlenecked on one person (@espadrine) who has not been actively involved in the project lately. (#2577)
Only that person can see the logs.
The deploy process introduces several minutes of instability. Each server is down for about a minute. When a single server is down, the entire service is unreliable because (1) requests are still sent to the down server and (2) the remaining servers couldn’t handle the load anyway. So the overall deployment downtime lasts several minutes.
Round-robin DNS doesn’t distribute traffic intelligently based on region, or evenly across multiple servers.

I’d like to propose moving the production servers to two Heroku clusters, one in the United States and a second in Europe. We’d configure Cloudflare geographic load balancing to direct traffic to the EU servers in priority over the US servers. Initially these would both use Standard-1X dynos, scaled manually, though we can consider adding auto-scaling in the future. The dynos would be sponsored by Heroku so there would be no cost to the Shields community. We have a platform credit on file though we probably will need to renew that for the upcoming year. We will save the very small amount of money since we’ll no longer need to pay the hosting costs of our current servers.
From the core maintainer team, Shields will create a four-member ops team. Each member of this group will be responsible for developing and understanding of the whole system, considering the security implications of their actions and our privacy commitment before taking every action, and conferring with the rest of the core team whenever needed. They will be responsible for investigating operations issues when they occur.
Access to the production Heroku apps will be given to the four members of this team. This is according to the principle of “least privilege,” as access to the Heroku apps includes access to all the production secrets.
Deploys will be handled by any of these four active maintainers, after basic checks that the staging site is working. However it’s possible in the future that other maintainers could be given access to deploy or that deploy could be done automatically.
I’d propose @chris48s, @calebcartwright, and @PyvesB join me as the four initial members of this group. If @espadrine wants to, he could join as a fourth/backup person. If not, the rest of us could consult with him as needed and give him our sincere thanks for the massive responsibility he’s carried over the years. As part of formalizing #2577, we could revisit the ops team’s membership, and how this responsibility is rotated over time.
There are many advantages to this approach:

Deploy bottleneck is removed. Deploying is fast, and triggered in the cloud by a couple clicks in the UI. Rollbacks can be done with a couple clicks, too.

This is a slight oversimplification. The frontend is statically hosted on GitHub Pages, so we’ll either need to deploy in two steps, integrate the GitHub Pages deploy, or move the frontend hosting to Heroku. (Let’s not get bogged down on this issue, as we can address it later, independently.)

Log access bottleneck is removed.
All actions related to the production apps are logged by the Heroku platform, providing transparency around the ops team’s actions.
Deploys have zero downtime. Heroku’s dyno manager brings up the new instances before it takes the old instances offline, ensuring the configured capacity is always available.
Cloudflare’s geographic affinity provides better response times.
Upgrading node and npm is as simple as editing our package.json.
We will have close to 100% parity between review apps, staging, and production environments.
As the Heroku platform is widely used, most problems we will encounter in the future have existing recipes, either as platform features or pre-integrated add-ons. For example, if we want to add a logging platform we could integrate Papertrail, Loggly, etc.
After reaching a modest level of familiarity, most actions are very fast. For example, I just deployed the new EU servers in about 5 minutes, with one command on the command-line and a few clicks in the UI.

It has some disadvantages, too:

While some basic metrics like response times and resource utilization are provided by the Heroku platform, the metrics we’ve been providing with Prometheus are not designed to be PaaS-friendly. We may need to do some work on our own to get Prometheus working with Heroku. (#3946) (This issue was solved this weekend. Thanks @platan! 🎉 )
For developers who are more familiar with running servers and EC2, Heroku has a small learning curve.
Apps should conform to the 12-factor principles. For example, you can’t rely on a persistent file system or ssh / https access into a specific instance. This isn’t a big problem for Shields. Most of this work was tackled as part of #1848, and persistent storage and communication have been handled in Cloud Redis since #3332.
Since Heroku only supports two regions for public servers, in order to expand into Russia, Asia, etc., we would need to use Heroku Private Spaces.

Clearing this bottleneck would be a very, very good thing for this project’s health and sustainability.
Thoughts? Concerns? Questions? Especially looking for input from maintainers here, though comments are welcome from the community, too.

I'm onboard with this :+1:
2 questions:

Do we have a ballpark of what the total cost of this solution would be? It's great that the dynos will be sponsored (which is awesome!), but still good to have an idea of the total cost of ownership with this solution (especially in case anything ever changes).

We’d configure Cloudflare geographic load balancing to direct traffic to the EU servers in priority over the US servers

^^ Will that priority be categorical or take origin location into account? If the former, is there any potential increase in latency (for example if the majority/plurality of requests hitting the badge servers today are originating in the US today and most of those are getting routed to the servers in Canada, etc.)

Do we have a ballpark of what the total cost of this solution would be? It's great that the dynos will be sponsored (which is awesome!), but still good to have an idea of the total cost of ownership with this solution (especially in case anything ever changes).

Yea, that's a good question. It'd be nice to work out that number. When I asked for the donation I worked out a high estimate based on some number of Standard-1x dynos. Let me see if I can track it down.
I definitely don't want to churn on hosting providers, but I think if cost were to become a deciding factor, we could move pretty easily to a technically similar cloud-based service like Google App Engine, AWS Elastic Beanstalk, or Azure App Service. Something based on Lambda, like Zeit Now, could also work, though it'd require some major rearchitecting to operate efficiently in Lambdas. Also if we had to pay for something like Zeit, given how many requests we can pack onto tiny servers, the cost per request would be higher.

Will that priority be categorical or take origin location into account? If the former, is there any potential increase in latency (for example if the majority/plurality of requests hitting the badge servers today are originating in the US today and most of those are getting routed to the servers in Canada, etc.)

Yea, taking location into account – that's what I meant to write. (Sorry, the way I phrased that was not at all clear!) The hope is that localizing the server handling the request is only a plus. Although we may have to experiment with that a bit, as our performance is also depends on the regional performance characteristics our upstream providers.

I definitely don't want to churn on hosting providers, but I think if cost were to become a deciding factor,

I don't think we need to, Heroku seems like the right choice. This is something we can potentially figure out later on too post migration. I'd just like to have a rough $ of what it costs to run, even if sponsorships are covering things.

That's great news!

I’d like to propose moving the production servers to two Heroku clusters [...]

How exactly this process of moving form OVH to Heroku could look like? Do you want to move to Heroku gradually or switch all at once? Does Cloudflare allows to control amount of the traffic send to a specific domain (something better than round-robin)? With round-robin we can do it gradually by adding a new domain (e.g. s4.servers.shields.io) handled by Heroku - this should direct ~ 1/4 of the traffic to Heroku. This will show how Shields@Heroku performs.

However it’s possible in the future [...] that deploy could be done automatically.

We have great (live) service tests which can be used to check if a newly deployed version works properly (using https://github.com/badges/shields/blob/master/core/service-test-runner/cli.js#L16). We do not have to run all of them, maybe one or few for every service will be enough.

The sooner we can make the transition the better IMO. Let me know what I can do to help.

Has anyone already reached out to @espadrine via mail to make sure he doesn't miss this?

I don't think we need to, Heroku seems like the right choice.

👍

This is something we can potentially figure out later on too post migration. I'd just like to have a rough $ of what it costs to run, even if sponsorships are covering things.

Not knowing for sure how many we'd need, I'd sent them what seems to be an extremely high estimate:

A rough estimate is that we’d need 5-10 Standard-1X dynos, plus one for our staging server, which would come to $150–275/month.

How exactly this process of moving form OVH to Heroku could look like? Do you want to move to Heroku gradually or switch all at once?

Yes, I think gradually would be a good idea.

Does Cloudflare allows to control amount of the traffic send to a specific domain (something better than round-robin)? With round-robin we can do it gradually by adding a new domain (e.g. s4.servers.shields.io) handled by Heroku - this should direct ~ 1/4 of the traffic to Heroku. This will show how Shields@Heroku performs.

I think Cloudflare offers a lot of fancy ways to do load balancing, however the round-robin is already set up and seems fine for the purpose of this transition. We can reconsider how load-balancing works when adding the second region.
Your suggestion is good: spin up a couple dynos, add the Heroku app as a fourth server, and see how it all goes, before we start removing anything.

Has anyone already reached out to @espadrine via mail to make sure he doesn't miss this?

Yep! I sent him an email when I posted this. If he responds to me directly I'll report back here.

The sooner we can make the transition the better IMO. Let me know what I can do to help.

Before we get too far along, it'd be great to get @espadrine's approval and find out how he wants to be involved in this.
Though if we haven't heard from him for a few days, perhaps we should meet to continue the conversation.

@paulmelnikow Curious what you view as the difference in terms of #4878 for this. Is it just that Heroku will be more reliable and the current server system is not? I guess my question is, are we confident that this proposal will fix #4878? Nothing I saw in the proposal really discusses that or gives much insight into the problems mentioned in #4878.
Would love to help support this in anyway I can tho.

The hope is that Heroku has less downtime than OVH. But more importantly, with Heroku, we can add capacity with two clicks in the UI.

Does Cloudflare allows to control amount of the traffic send to a specific domain (something better than round-robin)? With round-robin we can do it gradually by adding a new domain (e.g. s4.servers.shields.io) handled by Heroku - this should direct ~ 1/4 of the traffic to Heroku. This will show how Shields@Heroku performs.

I think Cloudflare offers a lot of fancy ways to do load balancing, however the round-robin is already set up and seems fine for the purpose of this transition. We can reconsider how load-balancing works when adding the second region.
Your suggestion is good: spin up a couple dynos, add the Heroku app as a fourth server, and see how it all goes, before we start removing anything.

I was wrong about this. Since our round-robin DNS is using A records, we can't just drop Heroku, since it needs to be used either as a CNAME or with a reverse proxy in front of it.
Given the service is basically unusable for big chunks of our peak hours (#4878), I suggest as an experiment we move all the traffic over to Heroku and see how it works. I sent a second note to @espadrine proposing that.
Meanwhile the service is online here: https://img-test.shields.io/badge/build-passing-brightgreen

I have good friends at Heroku who could potentially help us with costs if we asked. Let me know if you'd like me to.

I was wrong about this. Since our round-robin DNS is using A records, we can't just drop Heroku, since it needs to be used either as a CNAME or with a reverse proxy in front of it.
Given the service is basically unusable for big chunks of our peak hours (#4878), I suggest as an experiment we move all the traffic over to Heroku and see how it works. I sent a second note to @espadrine proposing that.

I suggest to start cautious and move only a part of the traffic to Heroku. Creating a reverse proxy at a new VPS shouldn't be complicated or expensive.

I suggest to start cautiously and move only a part of the traffic to Heroku. Creating a reverse proxy at a new VPS shouldn't be complicated or expensive.

@platan I fully disagree with this. Anything you add to the chain adds complexity and is one more thing to maintain and manage. It’s also one more thing that could break.
It sounds to me throughout this entire proposal the goal is to reduce complexity and streamline the process. Adding another reverse proxy or VPS, seems directly against the goal of this proposal.
It sounds like this project already uses Cloudflare. Why can’t we utilize that more instead of another server to manage?

@fishcharlie, if I'm understanding @platan 's suggestion correctly, the reverse proxy VPS would only be useful during the transition period, to allow dual running and load balance part of traffic between the old servers and the new Heroku deployment. It's only complexity we would have in the short term. Cloudfare alone wouldn't allow that gradual transition, it would have to be clear cut.

@fishcharlie, if I'm understanding @platan 's suggestion correctly, the reverse proxy VPS would only be useful during the transition period, to allow dual running and load balancing part of traffic between the old servers and the new Heroku deployment. It's only complexity we would have in the short term. Cloudfare alone wouldn't allow that gradual transition, it would have to be clear cut.

@PyvesB I don't believe this is correct. I'm not sure how this project is utilizing Cloudflare, but Cloudflare does offer a load balancing feature. This would allow you to set it up to manage traffic between multiple servers. This would reduce the complexity of having another layer of infrastructure to setup, manage, and maintain. Why add complexity when a service you are already using provides the functionality you need??

@fishcharlie, if I'm understanding @platan 's suggestion correctly, the reverse proxy VPS would only be useful during the transition period, to allow dual running and load balancing part of traffic between the old servers and the new Heroku deployment. It's only complexity we would have in the short term. Cloudfare alone wouldn't allow that gradual transition, it would have to be clear cut.

@PyvesB I don't believe this is correct. I'm not sure how this project is utilizing Cloudflare, but Cloudflare does offer a load balancing feature. This would allow you to set it up to manage traffic between multiple servers. This would reduce the complexity of having another layer of infrastructure to setup, manage, and maintain. Why add complexity when a service you are already using provides the functionality you need??

Well, I know very little about the Cloudfare product, but I was basing my previous message on @paulmelnikow analysis: https://github.com/badges/shields/issues/4929#issuecomment-619177622

Well, I know very little about the Cloudfare product, but I was basing my previous message on @paulmelnikow analysis: #4929 (comment)

@PyvesB Ahh got it, missed that somehow. Yeah I'm still not in support of spinning up another system. Of course I won't be the one maintaining it, so it's not really up to me, and if someone is willing to take over that responsibility that is fine.
I guess my point is that anything is better than what is going on right now. Yes, jumping all into Heroku is a massive leap. But to me, the tradeoffs are worth it since this service is basically unusable for a large amount of the day. Spinning up another service right now when the team is struggling to maintain the current infrastructure seems like an extremely bad idea. The goal is to isolate the issue and fix it. Let's say the problem persists or gets worse with this new plan, it will add complexity to isolate the issue. Is it the load balancer that is having problems or is it Heroku? That will be a much more difficult question to answer by spinning up more failure points.
The whole goal here should be to reduce failure points, not increase them. Even during a transition period.
If that means jumping off the deep end and just going for it, I say that is a tradeoff worth making. It just requires the team to move quickly and ensure they have time blocked off and willing to fix any problems that come up quickly.
Sure there might be downtime, but I think that is inevitable at this point no matter the path forward, and the service is already experiencing major outages and problems. It can't get much worse...
I came to this thread via #4878 so to me this is an extremely high priority and urgent issue. I don't think spending the time spinning up a VPS, managing that, and adding another failure point is worth it. This is an issue that I think needs to be solved quickly and I don't think adding more infrastructure is worth the time. I know I might be alone in this, but I'd prefer the team to take a few risks here at the cost of the service being less stable short term to have a higher chance of stability in the long run.

You do have some good points. I would personally be in favour on moving to Heroku directly. As you said, it minimises effort and things can't get much worse.

I wanted to post a brief update on behalf of the ops team. The team, consisting of @chris48s @calebcartwright @PyvesB and @paulmelnikow, met yesterday and decided to move ahead with this experiment. Given Shields has been basically unusable for several hours a day, the team decided to make a wholesale transfer to Heroku rather than set up a proxy so the Heroku dynos could join the existing servers.
This went live last night with four dynos around 2:30 UTC. Traffic started flowing to the new dynos in seconds.
For the most part it’s been pretty stable. We ran into an issue we did not foresee. We generate a lot of traffic to services which have chosen to allow unlimited traffic to our server IP addresses. On Heroku the outbound traffic comes from unpredictable IP addresses, so we will need to develop a solution to that. In the meantime we’ve worked around that by proxying the JSON result from the legacy servers.
Heroku is designed to have smooth server transitions, however we’re seeing lots of errors, dropped requests, and memory peaks at the time of server transition. These only last a few seconds (whereas the legacy deploy would disrupt the service for minutes). I am not completely sure, though I think this may be related to scout camp, which binds the port before the server is fully set up. (Heroku is designed to give apps a minute or so to set up, but they have to wait to bind the port until they’re ready.)
(Thanks also to folks who have opined in this thread! We took your input into consideration.)

First of all. HUGE thanks and shoutout to @paulmelnikow @chris48s @calebcartwright and @PyvesB for making this happen!! Great work to everyone to make this transition.  So this was 100% a positive move and a huge step in the right direction.

Now on to some of the other things to continue to try to help support this process:
@paulmelnikow You might have seen this. But in regards to outbound traffic static IPs, it looks like Heroku offers Fixie as an addon. Which looks to support having all outbound traffic come from one IP address. Only downside is cost and limits. Looks like they have bandwidth and number of requests limits depending on how much you pay.
Since @olivierlacan offered, might be worth seeing if Heroku would be willing to offer any type of benefits since this is an open source project.
This would also likely require communicating with the services that bypassed your IP for unlimited traffic and notifying them of the new IP so they can whitelist it. Not sure how many services that includes, but that for sure looks like an option.
Resources:

https://elements.heroku.com/addons/fixie
https://devcenter.heroku.com/articles/fixie

I'd say the other option here is to transform that old service into a pure proxy. Downside to this is having to maintain more infrastructure. I haven't heard too many cases of proxy's getting overloaded with traffic, but as this project grows and scales more, that could be a consideration that might make it difficult and would merely just be kicking the can down the road.

In terms of startup flow and binding the port during startup, it looks like that PR and issue #4958 are good steps in that direction, and as far as I can see, look like it should be a good solution for fixing that issue.

Overall looks like a huge success with a few super minor pitfalls to work through to increase the stability moving forward. Huge shoutout to the entire team here!! Amazing work! 🎉

I got a quick message back from @espadrine that he was okay with us moving forward with this, however that a VPS would be more cost effective. That's totally true. However I think the bonuses of a platform like a Heroku outweigh the cost, particularly if we can continue to get services donated from Heroku.
Thanks @olivierlacan for the offer to reach out to them! We are operating on a donation from them at the moment, though in a few weeks we need to ask them to renew it for the year to come. I'll let you know when we're ready to do that, so we're coming in from both angles.
We appreciate the ops suggestions @fishcharlie! Let's continue the discussion about the proxy services at #4962 which was opened yesterday. The port binding issue helped a lot but didn't perfectly fix it; let's continue that at https://github.com/badges/shields/issues/4958#issuecomment-620365980. We can always use enthusiastic help on this project. Most of us have been at it for a while 😉 so if you're looking for ways to help, please do continue to jump in! If you want to chat about ways to get more involved feel free to ping me on Discord.

@paulmelnikow I'd be interested in reading a writeup about your experience with Heroku after a month or two of trying it out - What worked well, and what didn't work well.
Have you considered "serverless" (Azure Functions or AWS Lambda) as well? Maybe Shields isn't built for it (as apps need to be entirely stateless in order to work well with serverless technologies), but might be worth keeping in mind?
I wonder if it's worth considering something like Dokku too - It's similar to Heroku and is Heroku-compatible, but self-hosted, so you'd still get some of the benefits. Some of the disadvantages still apply (like round robin DNS not being ideal), but could be fixable.

@paulmelnikow I'd be interested in reading a writeup about your experience with Heroku after a month or two of trying it out - What worked well, and what didn't work well.

It's a cool idea! Thanks for suggesting it.

Have you considered "serverless" (Azure Functions or AWS Lambda) as well? Maybe Shields isn't built for it (as apps need to be entirely stateless in order to work well with serverless technologies), but might be worth keeping in mind?

Yea, I got into a discussion with folks at Zeit / Vercel a year or so back about moving Shields to Now 2.0. Shields is entirely stateless, so that's not a problem. There are other issues, though. Currently the startup time is very high. You have to load the entire project to execute a single badge. That is fixable, however it's a big refactor. (Not nearly as huge as the service refactor though!)
The bigger consideration is that Shields is extremely super CPU- and memory-efficient, so a long-lived process is very cost-efficient. Even if we had to pay full price for Heroku at fixed scale, paying full price for serverless executions would be more. (Yesterday, for example, we had 11.4 million uncached requests.)

I wonder if it's worth considering something like Dokku too - It's similar to Heroku and is Heroku-compatible, but self-hosted, so you'd still get some of the benefits of self-hosting plus some of the benefits of a PaaS platform. Some of the disadvantages still apply (like round robin DNS not being ideal), but could be fixable.

I don't have personal experience with Dokku, though our legacy setup uses a homegrown post-receive hook which works in a similar way. This approach doesn't provide smooth failover, which might be solvable, and you also need to choose a solution for provisioning / deprovisioning.
Millions of developers want Shields to be reliable and fast. If Heroku provides that, and is willing to keep sponsoring us, I'm really happy to use it. Maintaining Shields is a ton of work, and personally I would rather work on making the codebase friendly, engaging contributors, improving the quite dated frontend, and making the service awesome, than on running servers. We'll have to see how it goes!

Sounds good to me! Thanks for continuing to keep things running 😃

The Ops team has unanimously agreed that our Heroku experiment has been a success, and we have decided that we will continue to host Shields in our Heroku environment going forward.
As Paul noted above, there were a few minor issues we initially encountered and resolved, and a couple that we'll need to revisit with a longer term solution (#4962).
However, the new Heroku hosting environment has been a big improvement overall, and it has ameliorated the performance and reliability issues we were having with our previous hosting environment. It also provides us with greater agility and allows us to more easily scale dynamically to handle the badge server loads.
We'll continue to monitor the new environment and address the outstanding items to ensure Shields.io remains available and performant for the community.
Thanks to everyone involved!

Our status page is now targetting the new Heroku hosting environment as well!

Our status page is now targetting the new Heroku hosting environment as well!

The status page seems to have an invalid SSL cert though:
NET::ERR_CERT_AUTHORITY_INVALID
Subject: DDoS-Filter.domain

Issuer<EMAIL_ADDRESS>
Expires on: Oct 8, 2027

Current date: May 25, 2020

PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIID1zCCAr8CCQCyIVKOm3lw7TANBgkqhkiG9w0BAQsFADCBrDELMAkGA1UEBhMC
QUExFDASBgNVBAgMC0REb1MtRmlsdGVyMRQwEgYDVQQHDAtERG9TLUZpbHRlcjEU
MBIGA1UECgwLRERvUy1GaWx0ZXIxCzAJBgNVBAsMAkNBMSMwIQYDVQQDDBpwcm90
ZWN0QEREb1MtRmlsdGVyLmRvbWFpbjEpMCcGCSqGSIb3DQEJARYacHJvdGVjdEBE
RG9TLUZpbHRlci5kb21haW4wHhcNMTgwMTA4MTA0MTI2WhcNMjcxMDA4MTA0MTI2
WjCBrTELMAkGA1UEBhMCQUExFDASBgNVBAgMC0REb1MtRmlsdGVyMRQwEgYDVQQH
DAtERG9TLUZpbHRlcjEUMBIGA1UECgwLRERvUy1GaWx0ZXIxFDASBgNVBAsMC0RE
b1MtRmlsdGVyMRswGQYDVQQDDBJERG9TLUZpbHRlci5kb21haW4xKTAnBgkqhkiG
9w0BCQEWGnByb3RlY3RARERvUy1GaWx0ZXIuZG9tYWluMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEApcTkt6gJC/nhup2t7pMfO2Q0/N6D+faZGdUpNzuI
9OEBLpgJBDWLn3S/EkNoUd/sNxWZ1b6ZfZN6HhbBHg8L4iq/kMuGbak4tkQp8W3H
dU9sBl4Sey4Xr73UlffEtp2Z/FctUkh64mAKMgRwZNEa4JOukbp/4uEMr6su3O8b
7lzLJEAJUfSYsxSrRJxFLzVJj+ZWJcnxPL3AWEnjDnqGkAP7Yiskw/2mS0t+yz3C
YIYfIbbv/yGwPORsKM+b5fOISuSuIx1qu61gqnaHJmEkHz7tPk0IWSL7ipEiXNPp
58em6+x6R0eg+8Kcnf385WwDAXj1SUsyDqpWgRLsI1oyMwIDAQABMA0GCSqGSIb3
DQEBCwUAA4IBAQAW+7V+f4GsNGspP04xXnbiLjMAVyLllxySstANjorUe0C8/2bi
K0bcpZudPfw2tY0XyDOqFsyi0gQlsqiD7IXOyM2uXZ57ymc/GhcTCPGaKvq23OKS
lryKu67nDHEFxM4do+bRWkHi8WkTqAxxJmBy2+0J6Aky3j7Zrr2DsloDMZSItEQt
n4eMRU4+yJWD5pC+WpTexZGKFdSHQxdpZs1iowB0uIXQmiLWQEMSNrXZArqv4iwk
Byoo1p5Mb6u1TgMEX+yhs8ijlGwU1WH85uh5Pl0y0QnVu6M4Q+beZ4895OefTxBm
MpUGLeCV+XmGyP6hnyF+7ouHYgkdRI5TRhof
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIELTCCAxWgAwIBAgIJANmdUmCD9aU+MA0GCSqGSIb3DQEBCwUAMIGsMQswCQYD
VQQGEwJBQTEUMBIGA1UECAwLRERvUy1GaWx0ZXIxFDASBgNVBAcMC0REb1MtRmls
dGVyMRQwEgYDVQQKDAtERG9TLUZpbHRlcjELMAkGA1UECwwCQ0ExIzAhBgNVBAMM
GnByb3RlY3RARERvUy1GaWx0ZXIuZG9tYWluMSkwJwYJKoZIhvcNAQkBFhpwcm90
ZWN0QEREb1MtRmlsdGVyLmRvbWFpbjAeFw0xODAxMDgxMDMyNDVaFw0yNzEwMDgx
MDMyNDVaMIGsMQswCQYDVQQGEwJBQTEUMBIGA1UECAwLRERvUy1GaWx0ZXIxFDAS
BgNVBAcMC0REb1MtRmlsdGVyMRQwEgYDVQQKDAtERG9TLUZpbHRlcjELMAkGA1UE
CwwCQ0ExIzAhBgNVBAMMGnByb3RlY3RARERvUy1GaWx0ZXIuZG9tYWluMSkwJwYJ
KoZIhvcNAQkBFhpwcm90ZWN0QEREb1MtRmlsdGVyLmRvbWFpbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBALu3IwZqfOZpY5T2ukFAjijxzQL2i9ioiOc7
3Ua4Sct9+MeiQO+ia2xsVMCzR0+cs/Vk4cmVeFJsXKEoNuqTeLpdVuAKpa/7WGFY
GsTN3PdnIYKEvfDDkxqd856s2gtB2WkxPVqHZRz/cy53JYCxrGfFG/4Vi5TG10Mi
JbMbepp/c8zyS3Boz5N9EneEgW1LgFOrKfuMuiao/I2Sd/ndf5990I2428F9da6n
rHuf4tN5ijtU3SYjh+XGtLSTCdIjWcd9xIH3WE6jFz9iTAhQIXs/OBILT/2AXMmQ
Vps3Jtb4KXcCPvvLfTFMc9gWol8cMJhM1DQQbH9Y0iTlhd14yusCAwEAAaNQME4w
HQYDVR0OBBYEFP0Bcoy51bDXe+ZfqG7Gn2mCyNe9MB8GA1UdIwQYMBaAFP0Bcoy5
1bDXe+ZfqG7Gn2mCyNe9MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
ADXfWa+Dkg3D65Ofmli1G13J+RR1HQbuHkhvGzvk1SWh5cek5FhDVeuhuXjxBCjN
el1GTB3keBvrdDNztSxsplx3z7vfkLtTNxQEq9Hx4GskrPpAHuvvkRiQyjMyCj1X
WQkj4M3leMO4zGq33XK77Uio1UX5HYUicJYiEx52/rGyrLcqLiyWEnVJ0OqHy35u
wCnDMT7e/q9jzAP+KgVLMBpMNtT7TPmBVQKpdh1ALjzXDH6C9BFkmHSsZaQGItzs
foEbzrsEWIhnsiBGXODkhN/2QzqDJ14ybzXrmPZXBw1iKyo2dtwbLr6NlEgU3xLg
sHmH1pxM87arGbkiLcdjU6c=
-----END CERTIFICATE-----

@pke - lets move that discussion to https://github.com/badges/shields/issues/5131 - its unrelated.
I'm also going to close this down now that the migration is done and we're happy with the new environment and processes. Further ops work is covered in separate issues: https://github.com/badges/shields/issues?q=is%3Aissue+is%3Aopen+label%3Aoperations


Extend Veraison ischeme interface to handle unprocessed evidence context

Currently Veraison ischeme only handles claim sets which are fully processed by a specific scheme.
This new enhancement, also handles the case to:
incorporate functionality to handle "Unprocessed Claim set" outside of plugin context.

Related to issue #105


On the path to better builds on windows

@kepkin one thing I did here was move gradle/ to deps/gradle/ since I'd like to isolate all third party code into that dir.  Wanted to get that OK from you in case you know of any reason not to.
I also removed the ref-qualified methods in mx3::sqlite::Value, so hopefully building is easier for you now.

Super. But if you wan't to remove Makefile and use gradle as root build it's better to leave gradlew and gradlew.bat in the root folder. I already build android fully with gradle, ios only left ;-)
BTW if it's possible to modify path to gradle wrapper we can do the same thing for example_android folder. Right now you will find another copy of gradle/wrapper there.

Ah, good point about using gradle as the root builder.  I still don't want people seeing the gradle/ subdirectory and wasting time trying to figure out what it is.  Perhaps we can move all the wrapper jars and properties to deps/gradle/ but leave gradlew in the root.  Either way, I'm going to merge this so you can continue to make progress.
Regarding android, I think we should leave gradle in there too.  That is probably how you'd structure it as an android developer (since gradle is the default build / dependency manager on Android Studio).  Being an example application, I'd like it to mirror reality as closely as possible.


Add auth tests for a databrickscfg file with an empty DEFAULT profile

Changes
Make sure an empty [DEFAULT] section yields the expected behavior.
Tests

[x] make test passing
[x] make fmt applied
[ ] relevant integration tests applied

Codecov Report
Patch coverage has no change and project coverage change: -0.22 :warning:

Comparison is base (5b14a09) 19.13% compared to head (e8f38fe) 18.92%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #496      +/-   ##
==========================================
- Coverage   19.13%   18.92%   -0.22%
==========================================
  Files          82       82
  Lines        8872     8988     +116
==========================================
+ Hits         1698     1701       +3
- Misses       7028     7139     +111
- Partials      146      148       +2

see 7 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


sap_hana_install: Support checksums for SAPCAR executable and SAR files (issue #44)

This commit adds support for verifying checksums of SAPCAR executable and SAR files. Automatic detection of SAPCAR executables and automatic extraction of SAR files remains in place.

We will choose a different approach for checksum checking, keeping the existing variable names.


Deploying php app with private composer dependencies

Hi,
I am deploying a PHP app that uses composer to install its dependencies. One of those dependencies refers to a private repository.
After dokku detects my app as a PHP app, it starts to install dependencies but fails when trying to install the private dependency.
remote: Cloning into '/tmp/tmp.i3HDOflujx'...
remote: done.
remote: HEAD is now at ae8cfd9... Added swagger specification
remote: -----> Building api-bdr using buildstep...
remote: -----> Installing ENV in build environment ...
remote: -----> PHP app detected
remote: -----> No runtime requirements in composer.json, defaulting to PHP 5.6.1.
remote: -----> Installing system packages...
remote:        - PHP 5.6.1
remote:        - Apache 2.4.10
remote:        - Nginx 1.6.0
remote: -----> Installing PHP extensions...
remote:        - zend-opcache (automatic; bundled, using 'ext-zend-opcache.ini')
remote: -----> Installing dependencies...
remote:        Composer version 1.0-dev (b23a3cd36870ff0eefc161a4638d9fcf49d998ba) 2014-11-21 17:59:11
remote:        Loading composer repositories with package information
remote:        Installing dependencies from lock file
remote:        - Installing symfony/finder (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/filesystem (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/console (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing nikic/php-parser (v0.9.5)
remote:        Loading from cache
remote:
remote:        - Installing classpreloader/classpreloader (1.0.2)
remote:        Loading from cache
remote:
remote:        - Installing d11wtq/boris (v1.0.8)
remote:        Loading from cache
remote:
remote:        - Installing doctrine/lexer (v1.0)
remote:        Loading from cache
remote:
remote:        - Installing filp/whoops (1.1.3)
remote:        Loading from cache
remote:
remote:        - Installing ircmaxell/password-compat (v1.0.4)
remote:        Loading from cache
remote:
remote:        - Installing jeremeamia/superclosure (1.0.1)
remote:        Loading from cache
remote:
remote:        - Installing psr/log (1.0.0)
remote:        Loading from cache
remote:
remote:        - Installing monolog/monolog (1.11.0)
remote:        Loading from cache
remote:
remote:        - Installing nesbot/carbon (1.13.0)
remote:        Loading from cache
remote:
remote:        - Installing patchwork/utf8 (v1.1.26)
remote:        Loading from cache
remote:
remote:        - Installing phpseclib/phpseclib (0.3.9)
remote:        Loading from cache
remote:
remote:        - Installing predis/predis (v0.8.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/http-foundation (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/event-dispatcher (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/debug (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/http-kernel (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing stack/builder (v1.0.3)
remote:        Loading from cache
remote:
remote:        - Installing swiftmailer/swiftmailer (v5.3.0)
remote:        Loading from cache
remote:
remote:        - Installing symfony/dom-crawler (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/browser-kit (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/css-selector (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/process (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/routing (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/security-core (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing symfony/translation (v2.5.7)
remote:        Loading from cache
remote:
remote:        - Installing laravel/framework (v4.2.11)
remote:        Loading from cache
remote:
remote:        - Installing usi/api-utils (dev-develop edc4a8d)
remote:        Cloning edc4a8d3e3ee2fd5e37161223a4ff5e2d6faafb0
remote:
remote:
remote:
remote:   [RuntimeException]
remote:   Failed to execute git clone --no-checkout<EMAIL_ADDRESS>'/tmp/build/vendor/usi/api-utils' && cd '/tmp/build/vendor/usi/api-utils' && git remote add composer<EMAIL_ADDRESS>&& git fetch composer
remote:
remote:   Cloning into '/tmp/build/vendor/usi/api-utils'...
remote:   Host key verification failed.
remote:   fatal: Could not read from remote repository.
remote:
remote:   Please make sure you have the correct access rights
remote:   and the repository exists.
remote:

Is there any way to configure the ssh key in order to dokku to have access to my private repository?
Best regards!

How is this resolved? None of the tickets actually provide a solution.

@sebastiaandegeus I'll push to beta injection of ssh key (either custom or automatically generated).

@sebastiaandegeus @mickael83 The latest dokku-alt-beta adds automatic deployment of ssh keys to buildstep-based apps. Please check dokku ssh:help. You can pipe your own private key or use automatically generated per-app key.

Any idea how to do this with a Dockerfile-based project? I've tried giving the Dokku user a deployment key in /home/dokku/.ssh/id_rsa, and I've tried adding the key to the container in the Dockerfile, but the private submodule I want to push up simply won't work...

Hi @ayufan , any idea when ssh:help will be in mainstream?


Fix ignored offset in rtc_mem access.

Fix sdk_system_rtc_mem_write and sdk_system_rtc_mem_read,
the functions did not use the user-provided offsets to rtc_mem.
Without using offset, rboot's rtcdata access, and its
temp_rom handling were broken.

Hi @otopetrik,
Thanks you very much!
Just checked the disassembly of the binary libraries. It was a mistake during reverse engineering. The original SDK uses the offset.


1.17 - Brigadier

Now that we have mappings on paper, we should move our commands to brigadier.

This is mostly complete, with the following issues:

I had to remove our custom flag argument, so we need another way to handle trailing flags in command arguments.
Our command is registered as /minecraft:otg.
/otg map biomes and /otg map terrain produce a black imagine in 0 seconds.


Remove custom context menu of youtube.

Is there a way to remove the custom context menu of youtube embed which appears on right click.

Yes, add this code
in JS this maybe not effect try the CSS solution
`const player = new Plyr('#player', { controls: true, disableContextMenu: true, muted: true });
`in CSS
 /* to disable right click on youtube video [disableContextMenu] */
  .plyr .plyr__video-embed iframe,
  .plyr__tooltip {
      pointer-events: none;
  }


draft: Introduce system theme detection for macOS

Based on https://github.com/bitcoin-core/gui-qml/pull/311, only last commit belongs to this PR
Introduces the basic wiring for detecting the system theme, and only does so for macOS here. Opening as draft for developer feedback on implementation of the idea of the theme manager.

We would then iteratively add this detection for Linux (where possible, looking at the dconf values for WM specific theme settings like gnome and kde), Windows (looking at the registry) and Android.

rebased over main


review the ras-stac hdf functions

Let's take a look at the ras-stac functions that are reading from hdf files and decide if we should be implementing them here instead of in the ras-stac repo.

@slawler, I took a look at the HDF functionality in ras-stac and I like the idea of migrating that over to this repo exclusively just to keep all HDF code in one place if that aligns with the overall vision y'all have in mind?

Sounds good, will do. Issue #17 added.


MB-14476 move history fetcher tests

Jira ticket for this change
Summary
To finish closing out History and Audit Logging, add and update Go tests for move_history_fetcher.go

Rearranged move_history_fetcher_test.go for context grouping
Renamed two of the test suites and re-grouped tests based on what they accomplish
Grouped private functions together
Utilized region commenting to help make this giant file more readable for future updates.
Improved how shipment context is tested throughout

Setup to Run Your Code

💻 You will need to use one terminal to test this locally.
Terminal 1
Run all server tests
make server_test

Additional steps

Verify that no server tests fail

Verification Steps for Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.

Messages

:book:
:link: MB-14476

  Generated by :no_entry_sign: dangerJS against c7e3c10af6ad8233734f50531592d661628498bc


Don't create a window.Hammer global when in CommonJS

In hammer.js:
// this prevents errors when Hammer is loaded in the presence of an AMD
//  style loader but by script tag, not by the loader.
var freeGlobal = (typeof window !== 'undefined' ? window : (typeof self !== 'undefined' ? self : {})); // jshint ignore:line
freeGlobal.Hammer = Hammer;

Not sure what such a code wants to prevent, but the fact is that it's polluting the global namespace (window) even when CommonJS or AMD is being used.
It shouldn't.

@ibc it should, for the reasons stated there.

According to such a rationale, every CommonJS/AMD capable library should also force a global. Is that what you mean?

To be perfectly clear: Your rationale is wrong. Otherwise, let's tell Reactjs, jquery and over 2000 NPM libraries that they should expose a window.Xxxxx global. So please, don't say that "it should" because that's not true. The author of a web application choose whether uses CommonJS/AMD loaders or legacy <script> tags.

@ibc No, this is a factor of usage. jQuery uses this same pattern, for example.  Hammer would often fail in a Cordova, Electron or NWJS package were we to not use this pattern.

As Cordova user I've never found such a problem. The point (or one of the points) of CommonJS/AMD libraries is to not pollute the window namespace.
Anyhow I may understand your concerns. However, a better solution could be to provide a bundled file (generated with browserify) for those loading your lib via a <script> tag, and leave all the others to load it as a NPM library, by removing all the "loader detector" from the main source code.
To be clear: when I use browserify I don't need that a lib (such as hammerjs) comes within a single JS file, nor I need that the lib checks whether it's running in a CommonJS/AMD environment.

Also, jQuery does not follow such a pattern:
$ npm install jquery
$ node

> require('jquery');

> global.jQuery
undefined
> global.jquery
undefined
> global.$
undefined

No globals.

It does though :P https://github.com/jquery/jquery/blob/master/src/exports/global.js

Well, just reproduce my code above. There are no globals after loading require('jquery'). I think that the "no conflict" stuff of jQuery is not present in the NPM version of the library.

@ibc I also work on the jQuery team and the npm version is not any different and it does expose a global still see here in the distributable https://github.com/jquery/jquery/blob/3.1.1/dist/jquery.js#L10166
This is in fact necessary because there are others that have written plugins for hammer that depend on it being available in the global context this is the same situation for jQuery. If we did not expose the global on window most jQuery plugins would break. The reason your code above does not work is because your checking global.* not window.*

Well, I've just added jquery NPM version into a browserify based app, and loaded it as usual in may app main JS file (the entry point of the bundled file):
var foo = require('jquery');

There is not window.jquery nor window.jQuery at all.

@ibc well i dont know whats going on in your app or your browserify build process but you can see it clearly on this page http://view.jqueryui.com/master/demos/button/default.html that loads jQuery via amd if you go into the console you can clearly see the global exists.
Again there is no "npm version" of jQuery the file i linked IS The latest version on npm

It just happens (checked right now) that this line is called with noGlobal === true so the global is not created.
That is because when browserify runs, there is no global.document so this code does not call the factory with true as second parameter.
I don't know if that is the desired behavior or not. Anyhow, I may understand that jQuery does a hack due the amount of 3rd party libraries relying on window.jQuery, but that does not mean that a new and modern library such as hammerjs should follow the same legacy pattern.

@ibc the fact is we face the same problem we have 3rd party plugins the depend on there being a global we would break 3rd party plugins if we change this so we won't be changing it like @runspired said

There needs to be a version that does not create a global. Even if I do not use any plugins, hammerjs still pollutes my namespace. Additionally more and more people continue to depend on the global because you continue to provide it.
It obviously is a chicken and egg problem but that is not a good reason to encourage the entire ecosystem being held back.
moment did the right thing.
moment deprecated their global.
moment removed their global.
moment broke many people's apps.
moment broke apps I was responsible for maintaining (forgot to import and paid the price).
They did the right thing.
Please consider deprecating your global, giving plugin authors time to update and users time to decide, and then remove it completely.

we have 3rd party plugins the depend on there being a global

A bad practice should not be kept forever.


I want to add auto-imports.d.ts to gitignore, but the production environment will report an error

Clear and concise description of the problem
Hmm,
If you don't add auto-imports.d.ts to gitignore, it will change frequently and cause conflicts, so I want to add gitignore, but this will cause another problem. The production environment does not have this d.ts file, and execute vue-tsc When an error occurs, how should I configure it?

Suggested solution
i don't know
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

any news regarding this? I'm experiencing the same problem. I've added the auto-imports.d.ts  to gitignore, but know the build doesn't work if i don't run vite --host --port 5050

I don't know if you have already tried to do this. But i inverted the order of my script
** before **
"vue-tsc --noEmit && vite build"
** after**
"vite build && vue-tsc --noEmit"
Now it's generating the auto-imports.d.ts and the errors disapear

i think if you do vite build first , vue-tsc --noEmit doesn't make sense anymore

At least it will capture some typescript problems, that are not related to the auto imports. I don't think this is the rigth way to do it, but it's a work around till some  answers...

It's recommended to commit the file. Otherwise, you should run the build before typechecking.

我也碰到这个问题

@JJiangZhe
1  你先在运行时跑通  确保 json  和  x.d.ts  你需要的都写入
2   关闭 dts  和  eslintrc 配置
3   重新build 你的项目就OK
 // Filepath to generate corresponding .d.ts file.
  // Defaults to './auto-imports.d.ts' when `typescript` is installed locally.
  // Set `false` to disable.
  dts: false,

  // Generate corresponding .eslintrc-auto-import.json file.
  // eslint globals Docs - https://eslint.org/docs/user-guide/configuring/language-options#specifying-globals
  eslintrc: {
    enabled: false,
    filepath: './.eslintrc-auto-import.json', // Default `./.eslintrc-auto-import.json`
    globalsPropValue: true, // Default `true`, (true | false | 'readonly' | 'readable' | 'writable' | 'writeable')
  },

原因分析(未读源码) :   全量覆盖 没有做到智能覆盖,存在的就不覆盖

@fukai007 as I said before, I think the best way to handle it, since the way the plugin works, is to run build before checking tsc.

I'm experiencing the same problem.

@srchafreenn Just commit the file. If you don't do so, once new developers clone your repository they should run the build step first to avoid type errors.

It's recommended to commit the file. Otherwise, you should run the build before typechecking.

Sounds weird to commit a auto-generated file to version control.


Browser extension?

It would be amazing if this was a browser extension!
I currently use this JSON viewer extension in Brave browser, but I believe Fractured JSON would be better: https://chrome.google.com/webstore/detail/json-viewer/gbmdgpbipfallnflgajpaliibnhdgobh?hl=en
Thanks!

I can see the value in a browser extension, but it's not something that I could do well.  I almost never do front-end web work, so I don't have a good sense for what sort of functionality people would expect.
If someone else out there wants to contribute their time and skill to create one, I would certainly welcome it into the FractureJson family.  Or perhaps there are existing extensions that could integrate its functionality.


crictl can't start an exited container

Description
crictl  ps
CONTAINER           IMAGE                          CREATED             STATE               NAME                ATTEMPT             POD ID
00740ba6a36b7       <IP_ADDRESS>:5000/alpine:latest   2 minutes ago       Running             stress5             0                   395a8bd7b6978

crictl  stop 007
007
crictl  ps -a
CONTAINER           IMAGE                          CREATED             STATE               NAME                ATTEMPT             POD ID
00740ba6a36b7       <IP_ADDRESS>:5000/alpine:latest   9 minutes ago       Exited              stress5             0                   395a8bd7b6978
crictl  start  007
FATA[0000] starting the container "007": rpc error: code = Unknown desc = failed to set starting state for container "00740ba6a36b78159736be4ecc9b3ad3e7ffc72126dc2113910676aa3f1729c0":
container is inCONTAINER_EXITED state

code is here
func setContainerStarting(container containerstore.Container) error {
	return container.Status.Update(func(status containerstore.Status) (containerstore.Status, error) {
		// Return error if container is not in created state.
		if status.State() != runtime.ContainerState_CONTAINER_CREATED {
			return status, errors.Errorf("container is in %s state", criContainerStateToString(status.State()))
		}

why can't start an exited container
Steps to reproduce the issue
crictl  ps
CONTAINER           IMAGE                          CREATED             STATE               NAME                ATTEMPT             POD ID
00740ba6a36b7       <IP_ADDRESS>:5000/alpine:latest   2 minutes ago       Running             stress5             0                   395a8bd7b6978

crictl  stop 007
007
crictl  ps -a
CONTAINER           IMAGE                          CREATED             STATE               NAME                ATTEMPT             POD ID
00740ba6a36b7       <IP_ADDRESS>:5000/alpine:latest   9 minutes ago       Exited              stress5             0                   395a8bd7b6978
crictl  start  007
FATA[0000] starting the container "007": rpc error: code = Unknown desc = failed to set starting state for container "00740ba6a36b78159736be4ecc9b3ad3e7ffc72126dc2113910676aa3f1729c0":
container is inCONTAINER_EXITED state

Describe the results you received and expected
crictl can start exited container
What version of containerd are you using?
1.4.11
Any other relevant information
No response
Show configuration if it is related to CRI plugin.
No response

Test locally with nerdctl with containerd and it works well, this maybe a bug of crictl.

it is by design. But cri-api doesn't have comment or doc on StartContainer. In kubernetes scope, if the container exits, kubelet will recreate new one and delete the stopped one. Based on this, the CRI-plugin in containerd doesn't allow Restart😅 which aligned with kubelet. Non-kubernetes scopes allow restart.

Since it is not bug here, I am going to close it.

but if somebody want to use cri-api but not use k8s,we want to restart(stop +start) it


Should @testsnippet be reexported by this package?

When we add using TestItemRunner in the beginning of runtests.jl it exports all macros, except @testsnippet. We needed to also import TestItems to get things working.

The idea really is that there are no test items (nor includes) in runtests.jl, just the macro call to run the tests, so that one doesn't need to load TestItems.jl. That should then work, right?

Exactly. As a first time user I thought that TestItemRunner.jl was the only
package needed to write the test suite.
Em sáb., 24 de ago. de 2024, 23:32, David Anthoff @.***>
escreveu:

The idea really is that there are no test items (nor includes) in
runtests.jl, just the macro call to run the tests, so that one doesn't
need to load TestItems.jl. That should then work, right?
—
Reply to this email directly, view it on GitHub
https://github.com/julia-vscode/TestItemRunner.jl/issues/91#issuecomment-2308627830,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZQW3MFVFE2HHGZ5MS3QHTZTE63DAVCNFSM6AAAAABNBS32UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGYZDOOBTGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

I can confirm that it works as-is if you move your @testsnippet to a separate file from the runtests.jl file.

So moving the snippet to any other file like test/snippets.jl removes the need of the dependency on TestItems.jl?


Release 1 1 2

Fuctionality

Deprecated Big Falcon Rocket (#106)
Added new info.clients() and info.apps() functions (#107)

Documentation

Completed Documentation for wrapper

Infrastructure/Code

Update tinydb from 3.14.1 to 3.15.0 (#89)
Syntax error in install_requires (#88) (@mhaddy)
Made Python code PEP-8 compliant + fixed 1 security issue (#105)

Hello @alshapton! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file setup.py:

Line 41:17: E126 continuation line over-indented for hanging indent


Added fixes to problems that occur on python3

The following errors happened when initially running tensorboard in python3:

The StringIO was giving the following error:

TypeError: string argument expected, got 'bytes'
Applied the fix from here: https://stackoverflow.com/questions/6479100/python-stringio-replacement-that-works-with-bytes-instead-of-strings , which suggests that BytesIO will work on both python2 and python3.

When trying to pass a gray-scale image (e.g. 2D array) when passing it to PIL I got:

https://stackoverflow.com/questions/16720682/pil-cannot-write-mode-f-to-jpeg
Thus I added a line to convert it to RGB.
This made the colorspace redundant as it already converts it to 3 channel even in the case of 2 channels.

Finally when saving images with float32 type between 0 and 1 tensorboard was displaying them as all black. For this I added a direct conversion to uint8 between 0 and 255.

I just ran into this issue as well. It'd be great to have it merged.

@keunhong Could you help verify this?
I'm going to change the backend to tensorflow/tensorboard these days first, and change the project name to tensorboard-lite, as the TensorBoard dev team has released their version but still rely on TF. The interface of our project won't change.


fix(v2): remove extra top margin of tab item

Motivation
Resolve #2738.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan

Before
After

Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)

Maybe it will but I am not sure about that.

A CSS reset won't help here because .markdown li+li is the class responsible for that margin. Maybe we should just use divs instead of ul/li and add aria roles to preserve the semantic-ness.

@yangshun will you add reset styles to Infima today?

Nope, not today

But what about the new Docusaurus release tomorrow? I mean, should we release a new version of Infima now in order to apply the new changes in the upcoming version of Docusaurus?

Yes I wanna fix some issue first - docs h2 size same as docs title on mobile

Alright, I hope you fix it asap.


Handle tap event of avatar UIImageView.

Hi,
is there an easy way to handle tap/touch events on the avatar image? I want to display a user profile of a message's author when the avatar image is being touched.

hI
i need to add avatar ,and Dont know how to do it

best solution


Navigation broken in Firefox

When using Firefox, navigation on component-party is broken. Clicking one of the buttons in the sidebar seems to work occasionally, but usually brings me to the top of page.
Tested on Firefox 123.0.1 and Firefox Nightly 125.0.a1. Seems to work fine in Chromium.

It seems that setting a breakpoint on [navigate function] (https://github.com/matschik/component-party.dev/blob/ec412ed093eec8eb57684b4590a78e645bc559c8/src/Router.svelte#L19) in Router.svelte gurantees breaks the navigation when clicking the first time. If you click again navigate is not triggered for some reason and works. On chrome naviagte is always called by onpopstate when clicking. Also, when I commented out window.onpopstate, navigation on Firefox also works as intended.