gem_package behaves like chef_gem after chef installs system ruby

I expect that this recipe when run for the first time will install the json gem to /usr/bin/gem:
package 'rubygems' do
  action :install
end

gem_package 'json' do
  action :install
  gem_binary '/usr/bin/gem'
end

gem_package 'thor' do
  action :install
  gem_binary '/usr/bin/gem'
end

execute "/usr/bin/gem list |grep thor"
execute "/usr/bin/gem list |grep json"

thor is installed to /usr/bin/gem but json is not.  This is for chef 12.3.0 in test kitchen.
The json gem is not installed because of this message:
  * gem_package[json] action install[2015-05-11T22:07:19+00:00] INFO: Processing gem_package[json] action install (repo::default line 16)
 (up to date)
  * gem_package[thor] action install[2015-05-11T22:07:24+00:00] INFO: Processing gem_package[thor] action install (repo::default line 21)
[2015-05-11T22:07:30+00:00] INFO: gem_package[thor] installed thor at 0.19.1

Testing with chef 11.16.4 the recipe runs all the way though without issue.
* gem_package[json] action install[2015-05-11T22:10:59+00:00] INFO: Processing gem_package[json] action install (repo::default line 16)
- install version 1.8.2 of package json

You most likely need to use action :upgrade.  The json gem is a default gem in ruby:
# gem uninstall json
ERROR:  While executing gem ... (Gem::InstallError)
    gem "json" cannot be uninstalled because it is a default gem

If you try to :install it then it will find it and won't install it.
If you try to :upgrade it then it'll download the latest if its available:
Recipe: (chef-apply cookbook)::(chef-apply recipe)
  * gem_package[json] action upgrade
    - upgrade package json from 1.8.1 to 1.8.2

I suspect between 11.16.4 and 12.3.0 that we may have fixed this.

That seemed to work, but I'm not sure that it is the full/correct solution.
The json gem is installed in /opt/embedded/chef. But is not installed for /usr/bin/gem. Should the fact that  a gem is installed in one path affect if it is installed in a different one?  Especially with the difference between chef_gem and gem_package.
I'm now fixed, but it is possible that this is a bigger problem.

What does this do before you run chef on the box?  And what version of ruby are you running?
% /usr/bin/irb
2.1.5 :001 > require 'json'

If I converge the image without installing ruby gems:
$ /usr/bin/irb
-bash: /usr/bin/irb: No such file or directory

At the same point
$ /opt/chef/embedded/bin/irb
irb(main):001:0> require 'json'
=> true

after installing rubygems
$ /usr/bin/irb
irb(main):001:0> require 'json'
LoadError: no such file to load -- json

the chef embedded hasn't changed.
This is what the gem list for the ubuntu installation of rubygems gives you:
$ /usr/bin/gem list

*** LOCAL GEMS ***

I then add this block to the run:
gem_package 'json' do
  action :install
  gem_binary '/usr/bin/gem'
end

And json is not installed because:
  * gem_package[json] action install[2015-05-13T15:38:15+00:00] INFO: Processing gem_package[json] action install (repo::default line 16)
 (up to date)

$ /usr/bin/gem list

*** LOCAL GEMS ***

But when following the same pattern with a different gem
Before:
$ /opt/chef/embedded/bin/irb
irb(main):001:0> require 'thor'
LoadError: cannot load such file -- thor

The block:
gem_package 'thor' do
  action :install
  gem_binary '/usr/bin/gem'
end

After:
$ /usr/bin/gem list

*** LOCAL GEMS ***
thor (0.19.1)

Why does a gem being installed in /opt/chef/embedded/ matter to if a gem should be installed to a different gem location.  Particularly when the gem_binary is explicitly set.
More than that, any gem that is installed in /opt/chef/embedded/ acts the same way.
Before:
$ /opt/chef/embedded/bin/irb
irb(main):001:0> require 'pry'
=> true

$ /usr/bin/irb
irb(main):001:0> require 'pry'
LoadError: no such file to load -- pry

this block gets ran:
gem_package 'pry' do
  action :install
  gem_binary '/usr/bin/gem'
end

and the require 'pry' for /usr/bin/irb fails the same way.

okay, i think i'm parsing what your problem is at least.  and your version of /usr/bin/ruby is sufficiently old that the json gem hasn't been integrated into ruby yet?
what happens if you leave "gem_binary" off of the gem_package resource?

I tried to replicate this with chef 12.3.0 and the 'highline' gem as my installed-in-embedded-but-not-in-system gem and its working for me.  Both with and without the 'gem_package' resource.  The fact that its installed in embedded doesn't affect it being installed into the system gems.

There is a known bug where gem_package will behave like chef_gem if there is no system gem, so if you've got an ordering issue and you're doing a gem_package before you've installed ruby+rubygems on the system then it'll behave this way.  Other than that my suspicion is some kind of pathology around the system ruby or rubygems being very old?

By the way, thank you so much for all your help.  It feels like we're quite close to getting it solved.
The repo recipe above is getting ruby installed by doing the package installation of rubygems.  It seems like maybe the issue is related to GEM_HOME or other ruby path/environment variables.
To be honest we don't care too much about solving the particular recipe above.  We'd be perfectly happy with any way to:

install ruby in a recipe
install json (and other gems)
use that ruby and gems in some scripts

Is there a recommended/supported way of installing the system ruby?  I assume that's the place we're falling down currently.  Poise-ruby looks like it is the recommended solution.  We're using ubuntu 12.04 and ubuntu 14.04

Yeah it might be that we're caching information somewhere in a chef_gem or gem_package call which is done prior to your installation of the system ruby.  Then after you've installed the system ruby the rubygems caching in the provider is still hanging around and chef still 'thinks' that the embedded ruby is the only ruby on the system.  Then you're hitting that issue where gem_package falls back to chef_gem behavior if there's no ruby on the system even though you've installed it.  This is very plausible because there's both a lot of caching of information in gem_package and there's that known issue.
So, one simple test is if you've manually installed the system ruby before running chef-client does that fix its behavior and the gem_package correctly installs into the system?
And best practices are all over the place.  If you don't want to spend the time compiling ruby, I'd just install the packages you need directly via the package resource and avoid any cookbooks out there.  If you want to have an upgraded ruby on the system and/or manage multiple ones I'd suggest the rbenv or chruby cookbooks (rbenv is a bit heavier than chruby, but the rbenv cookbook seems to be getting more maintenance than the chruby cookbook -- although if the chruby one works the both chruby and its cookbook may be simplest solution overall).

Did you ever determine if manually installing the system ruby before running chef-client fixed the behavior (and therefore points at some caching going on?)

There are two things that we could possibly do to fix this:

make gem_package raise if there's no system ruby, instead of behaving like chef_gem
track down whatever internal state is getting cached that doesn't notice the system ruby getting installed

We are also seeing this same issue when trying to install a gem to the system ruby.  The gem (io-console) exists in chef embedded and therefore it is not being installed to the system ruby.
gem_package "io-console" do
  gem_binary "/usr/bin/gem"
end

Chef-client debug reports that the gem already exists:
[2015-09-02T10:01:02-05:00] DEBUG: gem_package[io-console] using gem '/usr/bin/gem'
[2015-09-02T10:01:02-05:00] DEBUG: gem_package[io-console] found installed gem io-console version 0.4.3 matching io-console (>= 0)
[2015-09-02T10:01:02-05:00] DEBUG:  found gem io-console version 0.4.2 for platform ruby from #Gem::Source:0x0000000682fb30
[2015-09-02T10:01:02-05:00] DEBUG: gem_package[io-console] io-console 0.4.3 already installed
[2015-09-02T10:01:02-05:00] DEBUG: gem_package[io-console] is already installed - nothing to do
(up to date)
When we bootstrap our systems, the first thing that we do is install ruby and rubygems to the system.  After that we grab the embedded chef package and install that.
Here are the system ruby and rubygems versions:
[root@ip-10-0-- ~]# /usr/bin/ruby -v
ruby 2.0.0p645 (2015-04-13) [x86_64-linux]
[root@ip-10-0-- ~]# /usr/bin/gem -v
2.4.8
Our chef-client version is:
Chef: 12.4.1

So we still need to know if you've already installed the ruby+rubygems to the system before the chef-client run, does it work?

When we bootstrap our systems, the first thing that we do is install ruby+rubygems to the system. After that we grab the embedded chef package and install that.
We are running on Amazon Linux (2014.09) and we run the following as the first line in our bootstrap process:
yum install -q -y ruby ruby-devel gcc gcc-c++ automake autoconf rubygems make
Then we install chef and run chef-client for the first time.

Okay that's useful to know.  Does it work if you leave off the gem_binary flag to the gem_package provider or not?  (You shouldn't need to do that).

I removed gem_binary flag and it still behaves the same.

Well, that's a substantially worse bug, but I also can't seem to replicate it.

ahhh, do you have /opt/chef/embedded/bin and/or /opt/chef/bin in your $PATH?

