Dependabot auto merge not working

For my private repository it's not possible to add the auto merge feature. I added dependabot via the web interface and I receive PRs but the PRs are not merged automatically.
After this did not work I also tried via the dependabot config. The behaviour is the same. The check runs daily and creates PRs but does not merge them.
version: 1
update_configs:
  - package_manager: "javascript"
    directory: "/"
    update_schedule: "daily"
    automerged_updates:
      - match:
          dependency_type: "development"
          # Supported dependency types:
          # - "development"
          # - "production"
          # - "all"
          update_type: "all"
          # Supported updates to automerge:
          # - "security:patch"
          #   SemVer patch update that fixes a known security vulnerability
          # - "semver:patch"
          #   SemVer patch update, e.g. > 1.x && 1.0.1 to 1.0.3
          # - "semver:minor"
          #   SemVer minor update, e.g. > 1.x && 2.1.4 to 2.3.1
          # - "in_range"
          #   matching the version requirement in your package manifest
          # - "all"
      - match:
          dependency_type: "production"
          update_type: "all"

@infin8x I understand the security concern but we were hoping to set our target_branch to something that is not our default branch and then auto-merge into that branhc to limit the number of PRs that get opened per project. Many integration services like Chromatic, Heroku, etc. have costs associated with each PR that gets created in a repo so this is an important capability for us. I think you need to reconsider this policy to at least allow auto-merge on non-default branches.

@chdsbd Can Kodiak distinguish between patch, minor, and major versions?

@danielbachhuber Sadly not.
There was a discussion about adding that kind of metadata in a structured form via probot metadata, but I don't think that's gone anywhere yet.
#2294 would also make automatic updates based on type easy.
A potentially less robust solution would be to parse the update type from the PR description.
Assuming the following example is consistent I think a github action could label the PR based on the PR description.
Bumps eslint from 7.6.0 to 7.7.0.

...more content...

Here's a example script that could probably be integrated into some GitHub Action or bot:
https://runkit.com/chdsbd/5f3c822e5eda78001ac183df
const semver = require('semver')

const PR_DESCRIPTION = `\
Bumps eslint from 7.6.0 to 7.7.0.
Release notes
Sourced from ...`

const regex = /^Bumps\s.*\sfrom\s(.*)\sto\s(.*)\./;

/* determine the update type (major, premajor, minor, preminor, patch, prepatch, or prerelease) from a dependabot PR */
function parseUpdateType(x) {
  const match = x.match(regex)
  const prevVersion = match[1]
  const newVersion = match[2]
  return semver.diff(prevVersion, newVersion)
}

parseUpdateType(PR_DESCRIPTION)
/* equals "minor" */

In our org we have automerge setup for when branch conditions are met.
And we always require review, we like just being able to approve a PR and then it automatically merges.
It saves a few clicks in the UI and also means that if CI is retriggered it will merge after CI is green.
Saves have to type @dependabot merge which isn't too bad but would be nice to get automerge back

In our org we have automerge setup for when branch conditions are met.
And we always require review, we like just being able to approve a PR and then it automatically merges.
It saves a few clicks in the UI and also means that if CI is retriggered it will merge after CI is green.
Saves have to type @dependabot merge which isn't too bad but would be nice to get automerge back

That makes me wonder if you could setup a GHA to auto comment @dependabot merge when a PR is approved in review. Doesn't solve people wanting unattended auto-merge, but might solve your use case.

I can do that but just means adding another github action all over the place, previously we were able to control this in org settings in dependabot which was nice.

There is no automerging support in GitHub-native Dependabot [...] Several 3rd-party GitHub Actions and bots can replicate the automerge feature.

I must say this is the least helpfull feature migration help I have ever encountered. What about putting a link to somewhere where you can read about what to do?
Preferably a one-click-to deply action that just works.

For anyone looking for auto-merge, I believe there is a marketplace GitHub action that can do it for you, but I've also created a GitHub action file here: https://github.com/pydanny/cookiecutter-django/pull/2868 but credit goes to the Medium blog post that I took the code from. I can't seem to find the blog post anymore, but I hope that file helps anyone who want further configuration!
Quickly, here're the file contents:
name: "Dependabot Automerge - Action"

on:
  pull_request:

jobs:
  worker:
    runs-on: ubuntu-latest

    if: github.actor == 'dependabot[bot]'
    steps:
      - name: automerge
        uses<EMAIL_ADDRESS>        with:
          script: |
            github.pullRequests.createReview({
              owner: context.payload.repository.owner.login,
              repo: context.payload.repository.name,
              pull_number: context.payload.pull_request.number,
              event: 'APPROVE'
            })
            github.pullRequests.merge({
              owner: context.payload.repository.owner.login,
              repo: context.payload.repository.name,
              pull_number: context.payload.pull_request.number
            })
          github-token: ${{github.token}}

Does anyone know if this will auto-merge whatever PR from a user who changed their username to dependabot[bot]?

While I understand the refusal to implement this feature in Dependabot due to the security hole it opens up, the functionality provided by Dependabot's automerged_updates feature is very hard to replicate with the tools currently available.
The most important black hole in the current infrastructure is the lack of metadata (the version numbers being the most essential bits of information) in the pull requests submitted by Dependabot, or by any other bot, for that matter. While Probot could work – it is, as it even describes itself: A hack.
To enable the community to build alternatives, GitHub needs to provide us with a non-hacky implementation of pull request metadata that can be used in GitHub actions so at least the version numbers are available for comparison. The more metadata available, the better, of course.

I completely understand the security concerns, but I believe there's a gray area here between auto-merging unknown PR's and not having this feature at all.
Maybe we can have a treat approval as request to merge, or auto-merge for specific semver like minor, or maybe have auto-merging to a non-default branch that will be fully reviewed ie. auto-merge in develop that will be reviewed before merge to master.

FWIW, I tried the github action approach @Andrew-Chen-Wang mentioned above but it only works if there are no other pending github status checks. If you have another required status check that takes a while to finish (i.e. Travis CI), the action doesn't wait for it and fails with the following error:
Error: Required status check "Travis CI - Pull Request" is queued.

The action didn't wait for Travis CI - Pull Request status check to finish

@mkay581 I've redeveloped it in SimpleJWT's repositories to use two actions: wait for status check and automerge and delete branch. https://github.com/SimpleJWT/drf-SimpleJWT-React/blob/7fe37747f9b4385faeaf5ec57b650ff21d82c1ae/.github/workflows/automerge.yml#L1

We got the alternative here: https://twitter.com/github/status/1336360682221133827?s=20

Check out auto-merge! Now, when your branch protection rules are met, your changes approved, and your checks are green, GitHub can automatically merge your pull request for you.

@peaceiris It seems like someone still has to hit the button each time?

I do not know the details. I hope we can set the auto-merge for a whole repository/account.

