floh96

floh96

Member Since 2 years ago

@Nix-wie-weg, Bavaria, Germany

Experience Points
1
follower
Lessons Completed
7
follow
Lessons Completed
42
stars
Best Reply Awards
19
repos

71 contributions in the last year

Pinned
⚡ The Microsoft community Windows Package Manager manifest repository
⚡ Download ScriptAnalyzer from PowerShellGallery
⚡ Windows Templates for Packer: Win10, Server 2016, 1709, 1803, 1809, 2019, 1903, 1909, 2004, Insider with Docker
⚡ Chef Infra, a powerful automation platform that transforms infrastructure into code automating how infrastructure is configured, deployed and managed across any environment, at any scale
⚡ Development repository for the apache2 cookbook
⚡ Prevent cloud misconfigurations during build-time for Terraform, Cloudformation, Kubernetes, Serverless framework and other infrastructure-as-code-languages with Checkov by Bridgecrew.
Activity
Jan
23
1 day ago
Jan
22
2 days ago
Activity icon
delete

floh96 in floh96/sitespeed.io delete branch patch-1

deleted time in 1 day ago
Activity icon
issue

floh96 issue comment MicrosoftDocs/PowerShell-Docs

floh96
floh96

SSH Options: Add documentation for the Options parameter in PowerShell remoting over SSH

Documentation Issue

The Options parameter for the PowerShell remoting over SSH will need to be documented. Please see:

Context of the issue

Add an -Options parameter to pass SSH options:

  • Options parameter added to Invoke-Command

  • Options parameter added to Start-PSSession

  • Options parameter added to Enter-PSSession

  • Options parameter added to SSHConnection Hashtable

  • Issue affects the following content (check all that apply):

    Cmdlet reference & about_ topics

    • Version 7.x preview content
    • Version 7.0 content
    • Version 6 content
    • Version 5.1 content

    Conceptual articles

    • Fundamental conceptual articles
    • Script sample articles
    • DSC articles
    • Gallery articles
    • JEA articles
    • WMF articles
    • SDK articles
    • Community articles
  • Is the issue specific to a platform (Y/N - Win/macOS/Linux): N

Detailed description of the issue

The above issue/pull request allows passing OpenSSH options to the Invoke-Command, Start-PSSession, and Enter-PSSession cmdlets. These options should be documented in the docs as well.

Jan
21
3 days ago
Activity icon
issue

floh96 issue comment gitlabhq/terraform-provider-gitlab

floh96
floh96

Support group level CI/CD variable environment scope

Depends on https://github.com/xanzy/go-gitlab/pull/1138. Will remove replace directive from go.mod once released in go-gitlab.

Fixes #610.

The unrelated changes to calls to the client.Users.GetUser method are due to a breaking change in the upstream library.

floh96
floh96
Activity icon
issue

floh96 issue comment gitlabhq/terraform-provider-gitlab

floh96
floh96

Update Changelog for 3.8.0

floh96
floh96

@nicholasklick @nagyv this pr is still needed the changes from version 3.8.0 not in the Changelog yet

Activity icon
issue

floh96 issue comment validator/validator

floh96
floh96

Tag Docker images other than "latest"

It seems that all Docker image builds use the tag latest without having any specific release tags, e.g. 1.0 etc. Good practice suggests that users should ideally use "pinned" versions when pulling Docker images off Docker Hub.

floh96
floh96

@sideshowbarker there are no tags for specific versions in the github registry

Jan
20
4 days ago
Activity icon
issue

floh96 issue comment dependabot/dependabot-core

floh96
floh96

Adding a reviewer to a GitLab merge request is not working

The functionality below, which adds reviewers to a GitLab merge request, does not seem to be working properly.

https://github.com/dependabot/dependabot-core/blob/def2fca85bfe7c25d40569bb43b1d694fde4c89c/common/lib/dependabot/pull_request_creator/gitlab.rb#L156

It is trying to call a URL that does not exist, therefore a 404 is being returned.

Actually the problem seems to be in the GitLab dependency that Dependabot is using. This is the invalid URL: /projects/#{url_encode project}/merge_requests/#{merge_request}/approvers.