(or the chefdk versions if you're pulling chef-client out of chefdk)

My path appears to be correct.  My installation is in /opt/chef/embedded but it does not show up in the path.
[root@ip-10-0-- ~]# echo $PATH
/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/aws/bin:/root/bin
Is there any other debugging that I can do on my end for you?  I'm not too familiar with the source code but is there a spot that you could have me edit to spit out what the current path is when running gem_package?

I think you can just:
ruby_block do
  block do
    puts ENV['PATH']
  end
end

put that right before the gem_package resource.

@lamont-granquist Here is the output from running that.  My system version of "gem" exists in /usr/bin and that path is being hit before /opt/chef/embedded/bin
[2015-09-02T13:50:04-05:00] DEBUG: Providers for generic ruby_block resource enabled on node include: [Chef::Provider::RubyBlock]
[2015-09-02T13:50:04-05:00] DEBUG: Provider for action run on resource ruby_block[output_path] is Chef::Provider::RubyBlock
/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/aws/bin:/root/bin:/opt/chef/embedded/bin:/opt/chef/embedded/bin
[2015-09-02T13:50:04-05:00] INFO: ruby_block[output_path] called

Yeah I think chef-client adds those to the end of the PATH.  I can only replicate this behavior though if I add those to the start of the PATH.

@lamont-granquist
Trying to run through the code and figure out what is going on.  I noticed that "new_version_array" property in lib/chef/provider/package.rb contains ["0.4.3"] on my machine and this is the version of io-console installed in /opt/chef/embedded, but the version that would install with a /usr/bin/gem install io-console is version 0.4.2.
What system version of Ruby are you using to try to reproduce?

@dcampano @lamont-granquist I'm also running into the on OEL6.5.
ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux]
gem -v 1.3.7

I am experiencing the same behavior:
  %w{ json bigdecimal mysql2 }.each do |pkg|
    gem_package pkg do
      gem_binary '/usr/bin/gem'
      action :install
    end
  end

Before I run chef-client:
[root@mmbr ~]# gem list | grep -E 'mysql2|json|bigdecimal'
json (1.5.5)
[root@mmbr ~]# /opt/chef/embedded/bin/gem list | grep -E 'mysql2|json|bigdecimal'
bigdecimal (1.2.4)
json (1.8.3, 1.8.1)
multi_json (1.11.2)

Chef is run and reports:
  * gem_package[json] action install (up to date)
  * gem_package[bigdecimal] action install (up to date)
  * gem_package[mysql2] action install
    - install version 0.4.4 of package mysql2

Afterward:
[root@mmbr ~]# gem list | grep -E 'mysql2|json|bigdecimal'
json (1.5.5)
mysql2 (0.4.4)
[root@mmbr ~]# /opt/chef/embedded/bin/gem list | grep -E 'mysql2|json|bigdecimal'
bigdecimal (1.2.4)
json (1.8.3, 1.8.1)
multi_json (1.11.2)

And the reason why I need it to exist in the system gems:
# ./apiuser.rb
/usr/share/rubygems/rubygems/custom_require.rb:36:in `require': cannot load such file -- bigdecimal (LoadError)
	from /usr/share/rubygems/rubygems/custom_require.rb:36:in `require'
	from /usr/local/share/gems/gems/mysql2-0.4.4/lib/mysql2.rb:3:in `<top (required)>'
	from /usr/share/rubygems/rubygems/custom_require.rb:60:in `require'
	from /usr/share/rubygems/rubygems/custom_require.rb:60:in `rescue in require'
	from /usr/share/rubygems/rubygems/custom_require.rb:35:in `require'
	from /etc/monitor/scan.d/apiuser/lib/mysql2json.rb:1:in `<top (required)>'
	from ./apiuser.rb:2:in `require_relative'
	from ./apiuser.rb:2:in `<main>'

These systems are CentOS 6.6 in AWS w/ chef 12.6.0 client.  Prior to this code snippet, there is a mysql recipe which does some chef_gem magic.  That is probably where the chef embedded gem set is getting cached?  Is there any way to clear it?
For the time being I am just doing it manually:
  %w{ json bigdecimal mysql2 }.each do |pkg|
    # Chef bug 3363: gem_package acts like chef_gem after previous runs
    #gem_package pkg do
    #  gem_binary '/usr/bin/gem'
    #  action :install
    #end

    execute "Install gem #{pkg}" do
      command "/usr/bin/gem install #{pkg}"
      only_if  "[ -z $(/usr/bin/gem list | grep -E '^#{pkg} ') ]"
    end
  end

I've ran into this issue as well.  running chef clients 12.5 and 12.12.15 on OEL 6.6 and 6.7.  It might be worth noting that I do not have this issue with CentOS 7.2 (chef-client 12.12.15).

I'm seeing this issue as well. It appears to be something to do with amazon linux. When I ran the same recipe on RHEL7, it works. To add more confusion, its not all gems. For example, this code
gem_package 'bundler' gem_package 'io-console'
Against this list of gems:
`gem list --local
*** LOCAL GEMS ***
bigdecimal (1.2.0)
json (1.8.3)
psych (2.0.0)
rdoc (4.2.2)
`
Does this:
`[2017-01-18T18:20:29+00:00] INFO: Processing gem_package[bundler] action install (newrelic_plugins::aws_cloudwatch line 52)
[2017-01-18T18:20:29+00:00] DEBUG: Providers for generic gem_package resource enabled on node include: [Chef::Provider::Package::Rubygems]
[2017-01-18T18:20:29+00:00] DEBUG: Provider for action install on resource gem_package[bundler] is Chef::Provider::Package::Rubygems
[2017-01-18T18:20:29+00:00] DEBUG: gem_package[bundler] detected omnibus installation in /opt/chef/embedded/bin
[2017-01-18T18:20:29+00:00] DEBUG: gem_package[bundler] searching for 'gem' binary in path: /sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/opt/chef/embedded/bin:/opt/chef/embedded/bin:/usr/local/sbin:/usr/local/bin
[2017-01-18T18:20:29+00:00] DEBUG: gem_package[bundler] using gem '/bin/gem'
/root/.gem/ruby/2.0:/usr/share/ruby/gems/2.0:/usr/local/share/ruby/gems/2.0
[2017-01-18T18:20:29+00:00] DEBUG: gem_package[bundler] no installed version found for bundler (>= 0)
RubyGems Environment:

RUBYGEMS VERSION: <IP_ADDRESS>
RUBY VERSION: 2.0.0 (2015-12-16 patchlevel 648) [x86_64-linux]
INSTALLATION DIRECTORY: /usr/local/share/ruby/gems/2.0
RUBY EXECUTABLE: /usr/bin/ruby2.0
EXECUTABLE DIRECTORY: /usr/local/bin
RUBYGEMS PLATFORMS:

ruby
x86_64-linux

GEM PATHS:

/usr/local/share/ruby/gems/2.0
/root/.gem/ruby/2.0
/usr/share/ruby/gems/2.0

GEM CONFIGURATION:

:update_sources => true
:verbose => true
:backtrace => false
:bulk_threshold => 1000

REMOTE SOURCES:

https://rubygems.org/
[2017-01-18T18:20:29+00:00] DEBUG:  found gem bundler version 1.13.7 for platform ruby from
[2017-01-18T18:20:29+00:00] DEBUG: gem_package[bundler] bundler not installed, installing 1.13.7
Successfully installed bundler-1.13.7
1 gem installed
[2017-01-18T18:20:31+00:00] INFO: gem_package[bundler] installed bundler at 1.13.7
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[bundler] resetting gem environment to default
[2017-01-18T18:20:31+00:00] INFO: Processing gem_package[io-console] action install (newrelic_plugins::aws_cloudwatch line 53)
[2017-01-18T18:20:31+00:00] DEBUG: Providers for generic gem_package resource enabled on node include: [Chef::Provider::Package::Rubygems]
[2017-01-18T18:20:31+00:00] DEBUG: Provider for action install on resource gem_package[io-console] is Chef::Provider::Package::Rubygems
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[io-console] detected omnibus installation in /opt/chef/embedded/bin
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[io-console] searching for 'gem' binary in path: /sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/opt/chef/embedded/bin:/opt/chef/embedded/bin:/usr/local/sbin:/usr/local/bin
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[io-console] using gem '/bin/gem'
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[io-console] found installed gem io-console version 0.4.5 matching io-console (>= 0)
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[io-console] io-console 0.4.5 already installed
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[io-console] is already installed - nothing to do
[2017-01-18T18:20:31+00:00] DEBUG: gem_package[io-console] resetting gem environment to default
`

And results:
`gem list --local
*** LOCAL GEMS ***
bigdecimal (1.2.0)
bundler (1.13.7)
json (1.8.3)
psych (2.0.0)
rdoc (4.2.2)
`

It appears to be something to do with amazon linux.

are you all using opsworks?  as brought up in issue #3389 opsworks is running chef-client out of bundler, and then since it needs to escape from the bundle it hacks it up with this monkeypatch:
https://github.com/aws/opsworks-cookbooks/blob/c1426eee3f/opsworks_commons/libraries/monkey_patch_rubygems_provider.rb

Not using opsworks, I'm using my own chef server with my own cookbooks etc.

Its been a while, so I had to remember where I had this issue. It was with this: https://github.com/newrelic-platform/newrelic_plugins_chef/blob/master/recipes/aws_cloudwatch.rb
On a new system it still fails for the same root cause.
`  * gem_package[bundler] action install[2017-04-13T18:49:23+00:00] INFO: Processing gem_package[bundler] action install (newrelic_plugins::aws_cloudwatch line 3)
[2017-04-13T18:49:25+00:00] INFO: gem_package[bundler] installed bundler at 1.14.6
- install version 1.14.6 of package bundler

execute[bundle install] action run[2017-04-13T18:49:25+00:00] INFO: Processing execute[bundle install] action run (newrelic_plugins::aws_cloudwatch line 8)
[execute] /usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in require': cannot load such file -- io/console (LoadError)

My application was affected by this issue, and I think I finally tracked down the root cause.
The issue is that the AlternateGemEnvironment class used for searching the system gem binary paths for dependencies does so by setting Gem::Specification.dirs before invoking the Rubygems API: https://github.com/chef/chef/blob/8a361fbc44402e38b9eac6815c09456211ee0966/lib/chef/provider/package/rubygems.rb#L300
However, setting dirs to the alternate-ruby's gem-paths doesn't account for 'default' gems also installed in the embedded Ruby, which still get added to the list of specifications returned by Rubygems.
Simple fix is to add .reject(&:default_gem?) to the end of this line to filter out default gems from the returned list:
https://github.com/chef/chef/blob/8a361fbc44402e38b9eac6815c09456211ee0966/lib/chef/provider/package/rubygems.rb#L90
I tested this fix on my repro and it fixed the issue.