It seems like this (auto-merge) is applied individually to each pull request. The scenario is you are waiting for checks to pass or approvals to be applied via review, but you want the PR to merge once those conditions are met.
It does not seem you can globally apply this to an entire repository (and arguably probably don't want to).
It does not seem you can globally apply this to pull requests from repo admins, code owners, or specific users or groups that have been given permissions to a repository (this might be more reasonable than globally applying to an entire repository). I would imagine this option (if it were made available) would allow us to globally grant dependabot permissions to auto-merge within a repo, but not anything else (ex: admins, code owners, or other users/groups with permissions might not need/want auto-merge globally and would prefer it on an individual PR basis, which is how it currently seems to work).

If you have checks that need to pass before you want to merge the dependabot update PRs, you can use a combination of the "automerge" and "wait for status" actions.
https://github.com/JabRef/JabRef-Browser-Extension/blob/56666f241f3767af28fe2afb49b36afbf30bfb14/.github/workflows/automerge.yml#L22-L41

What would it take for this decision to be reconsidered?
The way I see, the security protection here is: updates will roll out slowly, so if it's malicious, it won't affect too many projects. Looks like this is only really slowing the whole process. I understand that as a temporary solution, but I'd expect something else to happen in the short term future.
I also don't expect a manual review to catch a security issue, unless it is a very known issue and you're specifically looking for it. I can't keep them all in my head and I don't want to go over every dependency update. We get hundreds of those per day. I expect that people will configure auto merge anyway (with fewer features, because now we can't enable it only for minor versions), or simply do them manually, but blindly.

What would it take for this decision to be reconsidered?
The way I see, the security protection here is: updates will roll out slowly, so if it's malicious, it won't affect too many projects. Looks like this is only really slowing the whole process. I understand that as a temporary solution, but I'd expect something else to happen in the short term future.
I also don't expect a manual review to catch a security issue, unless it is a very known issue and you're specifically looking for it. I can't keep them all in my head and I don't want to go over every dependency update. We get hundreds of those per day. I expect that people will configure auto merge anyway (with fewer features, because now we can't enable it only for minor versions), or simply do them manually, but blindly.

It would be interesting if it could auto merge if all github workflow checks pass, and there were a specific workflow available to check if any packages have known vulnerabilities and prevent merging if true. With that, auto merge could work for those who's packages are up to date with no known vulnerabilities, and if any vulnerability is present (even if it's not in the package being updated) all merges would have to be manual until the vulnerability is resolved.
I know that's not perfect, but it might be reasonable enough.

It would be interesting if it could auto merge if all github workflow checks pass, and there were a specific workflow available to check if any packages have known vulnerabilities and prevent merging if true. With that, auto merge could work for those who's packages are up to date with no known vulnerabilities, and if any vulnerability is present (even if it's not in the package being updated) all merges would have to be manual until the vulnerability is resolved.
I know that's not perfect, but it might be reasonable enough.

I made this article to help explain how to auto merge
https://jayisscott.medium.com/dependabot-auto-merging-prs-7b20459ed8e9

cc @asciimike would love to get your thoughts on this. It's clearly something that a lot of people really valued from the old dependabot, and not all projects/workflows are affected by the risk equally (not everyone autodeploys the main branch and may do a dependency check before manually kicking off a release, libraries still require a manual release etc), but at the same time the potential risk for massively rolling out a malicious update are scary.

I've been testing @Mergifyio for a few weeks and just wanted to mention that they provide a great alternative to Dependabot's auto-merge functionality. Works for protected branches, required code reviews, required checks, CODEOWNERS and restricted push. This configuration handles it all:
pull_request_rules:
  - name: Automatic approve on dependabot PR
    conditions:
      - author~=^dependabot(|-preview)\[bot\]$
    actions:
      review:
        type: APPROVE

  - name: Automatic merge on approval
    conditions:
      - author~=^dependabot(|-preview)\[bot\]$
    actions:
      merge:
        method: merge
        strict: smart

If you don't mind using another GitHub App for helping with auto merge, I made an open source GitHub App, Kodiak, that supports auto merging Dependabot PRs based on upgrade type (major, minor, patch).
It has a pretty simple config.
#.kodiak.toml
version = 1

# auto merge minor and patch updates made by Dependabot
[merge.automerge_dependencies]
versions = ["minor", "patch"]
usernames = ["dependabot"]

# let Dependabot update its own PRs
[update]
ignored_usernames = ["dependabot"]

Re: @sehenst

Would it be possible to add support for auto-merge if the dependency is an internal organization package?

This is one of the few situations that we think it's less-insecure to use auto-merge. I do think it's a little tough to know what "internal" packages are (e.g. is any private registry/repo considered internal? What if it's just mirroring a public registry?), so I doubt that we'll build it directly in, but instead recommend folks use an Action or a standalone app configured according to their security/risk profile. I'm working on some docs to help folks with this.
Side note, _infin8x is no longer working on Dependabot, so he's probably not going to be responding.

I think one completely overlooked use case is that dependabot can keep dependencies of hobby and community projects updated. While serious projects, where the security impact is large, have the manpower and dedication to approve and review the updates, these small projects, where the security impact is none or low, do not. Also, many of my projects are static websites, where security issues in dev tools required to build the site have zero actual impact (like various DDoS security vulnerabilities, etc.). Today, I woke up to this:

Except one, I'm not paid to maintain any of the projects. I want to keep them safe and updated, and I occasionally find some free time to make them better, or once, twice a year, we have a community sprint where we work on them. I can't imagine thoroughly reviewing the dependencies, it's just impossible. Even if the bot sends the PRs my way without automerging, it won't make me to review them. I'll just mindlessly click the PR to upgrade. It'll only add drag to maintaining them and drain my time and resources. The issues any vulnerability could cause on these projects are so small it just isn't worth the hassle of preventing them to happen, this is a hotfix scenario in case something happens (happened only once for the past 10 years). Letting the dependencies rot and upgrading them all once a year would be much worse.
We're advised to use bots and GitHub Actions, but for hobby and community projects, that's added complexity, which only requires installing on each repo, configuring on each repo, maintaining, explaining, documenting - so again, that's draining volunteering time and resources. Not mentioning not all the projects use GitHub Actions, so I'd have to find workarounds e.g. for CircleCI.
Unlike others in this discussion, I do not entirely understand the security reasons for not implementing the feature. I think that requiring people to go to the PR and manually approve the upgrades won't add security, it'll only add annoyance. People won't be reviewing, they'll see green checks and will just merge the PR and see if something broke 🤷 I think this might cause the opposite, in fact. I think this can cause many volunteer maintainers to feel like there is an endlessly growing stack of dependency upgrade PRs to go through, which will drain their energy and time, which will make them feel like maintaining the project is not a joy, but a job. So they'll either let the PRs rot, or they'll disable dependabot, or they'll never turn it on in the first place. Which will cause the projects' dependenices to rot, and outdated dependencies are exactly where vulnerabilities thrive.

Workaround... 😄
Please note that we only use this for internal dependencies (i.e., our own private packages).
name: Java CI with Gradle

on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - uses: actions/checkout@v2

      - uses: actions/setup-java@v2
        with:
          distribution: 'adopt'
          java-version: '11'

      - name: Build with Gradle
        run: ./gradlew build
        env:
          GRADLE_BUILD_USERNAME: ${{ secrets.**********************}}
          GRADLE_BUILD_TOKEN: ${{ secrets.********************** }}

      - name: "Auto-merge ********************** dependency updates"
        if: ${{ success() }} && github.actor == 'dependabot[bot]' && startsWith(github.event.pull_request.title, 'Bump ********************** from')
        uses: actions/github-script@v3
        with:
          github-token: ${{secrets.********************** }}
          script: |
            github.issues.createComment({
              owner: context.payload.repository.owner.login,
              repo: context.payload.repository.name,
              issue_number: context.payload.pull_request.number,
              body: '@dependabot squash and merge'
            })

      - name: Add reviewers on failed ********************** bumps
        if: ${{ failure() }} && github.actor == 'dependabot[bot]' && startsWith(github.event.pull_request.title, 'Bump ********************** from')
        uses: actions/github-script@v3
        with:
          github-token: ${{secrets.**********************}}
          script: |
            github.pulls.requestReviewers({
              owner: context.payload.repository.owner.login,
              repo: context.payload.repository.name,
              pull_number: context.payload.pull_request.number,
              team_reviewers: [ '@**********************' ]
            })

I've helped maintain a number of both popular and not-so-popular OSS projects, and while I understand the convenience, I also think Github is making a wise choice here.
Supply chain attacks are already happening and they are only going to increase in the future.
If you really want auto-merge, either setup a GitHub action, or spin up your own copy of dependabot, or switch to renovate, or simply lower the frequency so that you can handle updates as a weekly task.
IMO handling updates with a few manual clicks on PR's is trivial and takes less than 30 seconds for me most of the time.

This change actually makes my application less secure. In the past we could rely on detection of new maintainers from dependabot to prevent auto-merging suspicious packages. That is the only supply chain attack that manual review prevents and it is easy to automate and hard for humans to do.
It isn't possible to audit every commit in every package we depend on, we rely on those package maintainers to do that work. The supply chain threat that seems to be the focus of this change is that an unknown malicious actor could push a new version of a package and have it propagate to everyone. Forcing us to rely on a third party action to auto merge removes this protection and adds significantly more work to the process of staying up to date.
What is more likely to happen after this change is that deeply nested OSS packages who are now forced to manually merge updates will simply ignore those updates or be overwhelmed by the flood or work and abandon their packages. That is an actual critical threat to our supply chain. As transitive dependencies fall further behind and fail to patch known vulnerabilities those vulnerabilities will be easy to exploit with automated tools and detection. The theoretical risk of a malicious packages propagating to the ecosystem that is somehow prevented by application owners clicking a green button is nowhere near as important or as critical as using these components with known vulnerabilities will be.
It's too bad because dependabot was a fantastic service that did everything we needed. Sad to see this product damaged by a miss understanding of the threats that face application owners and our users.

How does 30s long manual merging of the PRs, which doesn't include any deeper consideration or investigation of the updates, prevent supply chain attacks? The only real difference is that it's me spending time on enabling them instead of a bot doing it for me.
Also, I wouldn't advocate for auto merging being anything near to default behavior, it should be opt-in with warnings and "I know what I'm doing" checks.

@honzajavorek
I had the same problem as you had.
I just drop dependabot and started use renovatebot.
just install this: https://github.com/marketplace/renovate
and drop a file similar to this one:
renovate.json
{
  "extends": [
    "config:base"
  ],
  "schedule": ["after 7pm and before 7am"],
  "prConcurrentLimit": 2,
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch", "pin", "digest"],
      "automerge": true
    },
    {
      "matchDepTypes": ["devDependencies"],
      "automerge": true
    }
  ]
}

I hope you can evaluate if that tool is better for your use case.