floh96
floh96

@andrcuns there was a new release of the gitlab gem. Is it now possible to fix this issue? thanks

Jan
19
5 days ago
push

floh96 push floh96/terraform-provider-gitlab

floh96
floh96

instance_cluster/group_cluster: Suppress whitespace diff for kubernetes_ca_cert (#728)

  • instance_cluster/group_cluster: Suppress whitespace diff for kubernetes_ca_cert

  • Add strings import

floh96
floh96

Added missing scopes to deploy token (#769)

  • added missing scopes to gitlab deploy token

  • removed write_repository, because it is not allowed

Co-authored-by: Johannes Gesenhues [email protected]

floh96
floh96
floh96
floh96

Fix docs for gitlab_project_level_mr_approvals import (#766)

floh96
floh96

Implement configuration of the integration "Microsoft Teams" (#308) (#784)

  • Implement configuration of the integration "Microsoft Teams" (#308)

  • Make use of schema.ImportStatePassthrough

Fixes https://github.com/gitlabhq/terraform-provider-gitlab/pull/784#discussion_r787020662

  • Get rid of obsolete ImportStateIdFunc

Fixes https://github.com/gitlabhq/terraform-provider-gitlab/pull/784#discussion_r787019810

  • Resolve tfproviderlint issue AT002

Fixes https://github.com/gitlabhq/terraform-provider-gitlab/pull/784#discussion_r787017072

  • Align handling of attributes with more of the exiting implementations. Before it mostly was just copy-paste-adapt of the jira service.

  • Remove superfluous attribute title and unify order of attributes in all locations.

Fixes https://github.com/gitlabhq/terraform-provider-gitlab/pull/784#discussion_r787151513

floh96
floh96

closes #778: fix branch_protection documentation (#780)

  • closes #778: fix branch_protection documentation

  • Update branch_protection.md

  • Update branch_protection.md

Co-authored-by: Adam Snyder [email protected]

commit sha: e57bf1d0811218585a496922602d542f4fe17be5

push time in 4 days ago
Activity icon
created branch

floh96 in floh96/terraform-provider-gitlab create branch revert-784-feature/ms_teams

createdAt 4 days ago
Jan
18
6 days ago
Activity icon
issue

floh96 issue comment microsoft/hcsshim

floh96
floh96

WCOW Base layer creation and export

Fixes: #853

Implementation of base-layer export and base-layer creation, intended to support FROM scratch non-bootable flows like #750, or supporting the containerd snapshotter in producing mountable, exportable layers which are not based on an existing MS-provided OCI image, so that the containerd snapshotter test suite can pass without significant changes.

It should work with bootable layers, or at least I've confirmed that passing a nanoserver tarball through these two new features produces something functionally-identical to the original nanoserver tarball.

So in theory, this could be used to "squash" several layers into a new single base layer, but I suspect that's not feasible for anyone except MS due to licensing requirements, and based on my learnings here, MS are clearly using a different tool internally to produce current container images.

Things I don't know, and will ignore unless told-otherwise:

  • Should bcd.bak and related backups be included in the exported tarstream, replacing the modified UtilityVM files they were backups of?
  • What does lack of a UtilityVM in a base layer actually mean?

Minimal base-layer export is working.

My test case for this stage is importing mcr.microsoft.com/windows/nanoserver:10.0.19042.630's base (and only) layer using wclayer import, then exporting it to a tarball and importing that tarball to a new directory.

Current differences/issues

No tests

It doesn't appear we have any wclayer tests, beyond some usage for wclayer.CreateScratchLayer on top of nanoserver or busyboxw, relying on Docker to provide the rest of the stack of images.

Certainly nothing testing import/export.

Files that are not round-tripping correctly: Probably working as intended, one open question.

Importing from my generated tarball ends up with different bcd.bak and bcd.log.bak compared to importing from the MS-built tarball. This is because the BCD in the tree is different after untarring, and the bcd.bak is a copy of the bcd from the original tarball.

❔ It's not clear if the exported tarball should invert the backup step, and redirect the BCD and BCD.LOG to use the bcd.bak and bcd.log.bak (etc) files that were saved during import. (Edit: See mutatedFiles and its usage. However, I don't think this is relevant to this PR anyway, as we're working at a lower layer than this.)

A bunch of other files differ, but they differ every time the same tarball is imported anyway.

And really, since my target here is not bootable images but FROM scratch for e.g., #750 or supporting containerd WCOW snapshots sanely, none of the being-changed files matter to me.

Details of differing files

Comparing a containerd import to the wclayer import from the same (MS-generated tarball), the following files differ:

$ diff -ru ../containerd-data/root/io.containerd.snapshotter.v1.windows/snapshots/1 nanoorig/
Binary files ../containerd-data/root/io.containerd.snapshotter.v1.windows/snapshots/1/blank.vhdx and nanoorig/blank.vhdx differ
Binary files ../containerd-data/root/io.containerd.snapshotter.v1.windows/snapshots/1/blank-base.vhdx and nanoorig/blank-base.vhdx differ
Binary files ../containerd-data/root/io.containerd.snapshotter.v1.windows/snapshots/1/UtilityVM/Files/EFI/Microsoft/Boot/BCD and nanoorig/UtilityVM/Files/EFI/Microsoft/Boot/BCD differ
Binary files ../containerd-data/root/io.containerd.snapshotter.v1.windows/snapshots/1/UtilityVM/Files/EFI/Microsoft/Boot/BCD.LOG and nanoorig/UtilityVM/Files/EFI/Microsoft/Boot/BCD.LOG differ
Binary files ../containerd-data/root/io.containerd.snapshotter.v1.windows/snapshots/1/UtilityVM/SystemTemplate.vhdx and nanoorig/UtilityVM/SystemTemplate.vhdx differ
Binary files ../containerd-data/root/io.containerd.snapshotter.v1.windows/snapshots/1/UtilityVM/SystemTemplateBase.vhdx and nanoorig/UtilityVM/SystemTemplateBase.vhdx differ

We know that the BCD files are modified by the import process, and the rest are presumably generated on-the-fly and end up with timestamps inside them or something.

Comparing the wclayer import of the original tarball to the wclayer import of the tarball I generated with wclayer export, the following files differ:

Binary files nanoorig/bcd.bak and newnano/bcd.bak differ
Binary files nanoorig/bcd.log.bak and newnano/bcd.log.bak differ
Binary files nanoorig/blank.vhdx and newnano/blank.vhdx differ
Binary files nanoorig/blank-base.vhdx and newnano/blank-base.vhdx differ
Binary files nanoorig/UtilityVM/Files/EFI/Microsoft/Boot/BCD and newnano/UtilityVM/Files/EFI/Microsoft/Boot/BCD differ
Binary files nanoorig/UtilityVM/Files/EFI/Microsoft/Boot/BCD.LOG and newnano/UtilityVM/Files/EFI/Microsoft/Boot/BCD.LOG differ
Binary files nanoorig/UtilityVM/SystemTemplate.vhdx and newnano/UtilityVM/SystemTemplate.vhdx differ
Binary files nanoorig/UtilityVM/SystemTemplateBase.vhdx and newnano/UtilityVM/SystemTemplateBase.vhdx differ

And nailing down what all the BCD files are

$ sha256sum */bcd.bak */UtilityVM/Files/EFI/Microsoft/Boot/BCD
71b8db95fdc7339e00bc6ac87505d5cf21987fcdd171184a88e91836a884a83b *nanoorig/bcd.bak
6d6597ec802a43cb9b53b3bddb2e6eccd806abc2871cbb454495a3e38a087227 *newnano/bcd.bak
6d6597ec802a43cb9b53b3bddb2e6eccd806abc2871cbb454495a3e38a087227 *newnano2/bcd.bak
6d6597ec802a43cb9b53b3bddb2e6eccd806abc2871cbb454495a3e38a087227 *nanoorig/UtilityVM/Files/EFI/Microsoft/Boot/BCD
3546633c9b234e14b30fc06b24fd0757a474b36771382764db7db9f6a0de3a7e *newnano/UtilityVM/Files/EFI/Microsoft/Boot/BCD
f084cc86c3b06a96e497d354003b0436a6210b4412c26cf65f5bff3d262b6764 *newnano2/UtilityVM/Files/EFI/Microsoft/Boot/BCD

We can see that the bcd.bak that comes from importing my generated tarball is the BCD from the from-MS imported Utility VM; bcd.bak in the from-MS import is presumably the BCD that's actually inside the tarball.

This is an oddity of ociwriter.ImportLayer. It backs up BCD and BCD.LOG*, but doesn't do anything with those backups, they are not referenced anywhere else in the hcsshim code base. I'm not sure if the intent was to copy them back after importing, or if they are supposed to be included in the export (i.e. invert the backup process).

File order is different: Only annoying when doing comparisons of the tar tv output.

I don't know what tool is being used to create the files published by MS, but clearly it's not filepath.Walk in Go, as they disagree about the ordering of case. I suspect the most-important thing here is that Files comes before UtilityVM. Order of processing files will affect hard-links in the tarball, but only cosmetically.

Hard links: Works for base layers, but not non-base layers (but the latter is unrelated to this PR).

Resolved, for this use-case. The layer export code now recognises hard-links on the filesystem, and adds them to the tar stream. The algorithm roughly matches the one given at the OCI Image Spec "Image Layer Filesystem Changeset" notes on hard-links.

The hard-links present in the nanoserver image are also present if that layer is reexported, but:

  • FIle order means a different file might be "the file" in the tarball, because the data is recorded against the first-seen name.
  • Somehow the nanoserver tarball from mcr contains hardlinks with different modtimes to their targets (observed in links from UtilityVM/Files/ to Files/). That information is lost when importing the layer (those details are a factor of the single file, not the multiple directory entries linking to it) so that's not possible to replicate. Nor desirable, I think. I'm not sure how that is possible in the first place, short of stale directory entries on the source system when creating the tarball.

In testing, I noticed that hard-links that exist in a non-base layer do not appear as hard-links when exporting, because modvmcompute.NewProc("ExportLayer") does not preserve hard links when copying the layer data into a temporary directory. It does not create BACKUP_LINK streams, and even if it did, go-winio's backuptar doesn't handle them anyway. It's not obvious if the BACKUP_LINK data format is well-defined but not documented, or is supposed to be application-defined, in which case the content would have to be part of ExportLayer's API and somehow make sense both intra-layer and inter-layer.

I also found that New-Item -ItemType HardLink didn't work to create cross-layer links (which makes sense, since I assume it wants to change the 'link count' on a file in a read-only layer), so I suspect that at this time, hcsshim will never export hard-links except when exporting a base layer (i.e. this new code). Maybe this used to work, since the code exists to handle both inter-layer and intra-layer hard links in tarballs during import.

Hard-link support also pulls in a fairly noisy Microsoft/go-winio bump which will resolvably conflict with #941, and since I was running go mod tidy as a matter of course, I think I inlined #942 in passing. If the latter lands first, this'll be less noisy, but the go-winio bump will still generate noise in both modules because it has bumped golang.org/x/sys quite a long way, which flows through into the vendor directory. (This was broken out into separate PRs)

Notes from before this was implemented

The tarball from MS for nanoserver's base layer includes lots of hardlinks, some between entries in Files, but most are from the UtilityVM/Files back to Files/. Not capturing these hard links when exporting the layer takes an uncompressed nanoserver base layer from about 280MB to about 430MB.

This one's a little intricate. winio.NewBackupFileReader doesn't generate winio.BackupLink, that's up to the code walking the tree, and I haven't yet worked out how, from Go, to actually identify that a file is a HardLink, which PowerShell can tell me, and track down the other links, which fsutil hardlinks can tell me. So the data's there, but the API has escaped my minimal searching. I am guessing I want BY_HANDLE_FILE_INFORMATION to tell me when something has hard-links, and match them by file index.

Dagnabbit: Go's os.File.Stat actually fetches exactly this structure, but doesn't grab the number of links, and the index values are not exported. So we'll be making syscalls of our own to achieve this. os.SameFile uses the indexes, but I can't see a good way to apply that here.

Also, github.com/Microsoft/go-winio/backuptar.WriteTarFileFromBackupStream doesn't handle winio.BackupLink anyway. So that would have to be implemented too, or intercept the call to backuptar.WriteTarFileFromBackupStream in ociwclayer.writeTarFromLayer like we do for deleted files. That's probably necessary anyway, as per the MS docs, the actual data in the winio.BackupLink object is up to the application. It would also mirror ociwclayer.writeLayerFromTar which similarly intercepts the call to writeBackupStreamFromTarAndSaveMutatedFiles for tar.TypeLink headers.

I did a quick test of just tarballing-up the tree using Windows-bundled tar, and it did find hardlinks correctly, although it disagreed about which one in the tarball was the "original", not that it matters. It also failed to include UtilityVM but did include UtilityVM\Files, but that could probably be fixed with a better command-line and more than the zero effort I put into this test:

tar cf simplenano.tar -C .\nanoorig Files UtilityVM\Files
No permission bits on the exported tarballs: This was already the case for the non-base layers.

backuptar.WriteTarFileFromBackupStream just doesn't have any way to set the permission bits on the tar headers it creates. I considered making it automatically apply 0644 for files and 0755 for directories to match the MS-generated tarballs, but (a) that's way over in go-winio, and is separate to this; and (b) I'm only 80% sure that won't invalidate every Windows Containers build-cache on the planet, and I don't think 20% is low-enough to risk having to change my name and go into hiding before an angry mob of CI/CD engineers comes looking for me.

Weirdly, the MS-built tarball doesn't have permission bits on the Files, UtilityVM, or UtilityVM/Files directories, which suggests that whatever is done to generate these tarballs, it's doing something fairly specialised and a bit unusual. And also suggests this isn't important.

Punted to https://github.com/microsoft/go-winio/issues/184 for discussion/feedback.


Creating a base layer from some files on-disk is working.

This introduces a new API, hcsshim.ConvertToBaseLayer:

  • If any of the below files are missing, create them as empty files so hcsshim.ProcessBaseLayer will complete:
    • Files/Windows/System32/config/DEFAULT
    • Files/Windows/System32/config/SAM
    • Files/Windows/System32/config/SECURITY
    • Files/Windows/System32/config/SOFTWARE
    • Files/Windows/System32/config/SYSTEM
  • Checks that if UtilityVM/Files exists, it contains UtilityVM/Files/EFI/Microsoft/Boot/BCD so that hcschim.ProcessUtilityVMImage will complete (assuming the BCD is valid).
  • Runs ProcessBaseLayer and if necessary, ProcessUtilityVMImage
    • Basically, this is the part of (w *baseLayerWriter) Close() after reapplyDirectoryTimes.

I'm not sure when a UtilityVM is necessary. At the moment, I'm assuming it's only needed if the layer is used as the base of a container's scratch layer, and that's not the target use-case for this work.

As it happens, the test TestSCSIAddRemoveWCOW is a passable candidate for exercising this API and particularly the use-case I'm targeting, as it creates scratch layers for attaching to a container as SCSI disks. Before this change, those scratch layers are based on the image used to create the container in the first place, i.e. nanoserver. With this API, it is much more similar to TestSCSIAddRemoveLCOW which uses trivial empty EXT4 scratch layers.

All of the above could be handled by the hcsshim user, e.g., this was done (but never merged) by refactoring the containerd snapshot testsuite in https://github.com/containerd/containerd/pull/2366 to use hcsshim.ProcessBaseLayer and fstest.Base, including defining fstest.Base in containerd/continuity in order to record an undocumented internal hcsshim requirement.

I propose instead to make containerd's snapshot Commit API call hcsshim.ConvertToBaseLayer at the appropriate point so that to callers of the snapshot system, no behaviour difference is seen between Windows and non-Windows behaviours.

My fallback is to take all the code I wrote here, and add it to containerd instead, which of course means no one else benefits, and the knowledge needed to call hcsshim.Process* remains buried over in some non-hcsshim project.

Current differences/issues

Test-case TODO question

testutilities.CreateWCOWBlankRWLayer has a TODO:

// TODO: This is wrong. Need to search the folders.

It appears that it intends to search the provided layers to find one with a UtilityVM folder, but it's not clear why, as its current use-case is for scratch layers attached as SCSI devices via the Utility VM, which does not, as far as I can see, require a Utility VM.

It's a TODO here because before this change, the top layer has a Utility VM, but with this change, it does not.

The test passes so I think I'm okay, but it's possible there's a downlevel issue, as I'm testing on Windows 10 20H2.

cd tests
go test -v -tags "uvmscsi" -run TestSCSIAddRemoveWCOW  ./...

There is no step 3

Well, there is, but not here. Assuming that this work is completed and merged, I need to revendor into containerd, and rebase my work there (see https://github.com/containerd/containerd/pull/4415#discussion_r532221174) to take advantage of this new API, and hopefully get the snapshot integration test suite to start passing, which creates arbitrary base layers in every test.

Activity icon
issue

floh96 issue comment ogham/exa

floh96
floh96

Initial support for Windows

Supports #32

floh96
floh96

@ogham friendly ping could this pr get a review?

Jan
16
1 week ago
started
started time in 1 week ago
started
started time in 1 week ago
Jan
15
1 week ago
pull request

floh96 pull request sitespeedio/sitespeed.io

floh96
floh96

Fix Gitlab link

Your checklist for a pull request to sitespeed.io

Please review the guidelines for contributing to this repository.

  • I'm making a big change or adding functionality so I've already opened an issue proposing the change to other contributors, so I got feedback on the idea before took the time to write precious code
  • Check that your change/fix has corresponding unit tests (if applicable)
  • Squash commits so it looks sane
  • Update the documentation https://github.com/sitespeedio/sitespeed.io/tree/main/docs in another PR
  • Verify that the test works by running npm test and test linting by npm run lint

Description

Fixes the link to gitlab.

Thank you for making sitespeed.io even better!

Activity icon
fork

floh96 forked sitespeedio/sitespeed.io

⚡ Sitespeed.io is an open source tool that helps you monitor, analyze and optimize your website speed and performance, based on performance best practices advices from the coach and collecting browser metrics using the Navigation Timing API, User Timings and Visual Metrics (FirstVisualChange, SpeedIndex & LastVisualChange).
floh96 MIT License Updated
fork time in 1 week ago
Jan
14
1 week ago
Activity icon
issue

floh96 issue comment PowerShell/PowerShell

floh96
floh96

Add lock and null check to remoting internals (#16542)

PR Summary

Lock and null check of the PrioritySendDataCollection.cs members to avoid race condition.

PR Context

Copy-Item cmdlet can throw unhandled exception that terminates the process. The issue occures in WSManTransportManager internals. The PrioritySendDataCollection class is used by 2 threads: first thread calls ReadOrRegisterCallback method, that gets _dataToBeSent field, when second thread calls Clear method, where _dataToBeSent member is disposed.

PR Checklist

floh96
floh96

@PaulHigin this was merged without the cla signed

Jan
4
2 weeks ago
Activity icon
issue

floh96 issue comment microsoft/terminal

floh96
floh96

Updates to Terminal repo milestones, 2022 edition

The Terminal repo right now consists of a collection of various different "milestones" that have evolved organically over the years. We've got Console milestones, we've got Terminal milestones, we have milestones that vaguely align with OS releases, and then we've got like, four different milestones that are all the "backlog" in one way or another ("Console Backlog", "Terminal Backlog", "Windows vNext", and "Icebox"). All together, they don't create a very clear picture of what's going on in the Terminal land. To try and clear this up, we're going to de-duplicate some of these, and try something new for 2022.

  • The "Console Backlog" and the "Terminal Backlog" are both getting deprecated. They'll be collectively replaced with just a unified "Backlog" milestone, which will track things we'd like to get to, but we don't have any time planned for.
  • "Windows vNext" is also being deprecated. Originally, it was a rolling milestone to track things that should be in "the next version of Windows". Unfortunately, it wasn't tracked super well, so it's effectively become a second Console Backlog.
  • We're going to use four milestones for tracking bits of the next year of planning. These are separated into two "release" milestones, and two "semester" milestones.
    • "Terminal v1.{n}" (as of when this was written, this is v1.13): Shots we're calling for the upcoming release. Features & tasks we expect to land, blocking bugfixes, or other high-pri fixes
    • "Terminal v1.{n+1}" (currently, v1.14): Same as above, for the following release. With two 6-week release milestones, this is about 3 months of planning. This is a useful buffer for "we really should do this SOON, but not ASAP.
    • "22H1" will represent the first 6 months of 2022. This will help align internally with the OS release cadence.
      • If there are conhost bugs that need to get fixed in the upcoming release of Windows, then they go here.
      • Accessibility bugs will also go here, or into the current semester.
    • "22H2" is the same idea. A planning buffer for the second half of 2022. This includes Terminal features we expect to land in the second half.
      • Terminal P2+ bugs will go here.
  • Terminal v2, Console Backlog, Terminal Backlog, Windows vNext are all going to be emptied into "22H1", "22H2", and the "Backlog", based on current priority labels.
  • We're also going to rename "Terminal v3" to Up Next". This is for features, we think are highest on the backlog. The next big set of features we want to work on. Things that should be at the top of our list to fill up the upcoming semester.
  • We're leaving the ""Icebox" as-is right now, albeit, possibly workshopping the name in the near future. This will remain for features that we think are cool, valid feature requests for the Console&Terminal. However, we'll admit we're never going get to these features. We'd likely accept PRs from the community for things in here.
  • We had a really successful "Engineering Improvements" milestone over the last few weeks, so we'll probably try that again next year. At the end of each year, I'll just move the closed issues in the EIM milestone to a specific "Engineering Improvements {current_year}" milestone.

We're intentionally not planning out more specifically that 1.n and 1.n+1 - we're generally a fairly responsive team, where priorities can shift quickly during the course of the year. Trying to lick cookies for specific milestones more than 3 months out has generally been an exercise in futility.

As always, as priorities shift, and resourcing changes, issues can move between these milestones fluidly.

Hopefully, by grouping bugs into semester-sized milestones, we can address some of them in a timelier fashion. Currently, they just get stuck into "Terminal v2", which we've been pulling features and tasks into as well, which has only created a longer bug backlog 😄.

I'll be going through and moving our issues into this new structure likely sometime early in 2022.

If this doesn't end up working, we'll take our learnings and try something else for 2023 😄

Dec
28
3 weeks ago
Activity icon
delete

floh96 in floh96/winget-cli delete branch patch-1

deleted time in 3 weeks ago
Dec
27
4 weeks ago
pull request

floh96 pull request microsoft/winget-cli

floh96
floh96

Fix Typo in upgrade.md


Activity icon
fork

floh96 forked microsoft/winget-cli

⚡ Windows Package Manager CLI (aka winget)
floh96 MIT License Updated
fork time in 3 weeks ago
Dec
22
1 month ago
Activity icon
issue

floh96 issue tarecord/sign-in-with-google

floh96
floh96

release request

@tarecord could you publish a new release with #73 included? thanks

Dec
21
1 month ago
started
started time in 1 month ago
Dec
20
1 month ago
Activity icon
issue

floh96 issue comment microsoft/terminal

floh96
floh96

After upgrade to 1.12.3472.0 startingDirectory with forward slashes does not work for WSL any more

Windows Terminal version

1.12.3472.0

Windows build number

10.0.19043.0

Other Software

I have both WSL2 and WSL1 with Ubuntu 20.04 images. For both of them after Windows Terminal upgraded form 1.11 preview to 1.12 preview my session starts in the Ubuntu's root directory instead of the directory set in the Terminal's profile:

            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "//wsl$/Ubuntu/home/vbrozik/"
            },
            {
                "guid": "{07b52e3e-de2c-5db4-bd2d-ba144ed6c273}",
                "hidden": false,
                "name": "Ubuntu-20.04",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "//wsl$/Ubuntu-20.04/home/vbrozik/"
            },

The directories exist:

PS C:\Users\vaclav.brozik> cd //wsl$/Ubuntu/home/vbrozik/
PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu\home\vbrozik> cd //wsl$/Ubuntu-20.04/home/vbrozik/
PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu-20.04\home\vbrozik>

The same bug is in the wsl utility itself as I noticed that the --cd switch fails to process the path with forward slashes while backslashes work fine:

PS C:\Users\vaclav.brozik> wsl --cd //wsl$/Ubuntu/home/vbrozik/
[email protected]:/$ pwd
/
[email protected]:/$ logout
PS C:\Users\vaclav.brozik> wsl --cd \\wsl$\Ubuntu\home\vbrozik\
[email protected]:~$ pwd
/home/vbrozik

So if Windows Terminal uses this buggy functionality of the wsl tool the bug propagates to Windows Terminal.

Workaround

After I replaced the slashes with backslashes everything works as expected:

            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "\\\\wsl$\\Ubuntu\\home\\vbrozik\\"
            },
            {
                "guid": "{07b52e3e-de2c-5db4-bd2d-ba144ed6c273}",
                "hidden": false,
                "name": "Ubuntu-20.04",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "\\\\wsl$\\Ubuntu-20.04\\home\\vbrozik\\"
            },

Steps to reproduce

Use forward slashes in the startingDirectory property of a WSL profile in Windows Terminal - for example //wsl$/Ubuntu/home/username/.

Expected Behavior

The interactive shell running in WSL should have the working directory as configured in the startingDirectory property.

Actual Behavior

The interactive shell running in WSL has the root directory as the working directory.

Dec
17
1 month ago
Activity icon
fork

floh96 forked chocolatey/boxstarter

⚡ Repeatable, reboot resilient windows environment installations made easy using Chocolatey packages
floh96 Apache License 2.0 Updated
fork time in 1 month ago
Dec
15
1 month ago
Activity icon
issue

floh96 issue comment MicrosoftDocs/terminal

floh96
floh96

Adding oh-my-posh to new-tab-same-directory.md

floh96
floh96

@xuwaters you don't need to change your profile like that with oh-my-posh. oh-my-posh supports emitting OSC9;9; it is just disabled by default because it is triggering a notification in iterm2.... you can enable it in your prompt settings see https://ohmyposh.dev/docs/config-overview#general-settings

Activity icon
issue

floh96 issue MicrosoftDocs/terminal

floh96
floh96

Gifs are not rendered

The gifs at the bottom are not rendered


Document Details

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

Dec
10
1 month ago
Activity icon
issue

floh96 issue dfinke/Tiny-PowerShell-Projects

floh96
floh96

Dockerfile broken

The following command in the Dockerfile is failing https://github.com/dfinke/Tiny-PowerShell-Projects/blob/master/Dockerfile#L64 Log from Binder:

Step 19/24 : RUN dotnet tool install -g Microsoft.dotnet-interactive --version 1.0.140401 --add-source "https://dotnet.myget.org/F/dotnet-try/api/v3/index.json"
 ---> [Warning] Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
 ---> Running in cddd4eabb666
/usr/share/dotnet/sdk/3.1.301/NuGet.targets(128,5): error : Unable to load the service index for source https://dotnet.myget.org/F/dotnet-try/api/v3/index.json. [/tmp/g1pulogo.tty/restore.csproj]
/usr/share/dotnet/sdk/3.1.301/NuGet.targets(128,5): error :   The SSL connection could not be established, see inner exception. [/tmp/g1pulogo.tty/restore.csproj]
/usr/share/dotnet/sdk/3.1.301/NuGet.targets(128,5): error :   The remote certificate is invalid according to the validation procedure. [/tmp/g1pulogo.tty/restore.csproj]
The tool package could not be restored.
Tool 'microsoft.dotnet-interactive' failed to install. This failure may have been caused by:

* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.

For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
Removing intermediate container cddd4eabb666
The command '/bin/bash -o pipefail -c dotnet tool install -g Microsoft.dotnet-interactive --version 1.0.140401 --add-source "https://dotnet.myget.org/F/dotnet-try/api/v3/index.json"' returned a non-zero code: 1Built image, launching...
Failed to connect to event stream
Previous