but if the AlternateGemEnvironment has the same gem as the built-in gem in the omnibus ruby, then your solution would incorrectly remove that wouldn't it?

but if the AlternateGemEnvironment really has the same gem as the built-in gem in the omnibus ruby, then your solution would incorrectly remove that wouldn't it?

Yeah, adding .reject(&:default_gem?) would remove the omnibus-ruby 'default' gems from the installed-versions list, which could be considered incorrect in the case where omnibus-ruby is the intended environment to check (and if we intended to include default gems in the installed-versions list). However, the current implementation already incorrectly misses default gems in system ruby environments, so a fix to ignore default gems entirely would at least make the behavior consistent from one environment to the other.
A more conservative fix for this issue would only filter out default gems when they're from the wrong environment:
gem_specification.find_all_by_name(gem_dep.name, gem_dep.requirement).reject do |spec|
  # Remove any default gems not from the current environment.
  spec.default_gem? &&
  gem_paths.none? {|dir| spec.loaded_from.include? dir}
end

Beyond that, it might be possible to stub more parts of the Rubygems environment beyond Gem::Specification.dirs to get the environment-specific default gems added to the installed-versions list as well- but I think that would open up an even greater risk of bugs and issues so I don't think it's worth it.

Should also be fixed by #6955.


Add Odata filter examples to get-azsippool

Examples for OData are non-existent on Azure Stack so I created one.
It is much more efficient way of filtering than using Where-Object.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azurestackps-1.3.0/Azs.Fabric.Admin/Get-AzsIpPool.md
:white_check_mark:Succeeded
View (azurestackps-1.3.0)

azurestackps-1.4.0/Azs.Fabric.Admin/Get-AzsIpPool.md
:white_check_mark:Succeeded
View (azurestackps-1.4.0)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@cblackuk Please sign off and this will be merged.

signoff

@sign-off

#sign-off


Add .cs: Content by default

Published with version 0.7.0

This feature does not work for me by default when installing v0.7.0. I still have to manually add the following setting to get the desired behavior:
"csproj.itemType": {
        "*": "Content",
        ".cs": "Compile",
        ".ts": "TypeScriptCompile"
},

I am not familiar with vscode extension defaults, but maybe this object needs updating?
https://github.com/azz/vscode-csproj/blob/9ac42aaf92359356bf2cf0c20e2eb987c611a477/package.json#L47-L50
Thanks,


float slides render bad until the slider is initialized

as you know your plugin uses float method to keep the slides alinged, and when the slider is initialized, you are able to give width to the parent container via javascript.
BUT... until the slider is loaded, the slides are stacked one below the other, as like normal elements, blocking space, and once the slider is init-ed, they suddenly go up and form a slider stacking one beside each other.
This wouldn't be noticed if its a single slider on page, but if thee's other content (big page) along with the slider, or consider a slow connection, the slider wouldn't be loaded the moment you enter the page. hence, the awkward rendering or movement, whatever you call, appears.
solutions:

for sliders I prefer to use absolute, so your slider looks as is before and after slider is loaded because of CSS, blocking same position before and after.
giving fixed height to the slider and overflowing none, is a way - but we talk responsive here, so isn't a good idea.

What do you think?

Stacking of slides issue solved after adding cS-hidden class.  But I am getting slider like this after including cS-hidden.
Before loading

After loading

How can I solve this issue? Please guide.

Including my script inside  $(window).load(function(){}); solved the issue shown in first screenshot. But i am still getting double lsaction as shown in the second screenshot.


Error in creating resources

This is how I create the client for resource groups:
	oAuthConfig, err := adal.NewOAuthConfig(azure.PublicCloud.ActiveDirectoryEndpoint, tenantID)
	if err != nil {
		fmt.Printf(err.Error())
		log.Fatalf("Cannot get oAuth configuration")
	}

	token, err := adal.NewServicePrincipalToken(*oAuthConfig, clientID, clientSecret, azure.PublicCloud.ResourceManagerEndpoint)
	if err != nil {
		fmt.Printf(err.Error())
		log.Fatalf("Cannot get service principal token")
	}

	groupsClient := resources.NewGroupsClient(subscriptionID)
	groupsClient.Authorizer = autorest.NewBearerAuthorizer(token)

Then, when I use it:
	 resourceGroupParameters := resources.Group{
	 	Location: &location,
	 }
	 _, err := groupsClient.CreateOrUpdate(name, resourceGroupParameters)
	 if err != nil {
	 	fmt.Println(err.Error())
	 }