Dependabot's goal is to keep apps secure by keeping their dependencies up to date, not to simply keep dependencies always updated. We've found a correlation between up-to-date dependencies and more secure apps, but it's important to remember that correlation isn't causation! Keeping dependencies up to date is more likely to result in fixing latent bugs that might otherwise turn into vulnerabilities; however, it comes with an increased risk that a new release contains or enables malicious behavior. Security updates, while likely more safe, are still potentially vulnerable to this (imagine an attacker purposefully introducing a benign security vulnerability that's designed to get caught, followed by a patch which contains an actual vulnerability). Is automerge a real risk in these cases? Recent history suggests it is.
When I worked at Google, we used to joke that "one in a million chances occur dozens of times every second" (true story), and with the scale we're operating at (Dependabot is the single largest creator of PRs at GitHub), it's possible that even small vulnerabilities will affect a lot of users and cause a lot of harm. The difference here is not a "misunderstanding of threats faced" it's that we're considering risks differently.
It should not be surprising that individuals working on projects they know well have a higher appetite for risk than a product with millions of users ranging from students working on homework projects to organizations larger than GitHub. We have to build a product that keeps everyone secure, and sometimes that means making choices that aren't locally optimal for one set of customers, but are globally optimal across the customer base.
The team and I recognize that it is effort to keep dependencies up to date, especially for OSS maintainers (we built Dependabot, after all). For those of you who have vetted your supply chain or are willing to accept the risks, the "opt-in" solutions exist. There are a plethora of apps (e.g. kodiak), Actions (e.g. merge-me), other products (e.g. renovate), a cron job that just runs npm update every day, etc. that can be used instead if automerge is the number one feature. We think that a user's decision to use a tool like this is a stronger signal of their willingness to accept risk than automerge: true.
I recognize that for some of you, nothing short of automerge: true will make you happy. As of right now, we can't offer that, and if that means you cease to use Dependabot, I'm sorry. Hopefully future changes to reduce noise, more precisely target vulnerable dependencies, or validate the integrity of packages will change the balance of power in supply chain attacks, and we can get to the point where folks can keep the right dependencies up to date with minimal burden. Until then, we'll do the best we can to work towards that goal, and welcome your feedback on how we can collectively make software more secure along the way.

@asciimike you're relying on a catch phrase "correlation isn't causation" to shrug off the very real fact that updated dependencies are a significant indicator of project quality and security.  Your specified threat of novel supply chain attacks, while interesting to dream about, are less of a risk for the majority of Github projects than the well researched OWASP Using Components with Known Vulnerabilities where the most applications are actually vulnerable. There are millions of examples of out of date dependencies causing real world breach for every one of your example targeted attacks. The real world isn't what you imagine it to be and our applications are substantially more likely to be compromised by an out of date dependency than a malicious commit and even if that were not the case clicking a green button when tests pass doesn't do anything to prevent the later.
You're also mixing up the automated security bump GitHub system built on dependabot with the opt in configuration driven tool that dependabot was built as. Projects which include a dependabot configuration file have to be close to 0% of the total projects on Github. Treating them as vulnerable to the same threats as a hobby project doesn't make any sense. Enabling dependabot and writing tests to ensure that only quality updates are merged is a hallmark of professionalism, please don't take away tools that help us to do our job well.
Lastly while blanket automerging may represent an issue the original dependabot allowed for significant narrowing of the scope for each PR which allows automerging to work securely. Security conscious maintainers of applications could restrict auto merging to specific packages with more trusted security practices and the auto merge automatically stopped when a new maintainer was detected. The solutions bandied about here and in other issues do not have access to the same depth of metadata on each update that dependabot does and so cannot be made as secure as the original feature.
I know you're seeing these complaints as coming from maintainers with no clue and don't know what we're talking about. I don't know if you meant the google remark to be condescending or it just came off that way to me. Please understand that this (and many other threads on this subject) are full of professional developers who are disagreeing with you for very good reasons and have been doing so for months. This change will make our applications less secure and distract from the work of building great things in order to take a few moments every morning to blindly click a green button instead of allowing well informed automation to do it for us. That's not a good tradeoff.

My comments are never intended as condescending, and I apologize if they came off as so. It was intended to just be a statement of us having different lenses through which we view the problem, as that's the heart of the disagreement. I respect everything folks have to say, and the arguments for why this feature makes sense in your use cases make sense. My concern isn't how folks on this thread use automerge, it's how everyone who isn't participating in this thread would use it.
Existing solutions aren't perfect, e.g. Kodiak can do semver based merges, but not dependency_type, and I'm happy to see if we can add that info (likely as labels or a metadata comment on the PR) for folks to act on if that would help. For folks with good enough test coverage and CI, merging based off this info should be easy enough (e.g. https://github.com/pascalgn/automerge-action 's MERGE_LABELS) that it's a reasonable "opt-in" to prevent folks who don't from YOLO merging everything.

I'm probably one of these potential users that "would use automerge but are not participating in this thread". I don't have any background in IT, and only maintaining a few smaller projects in my freetime. If I get a dependabot PR and the checks are green, I often just click merge without even looking at the changed files. Sometimes, if time permits, I skim over the changelog. Today was the first time I read about "chain of supply attacks".
That being said,

For those of you who have vetted your supply chain or are willing to accept the risks, the "opt-in" solutions exist. There are a plethora of apps (e.g. kodiak), Actions (e.g. merge-me), other products (e.g. renovate), a cron job that just runs npm update every day, etc.

This just feels like security by obscurity to me. So far, I was using an auto-merge action and while implementing it I was a bit annoyed that it's so complicated, but never thought about security concerns. That's probably also the case for many other developers that just want the feature and that not think about why it is not provided out of the box. In my opinion, it would create a much better awareness, if dependabot has a "automerge: true" feature and the documentation would discuss pro and cons of using it. Maybe couple it to an option "allow-unsafe-operations: true" or something, to make it really clear!

Relying on third-party actions to do auto-merge opens up another attack vector: Merging of non-Dependabot pull requests. If someone manages to create a user account that somehow matches the fragile string search for dependabot that 3rd party solutions require, they can easily submit pull requests on all repositories using the same matching algorithm and have their attack automatically merged. The attack would then not only be limited to dependencies, but to the actual code in the repository as well.
Even with a cryptographic signature-based solution (see https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-729702398), bugs will occur in 3rd party actions that may open up this attack vector. Actions are dependencies as open to bugs as any other dependency, after all. Therefore, the fewer dependencies, the better.

I used the dependabot auto-merge feature for a long while and was sad when it went away. My workaround is to schedule all of the dependabot updates for Tuesday mornings, and copy/paste @dependabot merge between GitHub email notifications. I don't mind this so much.
My hunch would be: the majority of maintainers don't review every line of change in their dependencies. At most, they look at the release notes. So, really the difference is:

Life before dependabot: dependencies rarely were updated.
Life with dependabot: dependencies are semi-regularly updated.

This hypothesis could be validated with a survey and some data analysis.
If this were true, it almost presents an argument in @asciimike's favor: longer delays in updating dependencies makes a supply-chain attack is less acute.
Ultimately, it's tough because official support for auto-merging dependencies presents a huge ball of liability for GitHub. This liability exists because open source is really only a web of trust. Auto-merging dependencies would allow a nefarious actor to violate the trust faster, more severely, etc.

Similar to the point raised in https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-830019926
To me at least, there's a bit of a conflict between

"auto-merging is too risky to be a core part of github / dependabot"

and the suggestion that

"Several 3rd-party GitHub Actions and bots [untrusted code, from untrusted devs] can replicate the automerge feature. [by allowing them access to PATs that have full control over the repo]"

I can understand how it reduces the legal liability faced by Github, but people looking to keep their current workflow will actively be making themselves less secure.
Ideally github / dependabot presents information about risk to me & I explicitly make an informed choice about what the acceptable trade off for me / my organisation is.
@asciimike 's comment about labels (https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-829848077) makes a lot of sense, if dependabot added labels like new maintainer / minor dev dependency patch / package from your own organisation-  then I was able somewhere else in github to say at an organisation level "automerge without approval if user is dependabot & labels have X but not Y".
Since trying to manually keep all 318 of our repos up to date is just slow manual "automation" but with the responsibility shifted to whoever is unlucky enough to be skimming over the big list of dependabot PRs and clicking merge without reading them.

Leaving the decision of what package to be merged instead a human being it is the same.
If you have a compromised npm repository that contains a virus... If you are a human you will end up merging the PR as well and being compromised.
So your suggestion basically it is not to update packages what it is so weird because why make a bot for updates in the first place?
I don't see why automerge feature is less secure than a human making the same mistake than a bot.
I would like to have this feature under a big disclaimer and A I_KNOW_WHAT_I_AM_DOING disclaimer type of thing.
The discusion about compromised repositories ends up in dont have trust on any package on npm and therefore dont update any package what makes this bot totally discouraged.
I think that a proper CVE announcements... automerge of CVE mitigations and even automerge a downgrade version on compromised repositories it is better than non supporting this feature at all.

Thanks.

I recognize that for some of you, nothing short of automerge: true will make you happy.

I don't think that's quite true. The issue, as I see it, is that GitHub/Dependabot hasn't taken on the development and documentation burden here. We aren't being told "if you want to setup automerge, add the following workflow which invokes actions/dependabot-merge@v1".
There is no clear, singular, and correct solution for this problem being offered up by Dependabot.
Where there was one vendor and one software solution before, we now have multiple vendors. We have to evaluate how much we trust them, how much it's worth learning a new toolchain, etc.
As a project maintainer using GitHub, I already have to trust GitHub. If I add another tool -- kodiak, renovate, etc -- then I'm trusting that maintainer with the relatively powerful and risky action of automatically merging PRs.
The reason a lot of people here have some frustration is this line in the migration doc:

For those of you who have vetted your dependencies, or are only using internal dependencies, we recommend adding third-party auto-merge apps, or setting up GitHub Actions to merge.

The guidance is incomplete and leaves finding a concrete solution "as an exercise for the reader". It might have been better for GitHub to have said nothing at all.

I'm trying to figure out what to do, and, in my case, I'm going to suggest to my co-maintainers that we just wait and see.
Dependabot is still offering me plenty of value, and as others have said it's not a huge problem to manually merge the PRs. I think some people are losing their heads a bit about how much of a pain that turns out to be; it's not fun but it's totally fine.

I've also replaced dependabot with renovate bot, and I can recommend everybody interested doing the same. I don't know what was so difficult in renaming automerge: true to i-know-what-im-doing-and-understand-the-risks-so-automerge-please: true and keeping perfectly valid feature, but it's no longer any concern of mine.
The fact that you've decided to announce the shutdown of native Dependabot before resurrecting this feature as part of your "investigation" in https://github.com/dependabot/dependabot-core/issues/1823#issuecomment-641594279 was the final nail in the coffin for me. Defending your decision with that argument yet recommending people to use third-party solutions to re-enable automerge is a total hypocrisy to me.
So long dependabot, yet another great product that went downhill after acquisition.

As a practical solution, I made a simple script that I can run locally that uses the GitHub API to find relevant pull requests and add a @dependabot merge comment. Because it runs locally I don't have to give my PAT to any third party.

Following https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-830065746, this is how I was able to re-implement auto-approve and auto-merge Dependabot pull request (only patch and minor updates) and after the CI becomes all green:
https://hugo.alliau.me/2021/05/04/migration-to-github-native-dependabot-solutions-for-auto-merge-and-action-secrets/

Thanks for this @asciimikeI I wonder if there is perhaps a PM we should be in touch with, in terms of understanding how we see this product feature interacting with messaging we are receiving around the product? I'm not hearing the centrality of this feature to the product offering being acknowledged in this thread, perhaps I missed it?
May I ask that our kind friends at Github also review how the Supply Chain Security is actually being marketed to clients like us? It still seems to me that there may be a disconnect between the outward-facing messaging from Github, vs the content of this thread.
For example:
https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically

Enabling and disabling version updates
You can configure your repository so that Dependabot automatically updates the packages you use.

Thanks again!

That PM is me.
It sounds like the issue is that you view "automatic upgrades" to be "zero action taken" (where does this end? The manifest file? Or should we deploy the dep to prod for you too?) while I think the current view taken by Dependabot is that the scope ends when we create the pull request. If we changed the language to be, "You can configure your repository so that Dependabot automatically creates pull requests to update packages you use" does that clear up confusion?
IMO, the difference between "enable a config in a dependabot.yml" and "add an action that basically does the same thing" is fairly minimal overhead wise but significantly more customizable from a developer perspective. It also plays nicer with existing functionality, e.g. we don't have to build an automerger that's constantly at odds with how GitHub's automerger works--we just allow devs to chain the functionality together.
Our goal is to provide a set of first party primitives, upon which folks can build whatever functionality they want.

Haha thanks @asciimike ! Apologies for not realizing you were the PM on this, and thanks for your work.
Please let us know if there might be an opportunity for us to contribute our client perspectives on this, beyond this public thread.

It's all good. Since support will hopefully direct you back to threads like this, feel free to email me at my username at github dot com.

Hi @asciimike , I tried something similar to your recommendation in one of my projects.
The result is that the PRs do get merged into the main branch automatically, but the PRs don't seem to close on merge.
I believe this is some sort of issue with the new GitHub auto-merge functionality. Is there any way to direct this issue to the correct teams at GitHub?

The result is that the PRs do get merged into the main branch automatically, but the PRs don't seem to close on merge.

I think this might be expected behavior. The Actions token expires as soon as the workflow ends.
At the point in time when the branch is merged, the token is expired and cannot delete the branch or close the PR. I had the same problem.
Or you might be right here and this is bug and not expected behavior.
If you want to work around that issue, you would be able to create a different workflow that triggers once the "test/build" action on the PR is completed. My code at the moment looks like this:
---
name: "Pull Request Auto Merge"

on:
  workflow_run:
    workflows: ["Syntax and Lint"]
    types:
      - completed

permissions:
  contents: write
  pull-requests: write

jobs:
  Dependabot-Automerge:
    runs-on: ubuntu-latest
    # Contains workaround to execute if dependabot updates the PR by checking for the base branch in the linked PR
    # The the github.event.workflow_run.event value is 'push' and not 'pull_request'
    if: >-
      github.event.workflow_run.conclusion == 'success'
      && github.actor == 'dependabot[bot]'
      && github.event.sender.login == 'dependabot[bot]'
      && github.event.sender.type == 'Bot'
      && (github.event.workflow_run.event == 'pull_request'
          || (github.event.workflow_run.event == 'push' && github.event.workflow_run.pull_requests[0].base.ref == github.event.repository.default_branch ))
    steps:
      - name: Approve Changes and Merge changes if label 'dependencies' is set
        uses<EMAIL_ADDRESS>        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            var labelNames = await github.paginate(
              github.issues.listLabelsOnIssue,
              {
                repo: context.repo.repo,
                owner: context.repo.owner,
                issue_number: context.payload.workflow_run.pull_requests[0].number,
              },
              (response) => response.data.map(
                (label) => label.name
              )
            );

            console.log(labelNames);

            if (labelNames.includes('dependencies')) {
              console.log('Found label');

              await github.pulls.createReview({
                repo: context.repo.repo,
                owner: context.repo.owner,
                pull_number: context.payload.workflow_run.pull_requests[0].number,
                event: 'APPROVE'
              });
              console.log('Approved PR');

              await github.pulls.merge({
                repo: context.repo.repo,
                owner: context.repo.owner,
                pull_number: context.payload.workflow_run.pull_requests[0].number,
              });

              console.log('Merged PR');
            }

This workflow is triggered once the "Syntax and Lint" action is completed successfully. The "auto-merge" (not GitHub auto-merge functionality) is only executed if the commit is created by the dependabot.

At the point in time when the branch is merged, the token is expired and cannot delete the branch or close the PR.

That's an interesting thought! I think it's probably still a bug since the auto-merge was enabled at the time the credentials were valid and the merge does actually complete.
If the credentials were required for merging after the workflow, I would think the merge wouldn't succeed at all instead of having partial success.

The result is that the PRs do get merged into the main branch automatically, but the PRs don't seem to close on merge.

I believe this is some sort of issue with the new GitHub auto-merge functionality. Is there any way to direct this issue to the correct teams at GitHub?

It is a known UI display issue, and we're tracking it internally. Sorry about the confusion :(

Thanks for the feedback and sorry for the confusion here.
Auto-merge will not be supported in GitHub-native Dependabot for the foreseeable future. We know some of you have built great workflows that rely on auto-merge, but right now, we’re concerned about auto-merge being used to quickly propagate a malicious package across the ecosystem. We recommend always verifying your dependencies before merging them.
The number of emojis of thumbs down is speaking what the users want! dependabot is an amazing tool and we are so excited for it to be natively part of github. however, it is missing this basic workflow of auto approval. basically, engineers want to put dependency management on "auto-pilot" as much as possible. Let them make specific choices on security them selves :)

@asciimike I just want to be clear, because on the dependabot preview settings page under installed GitHub apps, it expressly calls this out as a feature that is supported:

See the bottom section. If this issue is to be believed that is not at all accurate. It cannot be configured to automatically merge when checks pass in any meaningful way.
I can type @dependabot merge but that's not what is being described there. How do I reconcile that?

@KnechtionsCoding the dependabot preview app has different features from the github-native version.

Correct. Dependabot Preview has been deprecated since April and was shut down on August 3rd. We are in the process of uninstalling the Preview app from repos across GitHub, so that page will disappear soon.

Folks, if the decision of disabling auto-merge is final and won't be changed in the nearest future, please close this issue and add some notification to the docs, so people won't be confused while reading this huge page :)