resources.GroupsClient#CreateOrUpdate: Failure preparing request: StatusCode=0 -- Original Error: autorest: No scheme detected in URL
The same happens for the storage and network clients.
(Strangely, this doesn't happen for the VM client)

I see you closed this, @radu-matei. Has it been resolved?

I ran into this error recently, in my case I attempted to call an uninitialized client for Storage. Looking at your snippet, I see you initialize groupsClient but without specifying the base url. Try
resourceGroupsClient := resources.NewGroupsClientWithBaseURI(env.ResourceManagerEndpoint, subscriptionId)  where endpoint is from
env, envErr := azure.EnvironmentFromName("AzurePublicCloud") // change environment name to suite your needs


DTS-29689 changes

As part of this story, for FTPR in iteration, we have included a new field mapping called labels, in which we include the labels types of tickets, so that only that label linked tickets will be showed.

@eswbogol installation script changes not there, also add on mongo query on scripts as GS might need it


add note variable to the article and highlight template

feat: fetch note from articles api
feat: add note variable to the article and highlight template

LGTM, can we test with demo (once setting notes is available) before release?

yeah but we need to manually change the API endpoint in the code and compile it

@jacksonh I will add a setting for the endpoint just like what i did for the Obsidian plugin so we don't need to change the code manually

Added the server endpoint to the settings


How to add Prometheus data source in Grafana?

Hi, after I execute docker run, I try to add Prometheus data source in Grafana with url: http://localhost:8080.
However, when I press "save and test", error show up "HTTP Error Not Found".
I also can't open web browser with http://localhost:8080.
Please help.

Hey @banchain, I'd suggest reading more about how Prometheus works. This is just an exporter for gathering cloudflare data, you still need a separate Prometheus instance to pull data from this exporter.
https://prometheus.io/docs/instrumenting/exporters/


SDK Performance degradation from 13 - 15

Brief bug description
What went wrong?
Upgraded to 15.0.0-rc1 and noticed a large performance impact with linked items where they are now extracted before as they are added at construction time when creating the DeliveryItemListingResponse class.
History: compared latest commit to commit 03/01/2020
In the old delivery client, DeliveryItemListingResponse,  Linked items used to be a dynamic property linked to a lazy object.
_linkedItems = new Lazy(() => (JObject)_response.Content["modular_content"].DeepClone(), LazyThreadSafetyMode.PublicationOnly);
Which was only actioned if the property was accessed.
However in the new instance this is populated when the content is returned inside the delivery client. I feel this is causing the issue. In the past we have never used linked Items, well not intentionally anyway.....
Expected behavior
To be honest I am not quite sure I fully understand the linked items part, as I have never intentionally used that property. Happy to discuss though...
As per email through to Martin, we have happened on this by chance by the way our content is structured for menu's.

Hi @johnhydemtm365,
thanks for reporting the issue. You are right, the problem is with a large amount of strongly-typed LinkedItems. We did a hotfix 15.0.0-rc2, where we have removed strongly-typed LinkedItems and added the dynamic LinkedItems for now.
Before releasing a stable version of 15th, we want to find a better solution for LinkedItems.

internal ref: DEL-2832

We have decided to remove LinkedItems property from the response and added a wiki section describing the approach of mapping modular content to the strongly typed models in the wiki page.
These changes are in [15.0.0-rc3](https://github.com/Kentico/kontent-delivery-sdk-net/releases/tag/15.0.0-rc3

Hi, when are you guys releasing the next non release candidate?

Hi, when are you guys releasing the next non release candidate?

Hey @johnhydemtm365, I am planning to keep the RC for testing and evaluation for a couple of weeks. Don't quote me on that, but July/August is a realistic estimate to release the final candidate if nothing comes up.
I don't want to release them because of vacation and keeping the testing period. Would you be able to test it out? Or is there anything you would need to test it?

Hi, we can update and test with the other stuff we have going on.


fix(ops): add missing APIs for ops project

Part of #397

TODO: we may want to replace this PR with manual activation instructions (e.g. via gcloud).
(I'm leaving it open to document which APIs we'll need to enable on each project we use.)

Bootstrapping terraform on a project generally requires IAM and Resource Manager to be already available, to support Terraform authenticating with Cloud and querying for resources before the apply step is reached. This means these two services should already be enabled before terraform apply may execute.

This is obsolete; closing in favor of #524


New branding logo

An authentic trustable logo than existing B-itcoin

fixed in 2022.05.15 release


Golang Quick-Start master changes brings confusion

We can check the diffs between https://sdk.operatorframework.io/docs/building-operators/golang/quickstart/ (release) and master (https://master.sdk.operatorframework.io/docs/building-operators/golang/quickstart/). Following the points

Ansible/Helm/Golang now has no longer the same steps and are no longer equals
The idea of the quick start is to be very quick and just give the commands for the users to create and deploy an operator in order to offer a basic experience. However, now it is too much more verbose.
The following NOTE was removed. This NOTE is required since new users usually do not understand that the repository where the image will be pushed needs to be set as public. (It was a very common issue raised in the past which shows solved well with the note.)

Why we need to use quay.io? It is not a requirement and by adding that lead the understanding that users should mandatorily use it. Also, note that a lot of developers will not indeed know that it is a kind of registry since docker hub is the most used.

Also, why we need these exports at all? They make the instruction more verbose and in POV harder to understand and copy and paste.

Original instruction:
make docker-build docker-push IMG=<some-registry>/<project-name>:<tag>

Was replaced in master by:
export USERNAME=<quay-namespace>
export OPERATOR_IMG="quay.io/$USERNAME/memcached-operator:v0.0.1"
make docker-build docker-push IMG=$OPERATOR_IMG

The following NOTE shows not fit well in the quick start. See that it is very similar to the topics in the FAQ. Then, IMO it should be moved to the FAQ section.

The following instruction is confusing. To much verbose and I do not think that we should add notes in the instructions because it goes against the idea of making it easier for users just copy and past:

make bundle IMG=$OPERATOR_IMG
# Note the "-bundle" component in the image name below.
export BUNDLE_IMG="quay.io/$USERNAME/memcached-operator-bundle:v0.0.1"
make bundle-build BUNDLE_IMG=$BUNDLE_IMG
make docker-push IMG=$BUNDLE_IMG

Suggestion:
make bundle IMG=<some-registry>/<project-name>:<tag>
make bundle-build docker-push BUNDLE_IMG=<some-registry>/<project-name-bundle>:<tag>

Also, see that the section OLM Integration has a doc that shows more a tutorial but is named as a quick start. So, IMO we should fix that to be a real quick-start as we discussed and agreed before (@joelanford, @asmacdo and I) regards its standards and just link in the Next section the bundle quick start. Note that we discussed the quick start approach a lot for the release 1.0.0. (E.g see the bundle quick start to know how to deploy your operator using the bundle). Note that the steps add regards to the bundle are not completed too. It should speak about the interface mode that will appear for the users and then, by adding it to the building operators sections starts to get too verbose and confuse. Also shows go out of its scope and purpose.

c/c @asmacdo @jmrodri @estroz

c/c @asmacdo @jmrodri @estroz

Ansible/Helm/Golang now has no longer the same steps and are no longer equals

That isn't really true. In fact, they are more equal than they were in the latest release (v1.3).

The idea of the quick start is to be very quick and just give the commands for the users to create and deploy an operator in order to offer a basic experience. However, now it is too much more verbose.

Each quickstart takes ~3000 pixels (3 page-length scrolls on a 1080p monitor) to get to the bottom. That includes headers, footers, etc. IMO this is very quick.

The following NOTE was removed

This should be added back.

Why we need to use quay.io

We don't, it is an example. Feel free to make it more generic.

Also, why we need these exports at all

Feel free to change those.

The following NOTE shows not fit well in the quick start. See that it is very similar to the topics in the FAQ.

Agreed

The following instruction is confusing. To much verbose and I do not think that we should add notes in the instructions because it goes against the idea of making it easier for users just copy and past

Sure. #4406 makes these commands even easier to run inline.

Also, see that the section OLM Integration has a doc that shows more a tutorial but is named as a quick start. So, IMO we should fix that to be a real quick-start as we discussed and agreed before

There's already an issue for this: #4241

Ansible/Helm/Golang now has no longer the same steps and are no longer equals

That isn't really true. In fact, they are more equal than they were in the latest release (v1.3).

The idea of the quick start is to be very quick and just give the commands for the users to create and deploy an operator in order to offer a basic experience. However, now it is too much more verbose.

Each quickstart takes ~3000 pixels (3 page-length scrolls on a 1080p monitor) to get to the bottom. That includes headers, footers, etc. IMO this is very quick.

The following NOTE was removed

This should be added back.

Why we need to use quay.io

We don't, it is an example. Feel free to make it more generic.

Also, why we need these exports at all

Feel free to change those.

The following NOTE shows not fit well in the quick start. See that it is very similar to the topics in the FAQ.

Agreed

The following instruction is confusing. To much verbose and I do not think that we should add notes in the instructions because it goes against the idea of making it easier for users just copy and past

Sure. #4406 makes these commands even easier to run inline.

Also, see that the section OLM Integration has a doc that shows more a tutorial but is named as a quick start. So, IMO we should fix that to be a real quick-start as we discussed and agreed before

There's already an issue for this: #4241


适配kingbase数据库

Why you need it?
Is your feature request related to a problem? Please describe in details
系统建设需要，要使用kingbase数据库，并在AT模式下，实现分布式事务管理
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.

Thank you very much for your feedback. We have collected your requirements.

需求相同，系统建设需要，要使用kingbase数据库，并在AT模式下，实现分布式事务管理。

https://github.com/apache/incubator-seata/pull/6876


FAILED ATTEMPT: Regenerating MONDO with boomer results inclusion.

Fixes #6412

This PR is not usable atm because I made so many false assumptions about boomer


Help!

When I used Minecraft version win10 to generate the map, I put the map into the server to run, and bedrockServer.executeCommand couldn't run normally.
bedrockServer.executeCommandOnConsole too!

bedrockServer.executeCommandOnConsole is ok!


Should enumerable tasks default to one-at-a-time?

Instead of today being Task.WhenAll. It seems this default causes more problems than it solves. See #288

How about making it configurable?

I just made the methods virtual in my PR, would that be sufficient?
On Fri, Jul 13, 2018 at 1:57 PM Bartosz<EMAIL_ADDRESS>wrote:

How about making it configurable?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/291#issuecomment-404923192,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMhsGrR2MgM29R4TgzmMGdtLh-G8Nks5uGO2rgaJpZM4VLFku
.

I think its fair enough. It is the only way to avoid breaking changes.

I like the idea of configuring but without introducing some kind of
factory, not all containers would play nice with the new constructors.
On Mon, Jul 16, 2018 at 11:44 AM Bartosz<EMAIL_ADDRESS>wrote:

I think its fair enough. It is the only way to avoid breaking changes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/291#issuecomment-405310386,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMvI2UqiQ24eYhdUvW1Qup0f0Ubi1ks5uHMLRgaJpZM4VLFku
.

@jbogard Could you publish nuget with recent changes (without Task.WhenAll)? I think that could be reason of
System.InvalidOperationException: A second operation started on this context before a previous operation completed. Any instance members are not guaranteed to be thread safe.
   at Microsoft.EntityFrameworkCore.Internal.ConcurrencyDetector.EnterCriticalSection()

@sm-g pushed today, 5.1.0


Adding dependency status bar to README.md

Adding dependency status bar to README.md to make it easier to identify when one or more dependencies are out of date.

That might come in handy, but you should use icon from shields.io instead

Oh, I see: https://img.shields.io/david/request/request.svg?style=flat-square , I'll fix it up tonight or tomorrow.

Updated to the svg from shields.io


Ability to disable chapter transitions

Describe your suggested feature
As has been reported by several users on the Mihon Discord server, some sources generate a chapter for every page, which results in a chapter transition being shown between every page. There is an existing reader setting for "Always show chapter transition" which can be disabled, but this does not prevent chapter transitions from being shown, rather it inhibits what seems to be a random subset of them from appearing. The desired behavior is that chapter transitions are not shown at all when configured as such for a particular source.
Other details

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.16.5.
[X] I will fill out all of the requested information in this form.

That doesn't seem to match up with the behavior that I observe. Even with the current page and next/previous dozen already downloaded in advance, whenever I change from one page to the next or previous, the message "Loading pages..." is displayed momentarily and I am presented with a chapter separator.
I'm currently using "Paged (left to right)" as a reader setting, and "Auto download while reading" is set to "Next 5 unread chapters", although I don't think that setting would be relevant when all the chapters have already been downloaded manually.
Did I misunderstand what to expect from this feature, or am I doing something wrong?

I just used a different entry in my library to test this, and I have reproduced it. The first transition is skipped, but then it's always shown if you keep reading without exiting. I have also tried turning off the internet, it still shows "loading page" and displays it normally.
Tried one more thing - not downloaded, but cached beforehand. Turned off the internet. The same thing - pages are shown, but there is still a chapter transition with "loading page".
My guess is that it doesn't properly trigger preloading the next chapter when there is only one page. But it seems that when opening the reader, it does prepare the next chapter even if there is only one page.

I think the problem isn't limited to chapters with only one page. I use a particular source where each chapter has exactly two pages, and the problem still occurs. It seems that Mihon does not optimize well for the case of a large number of chapters. It's impossible to swipe between chapters faster than a rate of about one per five seconds, since it needs to repeatedly re-load data, presumably from the chapter index, before the next page is displayed.
The message is displayed here:
https://github.com/mihonapp/mihon/blob/f080a4937e61d3dde5473876c34db8f16844e30c/i18n/src/commonMain/resources/MR/base/strings.xml#L780
That function is called from here:
https://github.com/mihonapp/mihon/blob/f080a4937e61d3dde5473876c34db8f16844e30c/app/src/main/java/eu/kanade/tachiyomi/ui/reader/viewer/pager/PagerTransitionHolder.kt#L88-L94
Here is a sample of logs (debug logging enabled) for the aforementioned two-page-per-chapter source, which currently has about 2,900 chapters. I am swiping to the next page/chapter as fast as possible. You can see that the maximum throughput is 6.6 seconds per chapter. Most of the time is spent either waiting for the "Loading pages" spinner, or having gestures not be recognized because the app is frozen during the first part of that loading process.

04-17 17:47:34.214 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 2/2
04-17 17:47:34.214 10979 10979 D VerticalPagerViewer: Request preload next chapter because we're at page 2 of 2
04-17 17:47:37.095 10979 10979 I Choreographer: Skipped 159 frames!  The application may be doing too much work on its main thread.
04-17 17:47:37.107 10979 11132 I HWUI    : Davey! duration=2659ms; Flags=0, FrameTimelineVsyncId=66389203, IntendedVsync=298713245691162, Vsync=298715893189350, InputEventId=666364776, HandleInputStart=298715900966980, AnimationStart=298715900967875, PerformTraversalsStart=298715901226380, DrawStart=298715903209656, FrameDeadline=298713262291162, FrameInterval=298715900741150, FrameStartTime=16650932, SyncQueued=298715904146220, SyncStart=298715905162862, IssueDrawCommandsStart=298715905241394, SwapBuffers=298715906021790, FrameCompleted=298715906586243, DequeueBufferDuration=19043, QueueBufferDuration=249186, GpuCompleted=298715906586243, SwapBuffersCompleted=298715906356832, DisplayPresentTime=298696024342296, CommandSubmissionCompleted=298715906021790,
04-17 17:47:37.431 10979 10979 D VerticalPagerViewer: onTransitionSelected: Next(from=/437/, to=/438/)
04-17 17:47:37.431 10979 10979 D VerticalPagerViewer: Request preload destination chapter because we're on the transition
04-17 17:47:37.751 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 1/2
04-17 17:47:37.752 10979 10979 D ReaderViewModel: Setting /438/ as active
04-17 17:47:37.752 10979 11066 D StandaloneCoroutine: Loading /438/
04-17 17:47:38.078 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 2/2
04-17 17:47:40.284 10979 10979 I Choreographer: Skipped 113 frames!  The application may be doing too much work on its main thread.
04-17 17:47:40.304 10979 11132 I HWUI    : Davey! duration=1889ms; Flags=0, FrameTimelineVsyncId=66390364, IntendedVsync=298717208112591, Vsync=298719089368909, InputEventId=494521517, HandleInputStart=298719090028831, AnimationStart=298719090037986, PerformTraversalsStart=298719090295147, DrawStart=298719091967999, FrameDeadline=298717241362833, FrameInterval=298719089518414, FrameStartTime=16648286, SyncQueued=298719092821311, SyncStart=298719093943788, IssueDrawCommandsStart=298719094023256, SwapBuffers=298719098604636, FrameCompleted=298719098942364, DequeueBufferDuration=17416, QueueBufferDuration=228597, GpuCompleted=298719098942364, SwapBuffersCompleted=298719098932883, DisplayPresentTime=298697289866914, CommandSubmissionCompleted=298719098604636,
04-17 17:47:40.418 10979 10979 D VerticalPagerViewer: onTransitionSelected: Next(from=/438/, to=/439/)
04-17 17:47:40.418 10979 10979 D VerticalPagerViewer: Request preload destination chapter because we're on the transition
04-17 17:47:40.418 10979 11043 D ReaderViewModel: Preloading /439/
04-17 17:47:40.418 10979 11043 D UndispatchedCoroutine: Loading pages for 439 - Redacted
04-17 17:47:44.367 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 1/2
04-17 17:47:44.367 10979 10979 D ReaderViewModel: Setting /439/ as active
04-17 17:47:44.367 10979 11060 D StandaloneCoroutine: Loading /439/
04-17 17:47:44.368 10979 10979 D ReaderChapter: Recycling chapter 437 - Redacted
04-17 17:47:44.710 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 2/2
04-17 17:47:44.710 10979 10979 D VerticalPagerViewer: Request preload next chapter because we're at page 2 of 2
04-17 17:47:44.710 10979 11051 D ReaderViewModel: Preloading /440/
04-17 17:47:44.710 10979 11051 D UndispatchedCoroutine: Loading pages for 440 - Redacted
04-17 17:47:44.820 10979 11003 W System  : A resource failed to call close.
04-17 17:47:46.974 10979 10979 D VerticalPagerViewer: onTransitionSelected: Next(from=/439/, to=/440/)
04-17 17:47:46.974 10979 10979 D VerticalPagerViewer: Request preload destination chapter because we're on the transition
04-17 17:47:46.978 10979 10979 I Choreographer: Skipped 122 frames!  The application may be doing too much work on its main thread.
04-17 17:47:46.996 10979 11132 I HWUI    : Davey! duration=2036ms; Flags=0, FrameTimelineVsyncId=66393430, IntendedVsync=298723750885701, Vsync=298725781578263, InputEventId=739249126, HandleInputStart=298725783630274, AnimationStart=298725783631332, PerformTraversalsStart=298725783825872, DrawStart=298725785463526, FrameDeadline=298723784144738, FrameInterval=298725783416000, FrameStartTime=16645021, SyncQueued=298725786175522, SyncStart=298725787162176, IssueDrawCommandsStart=298725787246974, SwapBuffers=298725788255722, FrameCompleted=298725788769435, DequeueBufferDuration=16398, QueueBufferDuration=242229, GpuCompleted=298725788769435, SwapBuffersCompleted=298725788591741, DisplayPresentTime=298721780402611, CommandSubmissionCompleted=298725788255722,
04-17 17:47:49.563 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 1/2
04-17 17:47:49.563 10979 10979 D ReaderViewModel: Setting /440/ as active
04-17 17:47:49.564 10979 11015 D StandaloneCoroutine: Loading /440/
04-17 17:47:49.564 10979 10979 D ReaderChapter: Recycling chapter 438 - Redacted
04-17 17:47:49.700 10979 11003 W System  : A resource failed to call close.
04-17 17:47:49.900 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 2/2
04-17 17:47:52.327 10979 10979 I Choreographer: Skipped 125 frames!  The application may be doing too much work on its main thread.
04-17 17:47:52.333 10979 10979 D VerticalPagerViewer: onTransitionSelected: Next(from=/440/, to=/441/)
04-17 17:47:52.334 10979 10979 D VerticalPagerViewer: Request preload destination chapter because we're on the transition
04-17 17:47:52.334 10979 11047 D ReaderViewModel: Preloading /441/
04-17 17:47:52.334 10979 11047 D UndispatchedCoroutine: Loading pages for 441 - Redacted
04-17 17:47:52.339 10979 11117 I HWUI    : Davey! duration=2094ms; Flags=0, FrameTimelineVsyncId=66395736, IntendedVsync=298729044697566, Vsync=298731125314816, InputEventId=86723367, HandleInputStart=298731133297391, AnimationStart=298731133588936, PerformTraversalsStart=298731133802437, DrawStart=298731135768745, FrameDeadline=298729061297566, FrameInterval=298731132876696, FrameStartTime=16644938, SyncQueued=298731136613594, SyncStart=298731137544787, IssueDrawCommandsStart=298731137618436, SwapBuffers=298731138534126, FrameCompleted=298731139772367, DequeueBufferDuration=16398, QueueBufferDuration=229777, GpuCompleted=298731139772367, SwapBuffersCompleted=298731138842273, DisplayPresentTime=298726990978745, CommandSubmissionCompleted=298731138534126,
04-17 17:47:57.629 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 1/2
04-17 17:47:57.629 10979 10979 D ReaderViewModel: Setting /441/ as active
04-17 17:47:57.629 10979 11047 D StandaloneCoroutine: Loading /441/
04-17 17:47:57.630 10979 10979 D ReaderChapter: Recycling chapter 439 - Redacted
04-17 17:47:58.061 10979 10979 D VerticalPagerViewer: onReaderPageSelected: 2/2
04-17 17:47:58.061 10979 10979 D VerticalPagerViewer: Request preload next chapter because we're at page 2 of 2
04-17 17:47:58.061 10979 11260 D ReaderViewModel: Preloading /442/

The performance analysis above is corroborated by the fact that Mihon hangs completely on a black screen for about 5 seconds when selecting any chapter from the index. So, basically, loading a chapter takes 5-6 seconds when you have about 2,900 chapters. There is clearly some performance issue to be addressed, since the required work to load a single page should be in the milliseconds. (Sources with small chapter counts do not have any of the above issues.)

The speed of preparing a chapter, probably, should be a separate issue, if an issue at all.
In the case of 1-page chapters, it doesn't prepare chapters at all.
In the case of 2-page chapters, as I can see from the logs above, preparing the next chapter happens on the second page. It means that with a normal reading speed, it shouldn't be an issue. I have also tested this on my side with 2-page chapters, and it works fine if you scroll at a regular speed.

It means that with a normal reading speed, it shouldn't be an issue

Unfortunately, that doesn't quite turn out to be how it works, for two reasons:

The chapter loading sometimes completely freezes the app, so you can't zoom or pan for some seconds. (In cases where Mihon tries to repeatedly load a chapter, for example in cases where the source cannot provide working data for specific chapters, the Android system has intervened and suggested that I kill the app for nonresponsivity. Stack traces and log entries suggest that the app isn't responding in a timely manner to user inputs.
With the two-page-per-chapter source that I use, the second page of each chapter is the caption for the first page, which does not typically take more than five seconds to read. This means one must intentionally wait for the loading to finish before one can move to the next chapter.

There are also plenty of one-page-per-chapter sources where each page is small enough to take less than 5-10 seconds to read, e.g. a single panel per page. The long chapter loading times combine with the fallback behavior (to show a transition page when loading has not finished even if the user has disabled transition pages) to produce the experience described in the original post.

The speed of preparing a chapter, probably, should be a separate issue, if an issue at all

Well, the app freezing for more than 5 seconds every time you change pages is quite an issue in my personal opinion, but it only affects a subset of sources.
I only found out that slow chapter loading times were the cause when investigating this issue, which is why it's here. If the maintainers desire for that sub-problem to be split out into a separate issue I am happy to do so.

Okay, I finally found the explicit logic that adds a transition when the next chapter is not loaded yet:
https://github.com/mihonapp/mihon/blob/f27ca3b1b2f92258c213bca6b27d8eff4c7363ad/app/src/main/java/eu/kanade/tachiyomi/ui/reader/viewer/pager/PagerViewerAdapter.kt#L92-L100
I'm looking into the loading times, but I'm also looking into why it takes so long to initiate a download queue with a large number of chapters (because that is getting in the way of my testing the first issue)... this appears to be an error in the usage of UniFile where unneeded data is repeatedly retrieved. I'll file a separate issue or pull request about that one and then come back to debugging this problem.

Ok, considering your description and the number of chapters, I now realized that we are testing it on the same library entry. I scroll it 1 page per second, loads fine for me. It looks more like a device-specific issue if it takes 5 seconds to load it. Yet again, it should be a separate issue if an issue at all.

It turns out that the performance degrades linearly with the number of downloaded chapters due to an oversight in the UniFile library findFile implementation. If you have 2,400 downloaded chapters then it takes about 10-15 seconds to load a single chapter, or to initiate the download for a single chapter.
I will file a new issue or pull request for this issue, which in my opinion is a serious problem (initiating the download for a chapter should take milliseconds, not 15 seconds, and the delay is serial per chapter, so initiating download for 100 chapters takes 20 minutes of full CPU utilization for the phone - it makes downloading near-unusable for large numbers of chapters).
I doubt strongly that this is a device-specific issue given that I can point to the specific code that is causing the problem, which has clear logic errors. More details to follow.

As mentioned in https://github.com/mihonapp/mihon/issues/705#issuecomment-2084287478, I expect that https://github.com/mihonapp/mihon/pull/728 and https://github.com/tachiyomiorg/UniFile/pull/2, together, may fix this problem as well as the issue with download performance, since I believe they both have the same root cause. Now that it is actually possible for me to download a large number of chapters to produce an accurate test case, I will verify whether there are any further optimizations which are needed before chapter transitions become seamless.

This issue is resolved by https://github.com/mihonapp/mihon/pull/728, as explained in https://github.com/mihonapp/mihon/issues/705#issuecomment-2094406702.
The behavior of this setting is still unintuitive, I would argue that when chapter transitions are disabled, a loading screen rather than a chapter transition should be displayed if a chapter is not yet loaded, but this specific issue (there being no actual way to disable transitions properly when a large number of chapters have been downloaded) is resolved. I may file a separate, more specific issue for other usability improvements.


feat(build): webpack visualizer

SUMMARY
Some updates to the bundle analyzer in honor of @kgabryje's recent efforts. This PR does several things:

Adds a new npm run bundle-stats script to run package bundle analysis
Makes webpack's production build process (a.k.a. npm run build) exits when complete.
Removes the earlier webpack-bundle-analyzer flag in favor of the new npm script
Sets webpack-bundle-analyzer to static mode rather than server mode.
Adds a new bundle analyzer with a sunburst chart, which makes some aspects easier
Has BOTH bundle analyzers open at the end of the build process in your browser.

Here's what the new bundle analyzer looks like:

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

Nice! I wonder if we shoukd run the plugin only if a flag is passed, like we do with bundle analyzer

@kgabryje check out the updated PR description, it all works pretty smoothly now.

Given that we removed --analyzeBundle parameter, should we add something to UPDATING.md?

Given that we removed --analyzeBundle parameter, should we add something to UPDATING.md?

Happy to if you want. I only skipped it since neither Kamil nor I could get the --analyzeBundle parameter to actually WORK. We both just tweak the code to run the analyzer, it turns out. I figured this basically takes a broken tool and makes it work, and it's a dev tool rather than user-facing, so I wasn't sure how much value there is.
What might cover this would actually be a Wiki page explaining what all our scripts do, since there are a TON of them, and there's not really any real documentation on the whole lot.


distinct only compares new values to last value, not all previous values

distinct works as distinctUntilChanged
As explanation let me add those references:
http://rxmarbles.com/#distinct
http://rxmarbles.com/#distinctUntilChanged
It would be great to get real distinct operator working

Thanks for the quick solution ! Really helpful stuff.
I totally understand the problem of changing functionality for existing methods.
Would be great to have unique() as part of framework I'm sure about it.
I trust you are gonna pick the best solution to sort this problem out.
For now I'm happy to use extension outside framework.


[feature request] disable number hotkey, but add hotkey to advance/rewind parcellation level

related to https://github.com/FZJ-INM1-BDA/siibra-explorer/issues/741


feat(watcher): add a watcher for ibazel

ibazel (github.com/bazelbuild/bazel-watcher)
is a watch mode for Google's build tool, bazel
(http://bazel.build)
Under this watch mode, tools like Karma should not
directly watch .js files, because the build tool will
not write them all at once. Instead, the build tool
signals when it's time to reload the .js sources.
/cc @gregmagolan @achew22

Not a big fan of adding very tool specific support into core. I would rather see a plugable way to support different watching strategies through plugins. Also this adds the burden of maintenance of a tool I have no experience with or use for at the moment.

@dignifiedquire I understand that motivation. At the same time, AFAICT there isn't a way for a plugin to extend the watchers right now. Have there been any other requests to add a different file watcher? I could imagine doing the work to add this ability to the plugin system, only to see this be the last plugin that ever uses that ability.
Do you want me to try to add such a thing? My other options are to have Bazel users depend on a fork, or find some way to monkey-patch this at load time.

I think I would be fine keeping the code in here, but lets restructure things a little more cleanly so it is clear that there are multiple ways to watch files.
For this to be ready to merge I would like to see

documentation on how to integrate with bazel
a new folder lib/watchers, which holds the current watcher, which I would call filesystem watcher for now and the new bazel watcher
unit tests for the bazel watcher
ideally an e2e test that uses the bazel watcher and makes sure it works

Watchers are now configurable.


Create Transformation task for Engraftment_sample_state

As a developer, I want to have a Luigi task that transforms the data/metadata given by providers into a suitable format for the entity Engraftment_sample_state.
Design
Database Schema

Create entry in scripts/init.sql for the creation of the table, pk and fks.
Create entry in etl/workflow/transformer.py with the class TransformModel.
Create entry in etl/jobs/transformation/spark_transformation_job.py
Create job etl/jobs/transformation/engraftment_sample_state_transformer_job.py
Create entry in luigi.cfg
Create entry in etl/workflow/loader.py

Acceptance Criteria

[x] Table model was created according with the designed database schema
[x] The transformation task can be executed and it finishes correctly
[x] Data in the Engraftment_sample_state table is the expected one for the provider(s)

@CsabaHalmagyi done

Done.


sbt 1.5.0 and Scala 3.0.0-RC2

This PR removes sbt-dotty and upgrades to sbt 1.5.0 and Scala 3.0.0-RC2.
The biggest difficulty involves library dependencies.
withDottyCompat which is now .cross should not be used on Java dependencies and on all Scala dependencies.
I separated the libraryDependencies which contained only Java dependencies from others. Then I also separated the Scala dependencies which require cross versions from those that do not.
Many modules still have some conflict issues, but I propose that we fix them iteratively as we work on them as it is a very tedious process to remove ported/non-ported and incompatible bits.
As libraries progressively are ported to Scala 3, the list of cross-versioned dependencies should shrink.

Feel free to merge as soon as the CI passes.


error: Received response 401 (Not Authorized)

Hi,
I’m getting the below error when trying to publish an extension. I’m using a valid newly created(today) PAT for this. Can you please check and let me know the issue? I’m getting the same error when I try to publish to on-premises TFS 2015 update3 local gallery from cmdline and also using this task.
2017-11-23T05:47:33.6546956Z Extracting archive: E:\Agent-Test_work\1\s\buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z --
2017-11-23T05:47:33.6546956Z Path = E:\Agent-Test_work\1\s\buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z Type = zip
2017-11-23T05:47:33.6546956Z Physical Size = 4953
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Everything is Ok
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Files: 6
2017-11-23T05:47:33.6546956Z Size:       6050
2017-11-23T05:47:33.6546956Z Compressed: 4953
2017-11-23T05:47:33.7794964Z [command]E:\Agents_Ext_work_tasks\PublishExtension_631511b4-50ab-47c8-b766-7ae2aa672733\1.1.44\node_modules\7zip-bin-win\x64\7za.exe a ragamramachandran.build-task-0.0.10.gen.vsix E:\Agents_Ext_work_temp\vsixeditor1171023-11684-1hhfljj.0cmn9daemi* -r -y -tzip -mx9
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z 7-Zip (a) 17.01 beta (x64) : Copyright (c) 1999-2017 Igor Pavlov : 2017-08-28
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Scanning the drive:
2017-11-23T05:47:33.8262967Z 2 folders, 6 files, 5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Creating archive: ragamramachandran.build-task-0.0.10.gen.vsix
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Add new data to archive: 2 folders, 6 files, 5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Files read from disk: 6
2017-11-23T05:47:33.8262967Z Archive size: 5376 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z Everything is Ok
2017-11-23T05:47:39.0991305Z error: Received response 401 (Not Authorized). Check that your personal access token is correct and hasn't expired.
2017-11-23T05:47:39.1303307Z ##[error]tfx failed with error: Error: E:\Agents_Ext_work_tools\tfx.cmd failed with return code:<PHONE_NUMBER>
2017-11-23T05:47:39.1303307Z ##[section]Finishing: Publish Extension
2017-11-23T05:47:39.1459308Z ##[section]Finishing: Release

Thanks,
Ragam

If the command line isn't working, it would make sense the task won't work
either, it invokes the command line in turn.
TFS 2017 came with PAT support, 2015 as far as I can tell doesn't offer
this option, so you need to use a NTLM proxy in order to publish directly
to TFS  or your tfs server must be configured to support basic
authentication over SSL to allow you to pass in the username & password as
plain text.
On Nov 23, 2017 07:11, "RagamRam"<EMAIL_ADDRESS>wrote:

Hi,
I’m getting the below error when trying to publish an extension. I’m using
a valid newly created(today) PAT for this. Can you please check and let me
know the issue? I’m getting the same error when I try to publish to
on-premises TFS 2015 update3 local gallery from cmdline and also using this
task.
2017-11-23T05:47:33.6546956Z Extracting archive: E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z --
2017-11-23T05:47:33.6546956Z Path = E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z Type = zip
2017-11-23T05:47:33.6546956Z Physical Size = 4953
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Everything is Ok
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Files: 6
2017-11-23T05:47:33.6546956Z Size: 6050
2017-11-23T05:47:33.6546956Z Compressed: 4953
2017-11-23T05:47:33.7794964Z [command]E:\Agents_Ext_work_
tasks\PublishExtension_631511b4-50ab-47c8-b766-7ae2aa672733\1.1.44\node_
modules\7zip-bin-win\x64\7za.exe a ragamramachandran.build-task-0.0.10.gen.vsix
E:\Agents_Ext_work_temp\vsixeditor1171023-11684-1hhfljj.0cmn9daemi* -r -y
-tzip -mx9
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z 7-Zip (a) 17.01 beta (x64) : Copyright (c)
1999-2017 Igor Pavlov : 2017-08-28
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Scanning the drive:
2017-11-23T05:47:33.8262967Z 2 folders, 6 files, 5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Creating archive:
ragamramachandran.build-task-0.0.10.gen.vsix
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Add new data to archive: 2 folders, 6 files,
5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Files read from disk: 6
2017-11-23T05:47:33.8262967Z Archive size: 5376 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z Everything is Ok
2017-11-23T05:47:39.0991305Z error: Received response 401 (Not
Authorized). Check that your personal access token is correct and hasn't
expired.
2017-11-23T05:47:39.1303307Z ##[error]tfx failed with error: Error:
E:\Agents_Ext_work_tools\tfx.cmd failed with return code:<PHONE_NUMBER>
2017-11-23T05:47:39.1303307Z ##[section]Finishing: Publish Extension
2017-11-23T05:47:39.1459308Z ##[section]Finishing: Release
Thanks,
Ragam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vsts-extension-build-release-tasks/issues/54,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD-uSzSLErrXbLyvBVemrx5doKJk6uEsks5s5QyHgaJpZM4QoTpz
.

I’m able to upload the extension directly using TFS URL. But, yes, both the command-line and task fails. Using the basic authentication, I’m able to publish a customized build task to our TFS using command-line. Means our TFS is configured to support basic authentication over SSL and allows us to pass in the credential.
Or do extensions and tasks publish work in a different way?
I’m using basic-authentication, but the error shows PAT issue.
<EMAIL_ADDRESS>Thanks,
Ragam
From: Jesse Houwing<EMAIL_ADDRESS>Sent: Thursday, November 23, 2017 4:18 PM
To: Microsoft/vsts-extension-build-release-tasks<EMAIL_ADDRESS>Cc: Ramachandran, Ragam<EMAIL_ADDRESS>Manual<EMAIL_ADDRESS>Subject: Re: [Microsoft/vsts-extension-build-release-tasks] error: Received response 401 (Not Authorized) (#54)
If the command line isn't working, it would make sense the task won't work
either, it invokes the command line in turn.
TFS 2017 came with PAT support, 2015 as far as I can tell doesn't offer
this option, so you need to use a NTLM proxy in order to publish directly
to TFS or your tfs server must be configured to support basic
authentication over SSL to allow you to pass in the username & password as
plain text.
On Nov 23, 2017 07:11, "RagamRam" <notifications<EMAIL_ADDRESS>wrote:

Hi,
I’m getting the below error when trying to publish an extension. I’m using
a valid newly created(today) PAT for this. Can you please check and let me
know the issue? I’m getting the same error when I try to publish to
on-premises TFS 2015 update3 local gallery from cmdline and also using this
task.
2017-11-23T05:47:33.6546956Z Extracting archive: E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z --
2017-11-23T05:47:33.6546956Z Path = E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z Type = zip
2017-11-23T05:47:33.6546956Z Physical Size = 4953
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Everything is Ok
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Files: 6
2017-11-23T05:47:33.6546956Z Size: 6050
2017-11-23T05:47:33.6546956Z Compressed: 4953
2017-11-23T05:47:33.7794964Z [command]E:\Agents_Ext_work_
tasks\PublishExtension_631511b4-50ab-47c8-b766-7ae2aa672733\1.1.44\node_
modules\7zip-bin-win\x64\7za.exe a ragamramachandran.build-task-0.0.10.gen.vsix
E:\Agents_Ext_work_temp\vsixeditor1171023-11684-1hhfljj.0cmn9daemi* -r -y
-tzip -mx9
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z 7-Zip (a) 17.01 beta (x64) : Copyright (c)
1999-2017 Igor Pavlov : 2017-08-28
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Scanning the drive:
2017-11-23T05:47:33.8262967Z 2 folders, 6 files, 5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Creating archive:
ragamramachandran.build-task-0.0.10.gen.vsix
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Add new data to archive: 2 folders, 6 files,
5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Files read from disk: 6
2017-11-23T05:47:33.8262967Z Archive size: 5376 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z Everything is Ok
2017-11-23T05:47:39.0991305Z error: Received response 401 (Not
Authorized). Check that your personal access token is correct and hasn't
expired.
2017-11-23T05:47:39.1303307Z ##[error]tfx failed with error: Error:
E:\Agents_Ext_work_tools\tfx.cmd failed with return code:<PHONE_NUMBER>
2017-11-23T05:47:39.1303307Z ##[section]Finishing: Publish Extension
2017-11-23T05:47:39.1459308Z ##[section]Finishing: Release
Thanks,
Ragam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vsts-extension-build-release-tasks/issues/54,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD-uSzSLErrXbLyvBVemrx5doKJk6uEsks5s5QyHgaJpZM4QoTpz
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/vsts-extension-build-release-tasks/issues/54#issuecomment-346585293, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AgWaYmlcxeQ1mo1RNYyujLpML5eki0i6ks5s5U1MgaJpZM4QoTpz.

When using basic Auth you should not use the personal access token option.
That was only added to 2017. You should use the user/pass option when
setting up the service endpoint.
On Nov 23, 2017 12:00, "RagamRam"<EMAIL_ADDRESS>wrote:

I’m able to upload the extension directly using TFS URL. But, yes, both
the command-line and task fails. Using the basic authentication, I’m able
to publish a customized build task to our TFS using command-line. Means our
TFS is configured to support basic authentication over SSL and allows us to
pass in the credential.
Or do extensions and tasks publish work in a different way?
I’m using basic-authentication, but the error shows PAT issue.
<EMAIL_ADDRESS>Thanks,
Ragam
From: Jesse Houwing<EMAIL_ADDRESS>Sent: Thursday, November 23, 2017 4:18 PM
To: Microsoft/vsts-extension-build-release-tasks <
<EMAIL_ADDRESS>Cc: Ramachandran, Ragam<EMAIL_ADDRESS>Manual <
<EMAIL_ADDRESS>Subject: Re: [Microsoft/vsts-extension-build-release-tasks] error:
Received response 401 (Not Authorized) (#54)
If the command line isn't working, it would make sense the task won't work
either, it invokes the command line in turn.
TFS 2017 came with PAT support, 2015 as far as I can tell doesn't offer
this option, so you need to use a NTLM proxy in order to publish directly
to TFS or your tfs server must be configured to support basic
authentication over SSL to allow you to pass in the username & password as
plain text.
On Nov 23, 2017 07:11, "RagamRam"<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

Hi,
I’m getting the below error when trying to publish an extension. I’m
using
a valid newly created(today) PAT for this. Can you please check and let
me
know the issue? I’m getting the same error when I try to publish to
on-premises TFS 2015 update3 local gallery from cmdline and also using
this
task.
2017-11-23T05:47:33.6546956Z Extracting archive: E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z --
2017-11-23T05:47:33.6546956Z Path = E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z Type = zip
2017-11-23T05:47:33.6546956Z Physical Size = 4953
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Everything is Ok
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Files: 6
2017-11-23T05:47:33.6546956Z Size: 6050
2017-11-23T05:47:33.6546956Z Compressed: 4953
2017-11-23T05:47:33.7794964Z [command]E:\Agents_Ext_work_
tasks\PublishExtension_631511b4-50ab-47c8-b766-7ae2aa672733\1.1.44\node_

modules\7zip-bin-win\x64\7za.exe a ragamramachandran.build-task-0.0.10.gen.vsix

E:\Agents_Ext_work_temp\vsixeditor1171023-11684-1hhfljj.0cmn9daemi* -r
-y
-tzip -mx9
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z 7-Zip (a) 17.01 beta (x64) : Copyright (c)
1999-2017 Igor Pavlov : 2017-08-28
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Scanning the drive:
2017-11-23T05:47:33.8262967Z 2 folders, 6 files, 5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Creating archive:
ragamramachandran.build-task-0.0.10.gen.vsix
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Add new data to archive: 2 folders, 6
files,
5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Files read from disk: 6
2017-11-23T05:47:33.8262967Z Archive size: 5376 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z Everything is Ok
2017-11-23T05:47:39.0991305Z error: Received response 401 (Not
Authorized). Check that your personal access token is correct and hasn't
expired.
2017-11-23T05:47:39.1303307Z ##[error]tfx failed with error: Error:
E:\Agents_Ext_work_tools\tfx.cmd failed with return code:<PHONE_NUMBER>
2017-11-23T05:47:39.1303307Z ##[section]Finishing: Publish Extension
2017-11-23T05:47:39.1459308Z ##[section]Finishing: Release
Thanks,
Ragam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/Microsoft/vsts-extension-build-release-
tasks/issues/54>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD-
uSzSLErrXbLyvBVemrx5doKJk6uEsks5s5QyHgaJpZM4QoTpz>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/
Microsoft/vsts-extension-build-release-tasks/issues/54#
issuecomment-346585293>, or mute the thread<https://github.com/
notifications/unsubscribe-auth/AgWaYmlcxeQ1mo1RNYyujLpML5eki0
i6ks5s5U1MgaJpZM4QoTpz>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vsts-extension-build-release-tasks/issues/54#issuecomment-346588278,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD-uS5GIWq6cs1AqRS63zYKNva84LR0Jks5s5VBpgaJpZM4QoTpz
.

Yes, I’m using user/pass option for setting up the service end point not the PAT. But while publishing the task I’m getting error related to PAT.
<EMAIL_ADDRESS>C:\DeleteTasks>tfx extension publish --vsix C:\cVnextCustomTasks\ragamramachandran.build-task-0.0.10.vsix --auth-type basic
TFS Cross Platform Command Line Interface v0.3.24
Copyright Microsoft Corporation

Username: XXXXXXXX
Password:
Checking if this extension is already published
It isn't, create a new extension.
Received response 401 (Not Authorized). Check that your personal access token is correct and hasn't expired.

Thanks,
Ragam
From: Jesse Houwing<EMAIL_ADDRESS>Sent: Thursday, November 23, 2017 6:21 PM
To: Microsoft/vsts-extension-build-release-tasks<EMAIL_ADDRESS>Cc: Ramachandran, Ragam<EMAIL_ADDRESS>Manual<EMAIL_ADDRESS>Subject: Re: [Microsoft/vsts-extension-build-release-tasks] error: Received response 401 (Not Authorized) (#54)
When using basic Auth you should not use the personal access token option.
That was only added to 2017. You should use the user/pass option when
setting up the service endpoint.
On Nov 23, 2017 12:00, "RagamRam" <notifications<EMAIL_ADDRESS>wrote:

I’m able to upload the extension directly using TFS URL. But, yes, both
the command-line and task fails. Using the basic authentication, I’m able
to publish a customized build task to our TFS using command-line. Means our
TFS is configured to support basic authentication over SSL and allows us to
pass in the credential.
Or do extensions and tasks publish work in a different way?
I’m using basic-authentication, but the error shows PAT issue.
<EMAIL_ADDRESS>Thanks,
Ragam
From: Jesse Houwing<EMAIL_ADDRESS>Sent: Thursday, November 23, 2017 4:18 PM
To: Microsoft/vsts-extension-build-release-tasks <
vsts-extension-build-release-tasks<EMAIL_ADDRESS>Cc: Ramachandran, Ragam <Ragam.Ramachandran<EMAIL_ADDRESS>Manual <
manual<EMAIL_ADDRESS>Subject: Re: [Microsoft/vsts-extension-build-release-tasks] error:
Received response 401 (Not Authorized) (#54)
If the command line isn't working, it would make sense the task won't work
either, it invokes the command line in turn.
TFS 2017 came with PAT support, 2015 as far as I can tell doesn't offer
this option, so you need to use a NTLM proxy in order to publish directly
to TFS or your tfs server must be configured to support basic
authentication over SSL to allow you to pass in the username & password as
plain text.
On Nov 23, 2017 07:11, "RagamRam"<EMAIL_ADDRESS><EMAIL_ADDRESS>> notifications<EMAIL_ADDRESS>wrote:

Hi,
I’m getting the below error when trying to publish an extension. I’m
using
a valid newly created(today) PAT for this. Can you please check and let
me
know the issue? I’m getting the same error when I try to publish to
on-premises TFS 2015 update3 local gallery from cmdline and also using
this
task.
2017-11-23T05:47:33.6546956Z Extracting archive: E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z --
2017-11-23T05:47:33.6546956Z Path = E:\Agent-Test_work\1\s
buildtool\ragamramachandran.build-task-0.0.10.vsix
2017-11-23T05:47:33.6546956Z Type = zip
2017-11-23T05:47:33.6546956Z Physical Size = 4953
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Everything is Ok
2017-11-23T05:47:33.6546956Z
2017-11-23T05:47:33.6546956Z Files: 6
2017-11-23T05:47:33.6546956Z Size: 6050
2017-11-23T05:47:33.6546956Z Compressed: 4953
2017-11-23T05:47:33.7794964Z [command]E:\Agents_Ext_work_
tasks\PublishExtension_631511b4-50ab-47c8-b766-7ae2aa672733\1.1.44\node_

modules\7zip-bin-win\x64\7za.exe a ragamramachandran.build-task-0.0.10.gen.vsix

E:\Agents_Ext_work_temp\vsixeditor1171023-11684-1hhfljj.0cmn9daemi* -r
-y
-tzip -mx9
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z 7-Zip (a) 17.01 beta (x64) : Copyright (c)
1999-2017 Igor Pavlov : 2017-08-28
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Scanning the drive:
2017-11-23T05:47:33.8262967Z 2 folders, 6 files, 5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Creating archive:
ragamramachandran.build-task-0.0.10.gen.vsix
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Add new data to archive: 2 folders, 6
files,
5937 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z
2017-11-23T05:47:33.8262967Z Files read from disk: 6
2017-11-23T05:47:33.8262967Z Archive size: 5376 bytes (6 KiB)
2017-11-23T05:47:33.8262967Z Everything is Ok
2017-11-23T05:47:39.0991305Z error: Received response 401 (Not
Authorized). Check that your personal access token is correct and hasn't
expired.
2017-11-23T05:47:39.1303307Z ##[error]tfx failed with error: Error:
E:\Agents_Ext_work_tools\tfx.cmd failed with return code:<PHONE_NUMBER>
2017-11-23T05:47:39.1303307Z ##[section]Finishing: Publish Extension
2017-11-23T05:47:39.1459308Z ##[section]Finishing: Release
Thanks,
Ragam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/Microsoft/vsts-extension-build-release-
https://github.com/Microsoft/vsts-extension-build-release-> tasks/issues/54>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD-
https://github.com/notifications/unsubscribe-auth/AD-> uSzSLErrXbLyvBVemrx5doKJk6uEsks5s5QyHgaJpZM4QoTpz>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/
https://github.com/> Microsoft/vsts-extension-build-release-tasks/issues/54#
issuecomment-346585293>, or mute the thread<https://github.com/
https://github.com/> notifications/unsubscribe-auth/AgWaYmlcxeQ1mo1RNYyujLpML5eki0
i6ks5s5U1MgaJpZM4QoTpz>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vsts-extension-build-release-tasks/issues/54#issuecomment-346588278,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD-uS5GIWq6cs1AqRS63zYKNva84LR0Jks5s5VBpgaJpZM4QoTpz
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/vsts-extension-build-release-tasks/issues/54#issuecomment-346610350, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AgWaYub2m4Tb4BVupLfT-8GgssBQHugJks5s5WongaJpZM4QoTpz.

These issues are all related to tfx and not to the build tasks. I suspect the error message is generic for 401 and assumes usage of PAT, since the basic account support in 2015 was always sort of, but not very much supported.
Please report your issue here: https://github.com/Microsoft/tfs-cli
As I can't really do anything from this end, the CI tasks end up invoking tfx, if tfx isn't working these tasks won't work either.


docs(cn): translate src/content/loaders/stylus-loader.md

describe your changes...
translate src/content/loaders/stylus-loader.md into chinese

[x] Read and sign the CLA. PRs that haven't signed it won't be accepted.
[x] Make sure your PR complies with the writer's guide.
[x] Review the diff carefully as sometimes this can reveal issues.
[x] Do not abandon your Pull Request: Stale Pull Requests.
Remove these instructions from your PR as they are for your eyes only.

@QC-L 翻译完成，有空帮忙 review 下

参考其他文档，添加下 translators 字段，把你自己加上~

参考其他文档，添加下 translators 字段，把你自己加上~

已添加


CRAN version 0.5.3 of sparklyr incompatible with dev version of dplyr <IP_ADDRESS>02

With the dev version of dplyr installed (4/15/2017,  <IP_ADDRESS>02 commit d7d2f10167b4ac919e876eb9a891fd53345be985) the CRAN version of sparklyr (4/15/2017,   0.5.3 ) will not load:
library("sparklyr")
# Error : object 'sql_build' not found whilst loading namespace 'sparklyr'
# Error: package or namespace load failed for ‘sparklyr’

Problem goes away with dev-version of sparklyr (4/15/2017,  0.5.3-9005 commit 58fcd949d7709b4be44e2789a1c5355a6bd148f3).

We're aware of this -- dplyr 0.6.0 will be coming to CRAN soon, and we plan to update sparklyr at that time as well. For now, if you are using the development version of dplyr you should use the development version of sparklyr.

@kevinushey - Would simply installing dbplyr (https://github.com/hadley/dbplyr/) be another solution?  That way he can keep the versions of the packages he currently has

Thanks, I was hoping the answer was along the lines that there was a planned sparklyr release prior to the dplyr 0.6.0 release.

I'm not sure if installing dbplyr would help -- it's specifically designed to work with the development version of dplyr; I don't think it will work in tandem with the CRAN version of dplyr.

0.5.4 is on CRAN now: https://cran.r-project.org/web/packages/sparklyr/index.html