Interacting with dependabot would be a lot smoother if the @dependabot user would be autocompleted. I'm having to type the whole thing manually to give it a command and it's starting to become annoying.

Interacting with dependabot would be a lot smoother if the @dependabot user would be autocompleted. I'm having to type the whole thing manually to give it a command and it's starting to become annoying.

Thanks, that's good feedback I've definitely felt this myself. I'll raise this internally and see if there's something in the roadmap more broadly for bots to be autocompleted in mentions 👍

In case anyone stumbles across this issue.
The official GitHub Docs now document a process for Dependabot auto merge here.
Sadly, it looks like the fetch-metadata-action is not getting a lot of attention.

How do we disable auto-merge until our CI integration workflow completes? Auto-merge doesn't seem to block on this currently.

Put that code into your CI workflow and use needs

@Kurru you can also add a branch protection rule that requires status checks to pass. That way, you can also require non-GitHub Actions CI runs to be successful.

Those options are kinda workable though not great. We are a tiny company with a mono-repo and we don't want branch protections, but would really like to auto-submit dependabot pull requests if they pass our CI. Adding to the CI workflow isn't terrible, though we do have multiple CI targets that are impacted by certain pull requests (we use multi-project Gradle)

This kind of "auto-merge" workarounds are rather hacky and certainly not as intuitive to use or configure as renovate's baked-in automerge feature. Would really appreciate this being a "native" feature to dependabot as it was in v1.

I'm using the officially documented auto-merge workflow mentioned in https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-995664569, and it works, but with an odd quirk. If I want it to wait until CI checks pass, I have to turn on the "Include administrators" branch protection setting, which I'd rather leave off. Specifically, I want to be able to push to main myself directly, without a PR, but I want PRs to block on CI passing before they can be merged.
Any ideas? Can I run the auto-merge with a token that doesn't include the administrator permissions somehow? Or anything else? Thanks in advance!

@snarfed:
Instead of having a standalone workflow set the auto-merge flag, integrate it into your normal workflows.
If you have a single workflow for the rest of your tests, you can use: needs.
If you have a bunch of them, you could have a workflow with workflow_dispatch that each check triggers which checks to see if everything has passed.
Not sure about the "official" way to do this, although, I'd support having something officially documented as it seems like a perfectly reasonable request.
From reading https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request, it appears that dependabot is seen as an admin and thus isn't really bound by the terms of auto-merge. Which would be why enforcing require checks for administrators results in auto-merge doing what you want. I think it's reasonable to have the documentation for that page also changed to clarify this (that dependabot is functionally treated as an administrator, and for the auto-merge to wait for checks would require the enforce checks for administrators option).

@jsoref thanks for the reply! I use CircleCI for CI, not GitHub Actions.

While what I've described is framed in GitHub Workflow terminology, you can do the same sorts of operations anywhere.
https://discuss.circleci.com/t/run-another-workflow-after-a-workflow-succeeds/36294

Technically true!...but way more effort to build and maintain than I'd like.
Specifically, I only want to auto merge patch or minor version upgrades. Github Actions exposes this in the update-type metadata as version-update: semver-patch, -minor or -major.  That's easily consumed in Actions, but in Circle, I'd need to write code that auths into the GitHub API and uses it to fetch that metadata. Ugh.
(I briefly searched Circle's public orbs for anything relevant that I could use, but I didn't see anything.)

FWIW, I also have a set up with CircleCI and the officially documented auto-merge workflow, and it works well without turning on "Include administrators" setting. I'm using the secrets.GITHUB_TOKEN token just like in the documented example.

Interesting: the auto merge behavior changed at some point in the last few days. My branch protection has "Include administrators" disabled, and when the github-actions bot enables auto-merge on a PR (via the workflow in the docs), GitHub now waits for CI to pass before merging. Example: https://github.com/snarfed/granary/pull/298

Following up here, I may have misdiagnosed this initially. I'm seeing a different bug or odd behavior now, which was maybe also the root cause before.
It looks like auto merge is indeed waiting for the branch protection required checks to pass after all, even with "Include administrators" off. However, after the merge, it occasionally doesn't show that all required checks passed before merging.
https://github.com/snarfed/bridgy/pull/1236#event-6842402662= (screenshot below) is an example. The repo's branch protection on main requires the ci/circleci: build check to pass. Auto merge was enabled at 3:00p PT, most other checks ran within a few minutes, CircleCI finished and passed at 3:38:56p PT, and the GitHub UI says the PR was merged at 3:38p PT.
So it seems pretty like that Circle finishing triggered the merge. However, the GitHub UI says Circle hadn't finished when the PR was merged. I'm guessing this is a bug in the UI...?
(Yes, clock skew happens, but I doubt Circle's and GitHub's clocks were off by 30+m. 😁)

FWIW, there's also https://github.com/palantir/bulldozer, which does auto merging with a small configuration file. This is what we've used at my org for years and it's been pretty solid. You just add a config to your repo that will only auto-merge PRs created by dependabot. It also allows you to wait for non-required checks to pass before merging, you just have to add those checks to the config.

I agree that dependabot should not set auto-merge due to the security issues it raises.  If you really know what you're doing and really want auto-merge, just use something like https://github.com/marketplace/actions/enable-automerge-action

For the sake of discussion, what's the difference between the security concerns of Auto Merge versus that of a human pressing Merge? Wouldn't the human be just as oblivious to new vulnerabilities in the updated dependency as dependabot? What if the repo already has required security checks in place in the PR actions?

An adult can read the source code changes for the dependency before merging the PR.
It's true that not all humans will be able to understand the changes, but a human could.
Also, if you wait a bit on a dependency update, it's possible that if there is a problem with the update, some other human will report about it in a place the human could discover it.
A baby just tapping on buttons and triggering a merge without understanding the consequences of their actions otoh is dangerous. They're cute 👶, but dangerous if left unattended.

If the reason this isn't added is because of security concerns, couldn't you add an option to delay dependency updates by some amount of time, e.g. 1 month after release, so that new dependency updates are at least a month old and can be safely auto-merged?

Depfu has an option similar to this: https://docs.depfu.com/article/36-reasonably-up-to-date

🍿

@jsoref I see your point, but (at least in my experience) nobody checks the source changes of their upstream deps. Though we can (and probably should), we don't.
I don't know. It's something to consider. 🤷

@jsoref I see your point, but (at least in my experience) nobody checks the source changes of their upstream deps. Though we can (and probably should), we don't.
I don't know. It's something to consider. 🤷

Is this an argument against auto-merging, or against updating third-party dependencies in general?

Sorry if that wasn't clear @shepherdjerred. I was responding to @jsoref's comment above, which says we shouldn't allow auto-merging because humans should always have an opportunity to review dependency changes before merging.

Thank you for clarifying :)
As an aside, I've setup Dependabot auto-merging with a simple GitHub Action, though I would still like to see this as a native option for Dependabot.
https://github.com/shepherdjerred/glitter/blob/b06caa53ca1b3d5adb9dad8d53139cb159e6b53d/.github/workflows/dependabot.yml#L1-L22

We recommend always verifying your dependencies before merging them.

Isn't that what status checks are?

Status checks are automated. The wording implies a human reasoning through things.

@shepherdjerred I've used your Github Action, but my org requires two reviews before a PR can be merged. I've added a Ruleset for that and added Dependabot to the Bypass list, but PRs still aren't merged.
I think this may be related to https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository - "The actor can then choose to bypass any branch protections and merge that pull request.", but I don't know how to make Dependabot bypass the protections
Ruleset

PR

@piotrjak Renovate gets around this with GitHub apps:

https://github.com/renovatebot/renovate-approve-bot
https://github.com/apps/renovate-approve
https://github.com/apps/renovate-approve-2

There might be similar bots for Dependabot. A cursory search found this:

https://github.com/dannyshaw/dependabot-approval-bot

But, your issue isn't really related to this thread. You have auto-merge enabled; you're now fighting GitHub's auto-merge feature.


VSCode doesn't autoimport from export * as X

Bug Report
I'm not sure if this issue belongs on TypeScript or VSCode. Let me know.
If you do export * as SomeName, then write SomeName elsewhere, there is no autoimport suggestion.
You can fix it by doing this:
import * as SomeName from './some-file'

export { SomeName }

Now, writing SomeName does give autoimports.
However, this breaks Webpack tree shaking.
🔎 Search Terms

autoimport
export * as

🕗 Version & Regression Information
I've always seen this behavior in VSCode.
⏯ Playground Link
I'll put together a git repo. I wish I could use a playground, but I don't know how to simulate this with a single file.
🙁 Actual behavior
There's no autoimport suggestion.
🙂 Expected behavior
If I do export * as Y from './y', then other files should be able to detect that Y is an import-friendly variable.

I found the issue. It was due to JSX + capitalization.
If you export * as hello, and then try to get autocomplete from <hello.IconName /> in JSX, it won't work.
However, if you type hello outside of JSX scope, it works. Renaming the variable to have a capital first letter fixes it for JSX:
export * as Hello from './hello`

Then in JSX:
<Hello.Icon />


Updating docs to reflect full path requirement for ssh key

Just ran through the example and ran into issues with the file path path.

Ah this will save people tons of time

It certainly would have saved some :)


feat(operator): add publishBehavior operator and spec

Implements #219.
We're not sure yet whether #219 should be done or not, but in any case, here's the PR in the pipeline awaiting for review/approval.

@staltz lgtm

merged with 249ab8d
Thank you, @staltz!


Includes not working with local packages as of 3.3.3/3.4.0-beta1

I have a number of local packages in my project under the /packages folder.  Previously, I was just using an index.scss file and including their stylesheets by file path.  Now, I get the same kind of error for all include attempts:
While processing files with fourseven:scss (for target web.browser):
   /ondemjobs.scss: Scss compiler error: File to import: {}/packages/views/stylesheets/AppModeChoice.scss not found in file:
   {}/ondemjobs.scss

I've also tried {views}/stylesheets/AppModeChoice.scss without success.
This happens with 3.3.3, and 3.4.0-beta1.

The second syntax {views}/stylesheets/AppModeChoice.scss is correct. This is probably due to how you add your scss files in your package.js file.
You need to add them using: api.addFiles([...],'client',{isImport:true})

In Meteor 1.2 I can't use addFiles for .scss files.  It complains that there's no plugin to handle them, and requires me to use api.addAssets instead.

And you're sure you have fourseven:scss also in your package.js use list for client architecture and you?
Otherwise we'd need a reproduction, because this should work.

I got this working, but the process was not pleasant.  Doesn't feel like an improvement over the previous version.
Here's how I got it all working:

Move all of my variables and mixins into a separate package
api.use that package in all of my local packages that have scss files
api.use fourseven:scss in all of my local packages with scss to compile the files
Import the vars/mixins package css into each and every .scss file that uses variables or mixins
Include each file into the main app scss.

So, where I was previously able to use variables without explicitly including them in my packages, I now have to use explicit imports, at the package level and the scss level.  I'm not sure that's better than before, where I just included the .scss files into a master index file that also imported the vars and mixins.  It was a whole lot less trouble that way.

You should still be able to do it the old way. But again, I would need to see a reproduction to further help

I've converted everything over to the new way.  It's just a lot of extra housekeeping to keep track of, as is too often the case in Meteor itself as well.  Closing this.


Fix failure response when we make request to non-allowed cross-domain url

When we initialize failureResponse here xhr variable not initialized yet.
So, if we have a fired onError (for example request to non-allowed cross-domain requests url) we have undefined``xhr in resp.rawRequest.
Fixed it and wrote the test for that case.

Hi, sorry I overlooked this, should have merged it a long time ago.
I have one issue though - the test doesn't fail on current master. It just hangs.
Did it fail for you?

bump.
What is the expected outcome of the test you added in master - before the fix?

Oh, sorry for late.
On current master my test failed (if we add the only test, not fix):
  [func] Request to domain with not allowed cross-domain

    XMLHttpRequest cannot load http://www.mocky.io/v2/57bb70c21000002f175850bd. Origin http://localhost:3000 is not allowed by Access-Control-Allow-Origin.
    ✔ should return error
    ✔ should be equal

    ✖ should be equal
    ------------------
      operator: equal
      expected: 'object'
      actual:   'undefined'

rawRequest: xhr is undefined, because we try to use it in failureResponse before initialize.
Renew my branch with current master.

I tried it some time ago and it would hang on the test and never finished. I'll try again today.

👍 Let's keep in touch

wait let's check the premise here from back in August
premise:

When we initialize failureResponse here xhr variable not initialized yet.

result drawn from premise:

So, if we have a fired onError (for example request to non-allowed cross-domain requests url) we have undefined``xhr in resp.rawRequest.

my reading of the code tells me premise is false on the basis:
xhr variable is initialized before failureResponse object reference call order enters the JavaScript parser's execution stack

@reqshark oops, you're totally right about xhr initialization. Xhr is initialized, cuz hoisting, but anyway it's undefined and then, we set xhr variable, but not failureResponse.rawRequest

Thanks for the fix!
My apologies for taking so long, maintaining xhr is on my hobby time (eg. now, at 1AM :) )
but really, I somehow overlooked this.

Sorry to be a bother, but is there any chance for a patch release of this soon? :)
In my error tracker, I've noticed a lot of exceptions relating to rawRequest being undefined, and this would fix that behaviour.

Thanks for asking, I was busy at the time, but I should've published this last Friday, just missed that.
v2.3.2 published

Thank you thank you 😄


Artifacts with vector path in example template

Verified to be an issue in 6869d2b3c2 and 818550fd5dc42c78ba19d98b97d6a072fa885fec
Only tested on Windows
Steps to reproduce:

Stuff/uno build -t=dotnet -r -l ProjectTemplates/Projects/Example/
Navigate to the last page

This Path has an invalid final bit to it ...M -1.0 -10.0 l 1,1 z"  That moves to -1,-10 does a line to 1,1, and then closes the figure. I suppose that shouldn't render anything, but that might be hard to detect such invalid shapes.

This is a capture from Inkscape, notice the odd bit in the top-left. It does render differently though, so perhaps still technically a defect in fuselibs.

DotNet doesn't appear to have a function that supports this correctly. It has only CloseFigure which draws a straight connecting line, which is what we are seeing. SVG allows a move command to "end" the current figure without drawing a line. DotNet is closing to the bototm-right graphic on that final close command.
In the SVG file, that bottom-right graphic, the top-left corner, draws without a completing path. There are two end-points instead of a complete curve.

StartFigure/CloseFigure also draws the connecting line.
In order to support the correct SVG drawing here we'd need to create two paths: One for the filling and one for the strokes. The filled path would require use calling StartFigure and CloseFigure. The stroked path would not want that -- since we could be animating lines.  Unfortunately System.Drawing has no support for ending a segment without adding a connecting line.

It's a regression though, since the line wasn't visible in fuselibs version 1.7.


[analyzer] add a fix for "EOL at end of file" lint.

I am trying to add a fix to add "EOL at end of file".
The patch works on a locally built SDK, however, I don't know:

What is the difference between 'assist' and 'fix'? Some corrections implement one or both of them.
Fix AddEolAtEndOfFileTest, gives Expected one error, found: none. Is it because the lint is not triggering error? and how to fix that.

https://dart-review.googlesource.com/c/sdk/+/208583

What is the difference between 'assist' and 'fix'? Some corrections implement one or both of them.

A quick fix is a set of edits that is made available to the user in response to a diagnostic. For example, if a lint is produced and if there is a correction producer associated with the lint, then the quick fix will be made available to the user. If the associated diagnostic (or set of diagnostics) are not being produced, or if the correction producer fails to produce a set of changes, then the fix will not be available.
A quick assist is a set of edits that is available when the code pattern it changes is found. For example, there is an assist that will take code of the form
if (a && b) {
  s;
}

and convert it to
if (a) {
  if (b) {
    s;
  }
}

It is presented to the user only when there is a conditional-and expression in an if statement.
I would suggest that we probably shouldn't offer this as an assist, only as a fix. We have to be really selective about adding assists because each one has to examine the AST to see whether it should be made available, and that takes time.

Fix AddEolAtEndOfFileTest, gives Expected one error, found: none. Is it because the lint is not triggering error? and how to fix that.

Yes. You need to subclass FixProcessorLintTest and override the getter that returns the name of the lint that should be enabled.

Thanks a lot for the detailed feedback and guidance.

https://dart-review.googlesource.com/c/sdk/+/208583


Cherry pick PR #270  to release/2.3 branch

This PR cherry-picks the following commit(s) to release/2.3:

3593cde8aab7

bors merge


feat: list smart modules

Provides support to list Smart Modules similar to how we do from CLI using
fluvio smart-module list.

Could you fix conflicts when you have a chance?

Sure thing!


[WFCORE-5163] Don't reject EE 9 permissions.xml files

https://issues.redhat.com/browse/WFCORE-5163

@bstansberry thanks


add constructor to transformdelegate

didnt know that it already existed  https://github.com/Clazex/HollowKnight.Osmi/blob/4a8e03719386970ae52a0116207714f660032353/Osmi/Utils/GameObjectUtil.cs#L32


ARROW-10561: [Rust] Simplified Buffer's write and write_bytes and fixed undefined behavior

This PR addresses 3 small issues on MutableBuffer:

write_bytes is incorrect, as it double-increments len: the length is incremented both on self.write and also by write_bytes itself. This leads to more allocations than necessary.
write is implemented from the trait io::Write. However, this trait is suitable for fallible IO operations. In the case of a write to memory, it isn't really fallible because we can always call reserve to allocate more space.
write and write_bytes are really similar.

This PR replaces both write_bytes and write by extend_from_slice (inspired by Vec::extend_from_slice) that checks the available capacity and reserves more if necessary. This has the same or better performance than write, as it performs a single comparison per call.

@alamb @jhorstmann @vertexclique , I think I need your help here. This change is causing a segfault in one of the benchmarks, even though I have not changed any unsafe code and think the change is reasonable.
I narrowed it down to the function set_bits_raw. I think that this function is accessing a byte too many. However, my bit knowledge is limited here. I filled ARROW-10562 with why I think the function has an issue. IMO the reason this has not surfaced before is that we were allocating too much memory in the boolean buffers, and thus the memory address was fine.

My suggestion for this is merging https://github.com/apache/arrow/pull/8634 then implementing bit ops over that interface. And get rid of bit_util.rs. That's going to remove all these issues in a single shot.

Ok, I confirm that this error is due to a wrong byte offset on the set_bits_raw and that this undefined behavior is already present in master:
Switched to branch 'master'
Your branch is up to date with 'upstream/master'.
   Compiling arrow v3.0.0-SNAPSHOT (/Users/jorgecarleitao/projects/arrow/rust/arrow)
    Finished bench [optimized] target(s) in 53.79s
     Running /Users/jorgecarleitao/projects/arrow/rust/target/release/deps/builder-65ece1c06584e62c
Gnuplot not found, using plotters backend
bench_primitive         time:   [522.83 us 523.58 us 524.34 us]
                        thrpt:  [7.4499 GiB/s 7.4607 GiB/s 7.4713 GiB/s]
                 change:
                        time:   [-6.7844% -4.8815% -3.0463%] (p = 0.00 < 0.05)
                        thrpt:  [+3.1420% +5.1320% +7.2782%]
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  3 (3.00%) high mild
  6 (6.00%) high severe

Benchmarking bench_bool: Warming up for 3.0000 serror: process didn't exit successfully: `/Users/jorgecarleitao/projects/arrow/rust/target/release/deps/builder-65ece1c06584e62c --bench` (signal: 11, SIGSEGV: invalid memory reference)

This PR removes now also removes that function altogether and replaces it by a safe counterpart. I suspect that there will be a performance regression, but I do not know enough of bit operations to be able to fix the function (and it is not clear whether we should, as per @vertexclique suggestion of using bitvec).

I am going to take another hard look at https://github.com/apache/arrow/pull/8598 and see if we can get enough consensus to get it merged

In terms of evidence that there is a problem on master, I ran the arrow test suite under valgind @<PHONE_NUMBER>2c1a527ffb375e7790102f58edb4f9 on master and it does flag an invalid read (that could cause a segfault depending on the circumstances). Here is the error it flagged:
test compute::kernels::cast::tests::test_cast_dict_to_dict_bad_index_value_utf8 ... ==5483== Invalid read of size 1
==5483==    at 0x55D7B2: arrow::util::bit_util::set_bits_raw (bit_util.rs:128)
==5483==    by 0x605D49: <arrow::array::builder::BufferBuilder<T> as arrow::array::builder::BufferBuilderTrait<T>>::append_n (builder.rs:339)
==5483==    by 0x62C854: arrow::array::builder::PrimitiveBuilder<T>::append_slice (builder.rs:591)
==5483==    by 0xA992F6: arrow::array::builder::StringBuilder::append_value (builder.rs:1781)
==5483==    by 0x6A309B: arrow::array::builder::StringDictionaryBuilder<K>::append (builder.rs:2435)
==5483==    by 0x302DA3: arrow::compute::kernels::cast::tests::test_cast_dict_to_dict_bad_index_value_utf8 (cast.rs:2612)
==5483==    by 0x31E499: arrow::compute::kernels::cast::tests::test_cast_dict_to_dict_bad_index_value_utf8::{{closure}} (cast.rs:2598)
==5483==    by 0xA751ED: core::ops::function::FnOnce::call_once (function.rs:232)
==5483==    by 0xB97365: call_once<(),FnOnce<()>> (boxed.rs:1008)
==5483==    by 0xB97365: call_once<(),alloc::boxed::Box<FnOnce<()>>> (panic.rs:318)
==5483==    by 0xB97365: do_call<std::panic::AssertUnwindSafe<alloc::boxed::Box<FnOnce<()>>>,()> (panicking.rs:331)
==5483==    by 0xB97365: try<(),std::panic::AssertUnwindSafe<alloc::boxed::Box<FnOnce<()>>>> (panicking.rs:274)
==5483==    by 0xB97365: catch_unwind<std::panic::AssertUnwindSafe<alloc::boxed::Box<FnOnce<()>>>,()> (panic.rs:394)
==5483==    by 0xB97365: run_test_in_process (lib.rs:541)
==5483==    by 0xB97365: test::run_test::run_test_inner::{{closure}} (lib.rs:450)
==5483==    by 0xB969F8: test::run_test::run_test_inner (lib.rs:475)
==5483==    by 0xB94BE9: test::run_test (lib.rs:505)
==5483==    by 0xB829D8: run_tests<closure-2> (lib.rs:284)
==5483==    by 0xB829D8: test::console::run_tests_console (console.rs:280)
==5483==  Address 0x65c1900 is 0 bytes after a block of size 128 alloc'd
==5483==    at 0x4C34443: memalign (vg_replace_malloc.c:906)
==5483==    by 0x4C34546: posix_memalign (vg_replace_malloc.c:1070)
==5483==    by 0xEB42F3: aligned_malloc (alloc.rs:95)
==5483==    by 0xEB42F3: alloc (alloc.rs:22)
==5483==    by 0xEB42F3: realloc_fallback (alloc.rs:39)
==5483==    by 0xEB42F3: realloc (alloc.rs:50)
==5483==    by 0xEB42F3: __rdl_realloc (alloc.rs:320)
==5483==    by 0x55348C: alloc::alloc::realloc (alloc.rs:124)
==5483==    by 0x71FB58: arrow::memory::reallocate (memory.rs:187)
==5483==    by 0x9D5606: arrow::buffer::MutableBuffer::reserve (buffer.rs:665)
==5483==    by 0x5FFC65: <arrow::array::builder::BufferBuilder<T> as arrow::array::builder::BufferBuilderTrait<T>>::reserve (builder.rs:307)
==5483==    by 0x605BEF: <arrow::array::builder::BufferBuilder<T> as arrow::array::builder::BufferBuilderTrait<T>>::append_n (builder.rs:335)
==5483==    by 0x62C854: arrow::array::builder::PrimitiveBuilder<T>::append_slice (builder.rs:591)
==5483==    by 0xA992F6: arrow::array::builder::StringBuilder::append_value (builder.rs:1781)
==5483==    by 0x6A309B: arrow::array::builder::StringDictionaryBuilder<K>::append (builder.rs:2435)
==5483==    by 0x302DA3: arrow::compute::kernels::cast::tests::test_cast_dict_to_dict_bad_index_value_utf8 (cast.rs:2612)
==5483==
==5483== Invalid write of size 1
==5483==    at 0x55D7B4: arrow::util::bit_util::set_bits_raw (bit_util.rs:128)
==5483==    by 0x605D49: <arrow::array::builder::BufferBuilder<T> as arrow::array::builder::BufferBuilderTrait<T>>::append_n (builder.rs:339)
==5483==    by 0x62C854: arrow::array::builder::PrimitiveBuilder<T>::append_slice (builder.rs:591)
==5483==    by 0xA992F6: arrow::array::builder::StringBuilder::append_value (builder.rs:1781)
==5483==    by 0x6A309B: arrow::array::builder::StringDictionaryBuilder<K>::append (builder.rs:2435)
==5483==    by 0x302DA3: arrow::compute::kernels::cast::tests::test_cast_dict_to_dict_bad_index_value_utf8 (cast.rs:2612)
==5483==    by 0x31E499: arrow::compute::kernels::cast::tests::test_cast_dict_to_dict_bad_index_value_utf8::{{closure}} (cast.rs:2598)
==5483==    by 0xA751ED: core::ops::function::FnOnce::call_once (function.rs:232)
==5483==    by 0xB97365: call_once<(),FnOnce<()>> (boxed.rs:1008)
==5483==    by 0xB97365: call_once<(),alloc::boxed::Box<FnOnce<()>>> (panic.rs:318)
==5483==    by 0xB97365: do_call<std::panic::AssertUnwindSafe<alloc::boxed::Box<FnOnce<()>>>,()> (panicking.rs:331)
==5483==    by 0xB97365: try<(),std::panic::AssertUnwindSafe<alloc::boxed::Box<FnOnce<()>>>> (panicking.rs:274)
==5483==    by 0xB97365: catch_unwind<std::panic::AssertUnwindSafe<alloc::boxed::Box<FnOnce<()>>>,()> (panic.rs:394)
==5483==    by 0xB97365: run_test_in_process (lib.rs:541)
==5483==    by 0xB97365: test::run_test::run_test_inner::{{closure}} (lib.rs:450)
==5483==    by 0xB969F8: test::run_test::run_test_inner (lib.rs:475)
==5483==    by 0xB94BE9: test::run_test (lib.rs:505)
==5483==    by 0xB829D8: run_tests<closure-2> (lib.rs:284)
==5483==    by 0xB829D8: test::console::run_tests_console (console.rs:280)
==5483==  Address 0x65c1900 is 0 bytes after a block of size 128 alloc'd
==5483==    at 0x4C34443: memalign (vg_replace_malloc.c:906)
==5483==    by 0x4C34546: posix_memalign (vg_replace_malloc.c:1070)
==5483==    by 0xEB42F3: aligned_malloc (alloc.rs:95)
==5483==    by 0xEB42F3: alloc (alloc.rs:22)
==5483==    by 0xEB42F3: realloc_fallback (alloc.rs:39)
==5483==    by 0xEB42F3: realloc (alloc.rs:50)
==5483==    by 0xEB42F3: __rdl_realloc (alloc.rs:320)
==5483==    by 0x55348C: alloc::alloc::realloc (alloc.rs:124)
==5483==    by 0x71FB58: arrow::memory::reallocate (memory.rs:187)
==5483==    by 0x9D5606: arrow::buffer::MutableBuffer::reserve (buffer.rs:665)
==5483==    by 0x5FFC65: <arrow::array::builder::BufferBuilder<T> as arrow::array::builder::BufferBuilderTrait<T>>::reserve (builder.rs:307)
==5483==    by 0x605BEF: <arrow::array::builder::BufferBuilder<T> as arrow::array::builder::BufferBuilderTrait<T>>::append_n (builder.rs:335)
==5483==    by 0x62C854: arrow::array::builder::PrimitiveBuilder<T>::append_slice (builder.rs:591)
==5483==    by 0xA992F6: arrow::array::builder::StringBuilder::append_value (builder.rs:1781)
==5483==    by 0x6A309B: arrow::array::builder::StringDictionaryBuilder<K>::append (builder.rs:2435)
==5483==    by 0x302DA3: arrow::compute::kernels::cast::tests::test_cast_dict_to_dict_bad_index_value_utf8 (cast.rs:2612)
==5483==

My interpretation of this report is that arrow::buffer::MutableBuffer::reserve is reading off the end of the array. I haven't studied the code closely.
The actual command I used is below in case anyone is interested
PARQUET_TEST_DATA=pwd/../../cpp/submodules/parquet-testing/data ARROW_TEST_DATA=pwd/../../testing/data valgrind /home/andrew/Software/arrow/rust/target/debug/deps/arrow-b9bea680be7dc6e4

(if you be so kind, could you quickly run fd75933 , just to test whether this PR addresses the issue?)

(if you be so kind, could you quickly run fd75933 , just to test whether this PR addresses the issue?)

@jorgecarleitao  -- I did so. There are no errors reported by valgrind when I ran commit fd75933bead400a3943af1d336c006c6656d6f80 (HEAD, jorgecarleitao/buffer_write)
==7779== For lists of detected and suppressed errors, rerun with: -s
==7779== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

FWIW I ran the code in #8598 under valgrind and it does not appear to fix the issue https://github.com/apache/arrow/pull/8598#issuecomment-726749085

Thanks a lot, @alamb , really useful data points ❤
For me that is enough of a reason: fix UB with safe code, and figure out a way to perform multi-bit assignment on a single call fast on a subsequent PR.
I also agree with @jhorstmann about the len_added. I did not want to change the API for builders in this PR because this already does a backward incompatible change on MutableBuffer and one change like this per PR avoids mixing the discussions).


detect the gflags namespace

Sometimes gflags is in google, sometimes it's in gflags. Cook up an autoconf test to figure it out, and add a little header to do something appropriate for us.

dupe of #723?

Correct, this is a dupe of #723.


Bug: Can not use @oxc-parser/wasm without error

Hello ! I've been trying to use @oxc-parser/wasm but there is an error.
Error: Cannot find package<EMAIL_ADDRESS>imported from 'test/a.mjs'

To reproduce the error:

run npm i @oxc-parser/wasm in an empty folder
create a test.mjs file, having this content:

import {parseSync} from "@oxc-parser/wasm"
console.log(parseSync)

Try to run the code.

The state of wasm build is really confusing.
As stated in the README

This package is built with wasm-pack build --release --target web for bundler (webpack / vite) consumption. Checkout oxc-parser for usage in node.js.

The original issue is about making the napi version work on stackbliz, pinging @Brooooooklyn who may know more.

The original issue is about making it work on stackbliz, pinging @Brooooooklyn who may know more.

We may need to publish more builds (wasi, node.js target) in the near future, but I'll close this for now as I don't have the bandwidth.

Closed by #2916
Released v0.1.0 https://www.npmjs.com/package/@oxc-parser/wasm


staticpaths are deprecated. Use Make instead.

The docs say to use the --static flag to serve static files https://staticjinja.readthedocs.io/en/latest/user/quickstart.html?highlight=static#configuration.
Here's what I tried
staticjinja watch --static static
I get this warning
env/lib/python3.6/site-packages/staticjinja/staticjinja.py:97: UserWarning: staticpaths are deprecated. Use Make instead.   warnings.warn("staticpaths are deprecated. Use Make instead.")
And my static files under templates/static were not copied

Closing as duplicate of https://github.com/staticjinja/staticjinja/issues/97


problem with persian language

Describe the bug
I'm not sure if this is a bug or if I did something wrong.
I'm trying to create a site in persian language.
1. I used persian name for my page structure like this:

2. everything works fine :

3. but when I create a sitemap, the url encoded like this:

4. and when I click the generated link i recieve error page not found 404:

Did I do something wrong or is this a bug?
Reproduction
No response
System / Nuxt Info
No response

Hi @Alijaaan, as far as I'm aware the sitemap module is doing the right thing. These characters aren't technically valid as a path, see https://webmasters.stackexchange.com/questions/11482/is-it-okay-to-use-persian-utf-8-characters-in-our-urls.
The encoding link should work, this may be an upstream Nuxt issue.

Actually, bcause of this problem and one other important issue, I had to change the whole solution for creating and managing my sitemaps and I wrote everything from the scratch.
Thanks for your answer :)

Fair enough, thanks for letting me know.


477 | Total Hamming Distance | C++

Title - Total Hamming Distance
What will change - Add Solution
Type of Issue - Adding New Code
Please add/delete options that are not relevant.

[x] Adding New Code
[x] Improving Code
[x] Improving Documentation
[x] Bug Fix

Programming Language
Please add/delete options that are not relevant.

[x] C++

Self Check

Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

Please assign me this issue @SSKale1

@Vicky-Jha Assigning it to u for now, but from next time please wait to get assigned before you make a pull request

Yes, i understood @Yashica7

please assign it to me @SSKale1


fixes #904. E.O.default performance

See #903

Codecov Report

Merging #905 (5576bf2) into develop (fb0aa72) will decrease coverage by 0.20%.
The diff coverage is 80.00%.

@@             Coverage Diff             @@
##           develop     #905      +/-   ##
===========================================
- Coverage    57.96%   57.75%   -0.21%
===========================================
  Files           73       73
  Lines         4094     4098       +4
===========================================
- Hits          2373     2367       -6
- Misses        1721     1731      +10

Impacted Files
Coverage Δ

...t/Distributions/PointSetDist/MixedShapeBuilder.res
54.54% <0.00%> (-18.19%)
:arrow_down:

...rescript/Distributions/PointSetDist/Continuous.res
62.22% <100.00%> (ø)

...c/rescript/Distributions/PointSetDist/Discrete.res
23.65% <100.00%> (ø)

...ucerInterface/ReducerInterface_ExternalLibrary.res
100.00% <100.00%> (ø)

...cript/ReducerInterface/ReducerInterface_StdLib.res
100.00% <100.00%> (ø)

packages/squiggle-lang/src/rescript/Utility/E.res
48.29% <100.00%> (+0.54%)
:arrow_up:

...rface/ReducerInterface_InternalExpressionValue.res
46.87% <0.00%> (-5.00%)
:arrow_down:

Continue to review full report at Codecov.

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


Axis support for LT and RT

Thank you very much for your contribution. Your previous modifications to borealis (like touch and recyclerList) have been very helpful to me.
And good job for moonlight, Looking forward to seeing the borealis version of Moonlight on iOS.

I also want to thank you for improving borealis with so many different platforms support, if not this I don't think I've even started to think about porting my Moonlight app to iOS.
BTW, could you check my branch by yourself? I've started to upstream it with your fork, maybe I've added something you could would like to cherrypick as well, i.e. I'm not sure if you need my changes for MetalANGLE support on iOS, but maybe some improvements could fit your needs

I think changing major version could scary devs from upgrading, like it was with v1 -> yoga update (and it was reasonable, it was almost a new library written from scratch), while currently I had no issues with migrating my yoga branch to current yours one, so I'd prefer to use something like v2.x

Yeah, then maybe 2.0 for the original yoga, 2.1 for the new release, I'll add some CI for different platform before the release.


Catch unexpected values in array

As a result of a brief linkedin bug where the array prototype was modified, this simple solutions offers better defensive detection of values passed in the config by checking that the value has its own property associated with it.

Note regarding failing tests. I've opened an issue: https://github.com/tableau-mkt/jquery.addressfield/issues/64

Thanks for the issue on the test fails @lesliedoherty.  I can repro them locally too, but they only occur on the git1 and git2 versions of jQuery.
Maybe we stop testing against "dev" branches for jQuery, but at least update the versions we test against?  e.g.
Go from
['1.3.2', '1.4.4', '1.5.2', '1.6.4', '1.7.2', '1.8.3', '1.9.1', '1.10.2', '1.11.3', '1.12.0', 'git1', '2.0.3', '2.1.4', '2.2.0', 'git2']

...to...
['1.3.2', '1.4.4', '1.5.2', '1.6.4', '1.7.2', '1.8.3', '1.9.1', '1.10.2', '1.11.3', '1.12.4', '2.0.3', '2.1.4', '2.2.4', '3.0.0', '3.1.1', '3.2.1', '3.3.1']

In Gruntfile.js?

Thanks all. I updated the jQuery test targets. Merging to master, then picking the change into branches where it applies and releasing updates.


Save MOCA script execution history

Let's keep it simple and just keep session's exec history in memory and allow user to show it via quick pick command

This has been added in v1.7.26

This has been added in v1.7.26


support comment count links for Disqus

See: https://help.disqus.com/developer/adding-comment-count-links-to-your-home-page

Great! Thanks for your PR!


Small update to v2-oauth2-auth-code-flow.md

@kendaleiv : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good; merging. Thanks.

Thanks!


Controller scaffolding using EF fails when project contains middleware configured using secrets

It seems EntityFrameworkServices.GetModelMetadata will fail at the step Attempting to figure out the EntityFramework metadata for the model and DbContext when building the application services in EntityFrameworkServices.TryCreateContextUsingAppCode, if the Startup class adds some middleware with required options being populated from the secret manager.
I have created a new ASP.Net Core 1.0.0 project using the default Web Application template adding individual accounts authentication.
Then I have added the google authentication middleware:
    "Microsoft.AspNetCore.Authentication.Google": "1.0.0"

I have updated my startup class with the Google middleware, where the ClientId and Secret are read from the SecretManager tool:
app.UseGoogleAuthentication(new GoogleOptions
{
    ClientId = Configuration["GoogleClientId"],
    ClientSecret = Configuration["GoogleClientSecret"]
});

If I then:

Create a new model class
Either add a dbSet to the default ApplicationDbContext or create a new dbContext class
Run the MVC Controller with Views, using Entity Framework scaffolding selecting that model class and context

I get the following error:
C:\Program Files\dotnet\dotnet.exe aspnet-codegenerator --project "C:\Users\Daniel.Garcia\Documents\Github\WebApplication3\src\WebApplication3" controller --force --controllerName ArticlesController --model WebApplication3.Models.Article --dataContext WebApplication3.Data.ApplicationDbContext --relativeFolderPath Controllers --controllerNamespace WebApplication3.Controllers --referenceScriptLibraries --useDefaultLayout
Finding the generator 'controller'...
Running the generator 'controller'...
Attempting to compile the application in memory
Attempting to figure out the EntityFramework metadata for the model and DbContext: Article
info: Microsoft.Extensions.DependencyInjection.DataProtectionServices[0]
      User profile is available. Using 'C:\Users\Daniel.Garcia\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.
The 'ClientId' option must be provided. StackTrace:There was an error creating the DbContext instance to get the model. No parameterless constructor defined for this object.

   at Microsoft.AspNetCore.Authentication.OAuth.OAuthMiddleware`1..ctor(RequestDelegate next, IDataProtectionProvider dataProtectionProvider, ILoggerFactory loggerFactory, UrlEncoder encoder, IOptions`1 sharedOptions, IOptions`1 options)
No parameterless constructor defined for this object.   at Microsoft.AspNetCore.Authentication.Google.GoogleMiddleware..ctor(RequestDelegate next, IDataProtectionProvider dataProtectionProvider, ILoggerFactory loggerFactory, UrlEncoder encoder, IOptions`1 sharedOptions, IOptions`1 options)

--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Extensions.Internal.ActivatorUtilities.ConstructorMatcher.CreateInstance(IServiceProvider provider)
   at Microsoft.Extensions.Internal.ActivatorUtilities.CreateInstance(IServiceProvider provider, Type instanceType, Object[] parameters)
   at Microsoft.VisualStudio.Web.CodeGeneration.ActionInvoker.<BuildCommandLine>b__6_0()   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.<>c__DisplayClass3_0.<UseMiddleware>b__0(RequestDelegate next)

   at Microsoft.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)   at Microsoft.AspNetCore.Builder.Internal.ApplicationBuilder.Build()

   at Microsoft.VisualStudio.Web.CodeGeneration.CodeGenCommand.Execute(String[] args)   at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()

   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at Microsoft.VisualStudio.Web.CodeGeneration.EntityFrameworkCore.EntityFrameworkServices.TryCreateContextUsingAppCode(Type dbContextType, ModelType startupType)
RunTime 00:00:07.10

It seems to me the environment isn't set as Development when building the app in EntityFrameworkServices.TryCreateContextUsingAppCode. If I update my Startup constructor to always call builder.AddUserSecrets(); regardless of whether the environment is Development or not, then the scaffolding works fine.
//if (env.IsDevelopment())
//{
//    builder.AddUserSecrets();
//}
builder.AddUserSecrets();

Another quick workaround would be setting things up so there are some dummy non-null values that will be overwritten in the dev environment with the values from the user secrets. Just adding some dummy values to appsettings.json or registering the options like this:
    app.UseGoogleAuthentication(new GoogleOptions
    {
        ClientId = Configuration["GoogleClientId"] ?? "MissingClientId",
        ClientSecret = Configuration["GoogleClientSecret"] ?? "MissingClientSecret",
    });

This is fixed in 1.0.0-msbuild2-final and later

Even with 1.0.0-msbuild2-final I still got the issue. @DaniJG solution worked for me.

Thanks for this @DaniJG, had me stumped for a while and all packages up to date


How do you send a message on reconnect?

I need to send a login message when the connection is reestablished.  How do I do this?

You can just use the subscribeHandler

Thank you Lucas for the very quick reply!  Can you give me a quick example of how I do that?  I see hasSubscribeHandler, not sure where I capture events for subscribeHandler.  Please excuse my ignorance.

You can just set the SubscribeHandler as field: https://github.com/recws-org/recws/blob/master/recws.go#L43
Let me know if this does not help - then i will create a quick example for you tomorrow

Should look like this:
&recws.RecConn{
			RecIntvlMax:      10 * time.Minute,
			SubscribeHandler: func() error{ // send your login message here },
			KeepAliveTimeout: 10 * time.Second,
		},

Awesome.  Thank you so much!


[PowerToys] Keyboard Manager lists key mappings that may not be usable on certain keyboards

Addresses PowerToys 12711
cc: @mattwojo

@dedavis6797 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

What is pending here?  @mattwojo

Looks good to me. Auto-assign is broken on this repo currently so just didn't see it earlier.


Help deploy and test hubs decision logic ignore some files

Some changes to deployer/* shouldn't trigger a re-deploy of everything as it currently does via discover_modified_common_files
The issue is that this code currently only checks for matching patterns, and not also considering a few exclusion patterns:
https://github.com/2i2c-org/infrastructure/blob/e8f25c80457aaaab6134d578217d0c2b4145b44f/deployer/commands/generate/helm_upgrade/decision.py#L55-L58
Ideally we'd support something like we have in here:
https://github.com/2i2c-org/infrastructure/blob/e8f25c80457aaaab6134d578217d0c2b4145b44f/.github/workflows/deploy-hubs.yaml#L14-L28

Can't we just put the deployer in it's own repo? I feel like that would solve 99% of the cases when an unwanted full redeploy is triggered.


Determine opam-repository fork user from URI

What's wrong
When running dune-release opam submit, the actual PR creation on opam-repository can fail due to an invalid head field in the API requests. As far as I understand, this appears to happen when the user or organisation owning the package repo differs from the opam-repository fork owner. See #60 for further details.
The actual fix
Since dune-release opam submit knows the opam-repository fork URI, it can be used to determine the owner of the fork and pass it in the github API request instead of the package repository owner.
Notes
This is a first draft, I mostly wanted to have your feedback on the fix.
I wasn't sure whether HTTP URIs should be supported along with SSH ones here but that should be fairly easy to add.
If the parsing of the URI fails it falls back to user.
You'll also note I added some tests in a separate commit.
Let me know what you think!
Thanks

Fixed the CI in #65 !

That looks great, thanks!
A few remarks:

the opam_fork_user variable is a bit confusing: I had to look at the code again to understand how it's different from the already existinguser; so maybe the right fix would be to rename user to something better (maybe distrib_user?) to be able to use user instead of opam_fork_user. What do you think?
The additions of the tests are very welcome, but I would prefer if they use alcotest instead of ounit, if possible. I'll be very happy to add more tests later :-)

I renamed the user and opam_fork_user variables and parameters and switched to alcotest!
I'm an alcotest virgin and because it lacks ounit nesting I'm torn between having a test_case per check and the current implem. I personally feel like it should be the former but without the nesting it doesn't feel so great and it makes the test executable output very verbose so I went for the latter!

Looks great now, thanks!

Also realized dune-release isn't built with dune yet, happy to contribute with the upgrade as well!

That would be great!


Bug report: Cyberchef doesn't decode multiple lines when using Base64 and RC4 combination

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behaviour or a link to the recipe / input used to cause the bug:

Type base64 and drag it into the recipe area
Type rc4 and drag it into the recipe area
Enter RC4 passphrase
It will only decode one at a time
An example is shown below.

Expected behaviour
A clear and concise description of what you expected to happen.
Screenshots
Example 1

Decoded 1

Desktop (if relevant, please complete the following information):

OS: Windows
Browser: Chrome
CyberChef version: Latest

Additional context
Add any other context about the problem here.

Closing this issue. Using the fork recipe makes it work.


[Theme] Variants not appearing as option

Description
Created project with nextjs, and put glueStackProvider around. The build on android  and expo is applying styles without error but on vsCode is appearing errors that the variant doesn't exist.
CodeSandbox/Snack link
No response
Steps to reproduce

Created project with template expo
In _layout.tsx

 <GluestackUIProvider config={extendedConfig}>
      <QueryClientProvider client={queryClient}>
        <Stack>
          <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
        </Stack>
      </QueryClientProvider>
    </GluestackUIProvider>

Edited config.theme

 import { createConfig, config } from '@gluestack-ui/themed';

export const extendedConfig = createConfig({
  ...config.theme,
  components: {
    Button: {
      theme: {
        variants: {
          variant: {
            ghost: {
              bg: '$red500',
            },
          },
        },
      },
    },
  },
});

Tried to call variant

gluestack-ui Version
0.1.10
Platform

[ ] Android
[X] Expo
[ ] iOS
[ ] Next

Other Platform
No response
Additional Information
No response

Hey @JoseCWise ,
Thanks for reporting. We will look into this

Hey @JoseCWise , Thanks for reporting. We will look into this

Hey just a thing i noticed, i think it's a typescript typing problem, when i use javascript it works fine. On the variants on components probably need to add a string typing for custom variants. Not really sure tho

Hey @JoseCWise, We can fixed this issue in our latest version.
Please follow our updated documentation on customizing components.


TACHYON-427 : in existing Spark 1.4.0 it never called the spark.tachy…

TACHYON-427 : in existing Spark 1.4.0 it never called the spark.tachyonStore.url and spark.tachyonStore.baseDir . Instead they are referred as spark.externalBlockStore.url and spark.externalBlockStore.baseDir

Can one of the admins verify this patch?

+1 LGTM

Thanks!


Fixed #4232 App crashes on trying to upload a media from gallery.

Description (required)
Fixes #4232
What changes did you make and why?
As @nicolas-raoul said https://github.com/commons-app/apps-android-commons/issues/4232#issuecomment-779903798 this was due to image with no EXIF.
Fixed by removing Exif and using file functions to get last modified and created time.
Tests performed (required)
3.0.0-debug-master~2695bbaf4 on Nokia 6.1 stock android version 10.

up for review @neslihanturan , @nicolas-raoul , @ashishkumar468

Thanks, @nicolas-raoul
I was heading in the wrong direction.
I've made the requested changes.

When uploading an image without EXIF:

Latest master: crash
This PR: success


[New Feature Request]  Auto Reboot On Upgrade

Again, in the spirit of supporting automated workflows, it would be nice to have an option to kick off a reboot automatically if the firmware gets upgraded.

Anything wrong with:
sudo rpi-update && sudo reboot

Does rpi-update set the error level such that this would not reboot if there were no firmware update?

I just checked:  rpi-update always sets exit code to 0 regardless of whether there was a firmware update or not, so the above solution will ALWAYS reboot.  What I want is reboot only if there has been a firmware update.

Duplicate of https://github.com/Hexxeh/rpi-update/issues/157 ?

Yes, they appear to be essentially identical issues.


Expose animation property for custom progress

Right the animation is hardcoded to "2" secs. Need to make it public.

animate duration made it to public