standardize team on build environment

This issue references 2 PRs. Both are different approaches to help improve and speed up our build environment. The multi-stage Docker PR also attempts to standardize our actual development/build environment, so we're all on the same page.
Via Makefile: https://github.com/omisego/elixir-omg/pull/956
Via multi-stage Dockerfiles: https://github.com/omisego/elixir-omg/pull/979
I've seen many variations on our development environments:

All development with Docker
A VM running on Mac/Windows running some flavor of Linux
A rented out VPS running some flavor of Linux
Building and running some services on the native host while running other services in Docker

I think we should all be free to use the tools and toys we love. But I feel we need to standardize our development environments. On an individual level, some developers may be able to work faster with their own custom setup. But at the team level, we work slower. I want to get rid of the 'it works for me, but not for you` engineering smell.
With everyone using Docker, if something is broken then we will all feel the pain and it will be fixed ASAP. With individual setups, we may be unaware that there are existing problems.
I believe using Docker will help simplify things not only for us and our team velocity, but also for onboarding newhires, the open source community, etc...
Do we want to continue to manage several environments and ways of building things, including a mixing and matching of containers and bare bones, or do we want to stick with Docker only?
If we do want to standardize on Docker I'm open to any feedback on my PR.
If we don't want to standardize on Docker, alternatives are fine, but as a team, it is my hope we can decide to standardize on some common development environment.
All of this partly a matter of preference and neither approach is necessarily right or wrong, but clearly a team consensus for either approach is highly desirable.
Check out the PRs and let the code speak for itself! :smile:
If you made it this far, thank you for your reading! 🙏  Looking forward to hearing from everyone!

I have a counterpoint :wink: Since we’re an open source project and expect anyone to run these components (as oppose to SaaS deployment where we’re in control), itmight actually be better to have people running different environments, so that we can detect errors that are not found in Docker image (e.g. incompatible library versions).
Still, I think it’s good to have Docker as a baseline. The approach we use in ewallet is to have a builder image that has all dependencies require to build the application and use it for both building prod image and dev image (which has benefit of able to persist build artifacts, reducing the time to do mix release). Makefile is used for building: we’re not expecting everyone to use docker build to build the production artifacts (due to reason above) so make prod is the actual endpoint where building happens.
In ewallet we have docker-gen.sh which generates docker-compose.yml according to the use case, e.g. for evaluation purpose (which uses artifact from Docker Hub) or for dev (which uses builder image with volume mounts for build artifacts). Makefile+docker-gen has been working great for us across many different environments (especially me, who runs Ubuntu, FreeBSD and Mac depending on the phase of the moon).

I second @sirn because a large part of his work has been adapted into elixir-omg not only because it's great practice and as fast as it can be with the tools we have but also because it aligns us with ewallets deployment. Ewallet has been using the same process for the last year. So it's rather thoroughly tested.
And to chip in on Makefiles, our Makefile (and ewallets) is tested every CircleCI run.
In my opinion, #979 does not add anything new that we don't already have.
The problem with standardization (in this case) is two fold:

you can't force anyone to use something you think it's best (you can only declare what you support, but you can only deprecate things you made yourself). So declaring we don't support barebone releases is like saying we don't support vim. It's there whether you like it or not. :) and people will open files with them.
And forcing everyone to use docker is not a great experience. OSx and Docker are not the best partners either.

With the following weeks, we will all be able to run all services barebone with rapid build process as #956 implies. Which is going to be faster then any docker build, because of dev settings that releases support. But it's a work in progress and I just can't do everything at once. Also, the biggest issue with compiling here was rocksdb, but with 1.3.2, rocksdb supports hooking itself to local installations, making compiling it very fast.

Thank you @sirn and @InoMurko for your thoughts. I'd just like to respond to some things and then I'll step back for a while. I hope to hear back from you guys and hope others chime in as well.
@sirn

Since we’re an open source project and expect anyone to run these components (as oppose to SaaS deployment where we’re in control), itmight actually be better to have people running different environments, so that we can detect errors that are not found in Docker image (e.g. incompatible library versions).

Our production images are built from the Docker image. Why do we want to detect errors not found in the Docker image? If someone outside OMG found a non-docker bug would we then spend our time debugging it? If so, why?
I do agree that, anyone in the open source community are free to do whatever they please.
@InoMurko

it's great practice and as fast as it can be with the tools we have

No doubt we have a great team building great stuff. However, there's always room for improvement. The Docker community has something to say about our current practices. I recommend you guys read this Docker multi-stage page if you haven't already. It has many great tips that will help us.
It particularly points out a specific 'Docker smell' we currently have that has snagged me many times before:

When you run the build.sh script, it needs to build the first image, create a container from it to copy the artifact out, then build the second image. Both images take up room on your system and you still have the app artifact on your local disk as well.

Not only do the artifacts take up space (not a big deal), but if you forget to delete them they create unpredictable builds.

In my opinion, #979 does not add anything new that we don't already have.

It specifically adds 3 things we don't have:

A prebuilt image with our mix dependencies also built.
No build artifacts on local machine.
Smaller release images.

Regarding your 2 bullet points about standardization, I hear you. If people want to use vim or build our stuff however they want, let them do so. I don't like it when others tell me how to do things too.
However, with Docker we provide the easy path, the path of least resistance. Docker is our gold standard. We release to production with it. Internally why do we not want our team to standardize on it?
What are the benefits of not standardizing on Docker? Or not standardizing on anything for that matter?
The benefits of standardizing are a lot! Most importantly we save a lot of time and money. Engineering is huge cost center. Every time someone needs to go to you (my hand is raised)  or anyone else with environment problems/questions, that takes away from yours and others feature development time. That is very expensive time! If we can reduce interruptions to you and others this is 👍

Which is going to be faster then any docker build, because of dev settings that releases support

I'd like to know more about this when it is ready. I don't know how a build can be faster that a prebuilt image. The multi-stage Dockerfile proposal prebuilds our dependencies.

Our production images are built from the Docker image. Why do we want to detect errors not found in the Docker image? If someone outside OMG found a non-docker bug would we then spend our time debugging it? If so, why?

Unfortunately we did not live in a perfect world where everyone have access to Docker (e.g. BSD, macOS/Windows [where Docker works by running an agent inside a VM]). I don't think it's a good idea for open source project to have a hard dependency on Docker.
It's OK to have Docker as a baseline, but I don't think it works as a community project if we were to dismiss everyone who found a bug using non-Docker setup as "nope, you're on your own." I learn this the hard way during eWallet workshop in Neutrino Tokyo where one third of the room, who were enthusiastic about trying out eWallet, were left in cold because we couldn't support their platform of choice.

It particularly points out a specific 'Docker smell' we currently have that has snagged me many times before [..snip..]

I don't think the note about build.sh is relevant to us. We're not building the app as part of Docker's RUN (e.g. not using Docker as a data container), thus we did not have the "create a container, copy artifact" steps. Instead, it's mounting fs on top of Docker and writing directly to the filesystem, so no extra artifacts are created.
In current iteration, deps and _build are cached via external means, e.g. CircleCI cache, which allow us to build incrementally. Incremental build currently took less than 2 minutes where rocksdb compilation is the main bottleneck (which could be put into builder image).
Whether incremental build is a good or bad idea is another thing to debate, though. :wink:

Smaller release images.

10~19 MB decrease seems to come from other factor rather than the methodology of the final build step itself. The way it works should essentially be the same, e.g. copying .tar.gz artifact and extract it into a bare image. I think alpine 3.8 vs 3.9 might be playing some role (packages in 3.9 repo is slightly smaller than 3.8)

Since we’re an open source project and expect anyone to run these components (as oppose to SaaS deployment where we’re in control), it might actually be better to have people running different environments, so that we can detect errors that are not found in Docker image (e.g. incompatible library versions).

Our production images are built from the Docker image. Why do we want to detect errors not found in the Docker image? If someone outside OMG found a non-docker bug would we then spend our time debugging it? If so, why?

I'm gonna agree with Sirn here. This is open source, and you can't control what people will do with the project. As maintainers, it's our duty to ensure that our code can be used by anyone, on any platform. Sure, we won't be actually writing and testing the support for all of them right now, but people can submit issues and PRs when they're having trouble.
I think it's important not to lock ourselves in a standard that everyone has to follow and reject all the other options. We can have a recommended or preferred way of running things, but it shouldn't go past that IMO. Docker can be that recommended way, but personally I won't be using it for development because it's too much of a pain most of the time (if things can be ran without it). Still great for things like testing PRs! And the work @InoMurko is doing with #956 looks pretty yummy with its hybrid approach.
For how we do Docker, I don't have a super strong opinion, but things have always worked pretty well for the eWallet with the work @sirn did, so I don't really see a reason to do it any differently.

Docker can be that recommended way, but personally I won't be using it for development because it's too much of a pain most of the time (if things can be ran without it).

same here, well put. To me, being able to do daily development without docker getting in the way is a big advantage. Standarization is good, I'd very much like to avoid locking ourselves out of the possibility of developing without docker.

I think it's important not to lock ourselves in a standard that everyone has to follow and reject all the other options. We can have a recommended or preferred way of running things, but it shouldn't go past that IMO.

FWIW I found a lot of value building the application in Docker when I first started working with the project. It was nice having a 'clean' environment and building it consistently for me with it. This of course has changed over time as a lot of fixes have been pushed out to really hone down on building the application.
I agree this is open source and we should realize everyone has their preferred way to build it, the value docker has is still pretty great(especially since I'm not on OSX anymore) and I think @InoMurko's hybrid approach really meets it in the middle for building the application outside of it and leveraging docker to spin up the services the application relies on.

Thanks all for your thoughts and opinions.
The good news here is it seems like there is overwhelming consensus on the direction we want to head! 😄
I'll close this issue and this PR shortly. I guess we can consider this WIP a RIP #979
@InoMurko I still want to poke you about something though. We can still make a combined image which includes our prebuilt dependencies. How about we give that a shot?

Can't imagine how that would work, but will review a PR if you make one! :)

Scroll up! 😉  The PR is in this issue's description. #979  Specifically see the Dockerfile.omg-dev-env file.
We don't have to incorporate everything in the PR, but that setup was working very well for me.

@InoMurko

That only makes sense for development

For development the idea was developers using docker would use both Dockerfile.omg-dev-env and Dockerfile.omg-service-env. That's the developer world.
But if you continue along the Dockerfiles you'll see Dockerfile.omg-service-release. This uses the same Dockerfile pipeline and produces release images.
The command in the PR to build a release is (put into a Makefile of shell script of course is):
docker build -t omg-erlang-env --target omg-erlang-env - < docker/Dockerfile.omg-erlang-env \
  && docker build -t omg-elixir-env - < docker/Dockerfile.omg-elixir-env \
  && docker build -t omg-dev-env --target omg-dev-env -f docker/Dockerfile.omg-dev-env . \
  && docker build --build-arg SERVICE=child_chain --build-arg RELEASE_VERSION=0.2.2+ --build-arg SHA=`git rev-parse --short=7 HEAD` -t omg-service-env-child_chain -f docker/Dockerfile.omg-service-env . \
  && docker build --build-arg SERVICE=watcher --build-arg RELEASE_VERSION=0.2.2+ --build-arg SHA=`git rev-parse --short=7 HEAD` -t omg-service-env-watcher -f docker/Dockerfile.omg-service-env . \
  && docker build --build-arg SERVICE=child_chain --build-arg RELEASE_VERSION=0.2.2+ --build-arg PORT=9656 --build-arg SHA=`git rev-parse --short=7 HEAD` -t omg-service-release-child_chain -f docker/Dockerfile.omg-service-release . \
  && docker build --build-arg SERVICE=watcher --build-arg RELEASE_VERSION=0.2.2+ --build-arg PORT=7434 --build-arg SHA=`git rev-parse --short=7 HEAD` -t omg-service-release-watcher -f docker/Dockerfile.omg-service-release .

There's also the issue of invalidating the image if mix.lock changes.

That's correct. My intention was that we would use CircleCI or something to publish a new 'dependency' image to omisegoimages whenever a dependency changes.

If I imagine this correctly, this would make the deployment pipeline faster, because it doesn't need to build deps?
So the step where we build a release is this:
docker-watcher-prod:
	docker run --rm -it \
		-v $(PWD):/app \
		-v $(IMAGE_BUILD_DIR)/deps:/app/deps \
		-u root \
		--entrypoint /bin/sh \
		$(IMAGE_BUILDER) \
		-c "cd /app && if [[ OSX == $(OSFLAG) ]] ; then make clean ; fi && make build-watcher-prod"

So instead of mounting the local dir -> -v $(IMAGE_BUILD_DIR)/deps:/app/deps \ you would pull the image with prebuilt deps (let's say the image tag is a checksum of mix.lock). Have I summarized you correctly, @jrhite ?

@InoMurko yes, this is correct.

Hm... They only need to be built once, since the build files are stored on your local HD. But if you think this is a pain for devs I'm here to give you my full support!

Hey all. Late to the party here because I've been away. Let me give my two gwei.
Firstly it's great to see so many opinions on this. It means people are passionate and want to make the development process better for everyone. I like that we have a range of technical solutions being proposed here but I feel this conversation has lost sight of something important. So let's step back from implementing the tech and tooling for a moment and look at what we're trying to achieve.
We're in the business of providing open access financial services for everyone. The way that we're doing that is by providing APIs to third parties to build on. We don't expect the open source community to be contributing to the development of elixir-omg. And to date this year we've had two contributions from third parties. One of these contributors is now working for us. So while I appreciate the empathy for development on a range of different platforms and different users, the data isn't showing us that we need to be building tooling to support this range of environments.
Secondly, two partners are either building or hosting their own Watcher. At least initially we're not expecting people to run their own Childchain instance. So the real world usage of our services adds weight to the point that we don't need to support a range of platforms. This means we can be somewhat selfish and build the tooling we need to suit our requirements at OmiseGO.
In terms of support, nobody is own their own. We have an established channel for supporting integrators via the ODP, and we've received good feedback from partners on the speed and quality of the support given to date.
I generally agree with @T-Dnzt's point about allowing code to be run by anyone, but we're not a standard three tier application. We run time dependent distributed systems which I think is the core of this problem. This means the infrastructure for local development is as much of a problem as the code itself.
As for how we achieve this I'm open to discussing.


Add ClusterChecks deployment template

What this PR does / why we need it:
Add the possibility to run dedicated agent(s) for handling the
Cluster Checks process. It allows having dedicated resources
request/limit for the Cluster Checks.
Which issue this PR fixes
Special notes for your reviewer:
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

@xvello, thanks for your review, I updated the PR according to your comments.

/ok-to-test

/lgtm


Add video to pop-up when clicking on a representative argument

Repro steps

Go to https://tttc-turbo.web.app/report/heal-michigan-7-adjusted-backup-final (or any report with video)
Under Employment Barriers, click "Returning citizens from affluent backgrounds may have..."
The Quote pop-up opens

Expected behavior
The video should display under Interview
Actual behavior
Only the quote and interview name are displayed.

To match from the circles, the video would be after "Interview", but I propose we change that in both places and have the order be:
Claim (if present)
Quote
Video
Interview
@colleenm leaving this greater change out in case you have other ideas

no strong opinions, I like having the person's name above the video but fine either way

We will leave as it

Fixed in PR #62 .


feat(service): Add line service

Changelog:

Add line service implementation
Add line service on main readme
Add line service usage example

Closes: #27

Hey @yoelsusanto, I just wanted to check in and see if maybe you need help with something or one of my instructions might not be completely understandable. Just let me know if I can help you in any way.

Hey @yoelsusanto, I just wanted to check in and see if maybe you need help with something or one of my instructions might not be completely understandable. Just let me know if I can help you in any way.

Hi @nikoksr, your instruction has been clear. I just added your requested changes. Let me know if you need anything else.


iris.plot does not always plot cloud base/top extent correctly

🐛 Bug Report

iris.plot does not always plot cloud base/top extent correctly. The plotted region is sometimes less than it should be.
How To Reproduce
Steps to reproduce the behaviour:

cube=iris.load(cloud_base_file)
contour_levels = np.linspace(0.0, 8000.0, 9.)
cf = iplt.contourf(cube[0], contour_levels)
plt.show()

(Example cloud base file is in /scratch/fpdh/CB/20210819T0600Z/20210819T0000Z_T+06_CB_base_test1_as_height.pp;
example cloud top file is in /scratch/fpdh/CB/20210819T0600Z/20210819T0000Z_T+06_CB_top_test1_as_height.pp)
Expected behaviour

Cloud base field extent should be the same as cloud top field extent. (Independent testing and plotting with matplotlib.pyplot confirms that this should be the case).
Actual behaviour
Cloud base field extent is less than cloud top field extent.
When plotted with matplotlib.pyplot, the extents are the same.
(See example plots; plt=plotted with matplotlib.pyplot,  iplt=plotted with iris.plot)
Screenshots

Environment

OS & Version: [e.g., Ubuntu 20.04 LTS]
Iris Version: [e.g., From the command line run python -c "import iris; print(iris.__version__)"]
RHEL7
python-3.4.10
iris-2.4.0 (from scientific software stack - default-current environment)

Additional context

Click to expand this section...
Please add additional verbose information in this section e.g., code, output, tracebacks, screenshots etc

![Figure_1](https://user-images.githubusercontent.com/89387305/137705611-2b6f3774-0838-4f20-a272-83ac2c43bfba.png)

From a bit of investigation, I think that this is being caused mostly (if not completely) by the antialiasing in iris.plot.contourf. I'm not too surprised that this issue is present in iris-2.4.0 given significant improvements were made in iris-3.1 (see https://github.com/SciTools/iris/pull/4127, https://github.com/SciTools/iris/pull/4150, https://github.com/SciTools/iris/issues/4086 and https://github.com/SciTools/iris/pull/4263).
However, I'm able to reproduce this in iris 3.2.dev0, suggesting there's an edge case that this data is hitting. Note that the matplotlib and "fixed" iris plots are not identical - there are ~1 pixel differences in various places.
matplotlib.pyplot.contourf

iris.plot.contourf

iris.plot.contourf (with undocumented kwarg antialiased=False)

@rcomer, as the person who last fixed some antialiasing, any advice before I look further as to what might be the culprit?


Inconsistency in recognizing offsets in disassembly

I have two binaries, one is a newer version of the other. I'm trying to port my findings from the old binary to the new one.
Anyway, why is it that Ghidra is able to recognize offsets on the right (old binary) but not on the left (new binary) even though it's the same disassembly (with some offsets moved)?

This prevents me from finding references to an offset in the new binary.

are those memory addresses labeled in memory if you goto them (either default name or custom)?
do those memory addresses show up in the decompiler?
how much manual analysis did you do in the old and how much manual analysis did you do before/after auto-analysis (and how often did you do auto)?
not pertaining to your issue really on why it didn't catch the labels it in the newer but did you try the versioning tool?

Those memory addresses are indeed valid and they show up in the decompiler.
I barely did any manual analysis (function start finder) after the auto-analysis was completed.
Also, no, I don't think I used such tool.

I don't know if this matters or not, but the old binary's data was from an xml exported from IDA.
However, the new binary was imported using Ghidra's ELF importer.


Strange character being added to the end of xml files

Hi,
I use xml files in my project and I get the char "" appearing intermittently at the end of the file.

I'm using HaxeDevelop x86 v<IP_ADDRESS>

Please try development build from https://flashdevelop.org/downloads/builds/

Unfortunately It's still happening with the latest development build.  After some more testing it looks like the char is added when HaxeDevelop is first opened and the file is open in the editor, but it only happens to some of the XML files.
Here is a gif of me opening HaxeDevelop and the char is at the end of the file, I delete the char, save and quit HaxeDevelop. Then when I re-open HaxeDevelop the char is there again.


"Debranding" CONTRIBUTING.md

Currently https://github.com/aurora-website/website_v1/blob/source/CONTRIBUTING.md seems to have lots of references to https://github.com/github/docs that should probably be removed!

Indeed, I actually haven't edited the CONTRIBUTING.md or rather had the time to rewrite it completely. I know, sounds like a lame excuse but I had many things at hand. It's in the works so look forward to the next commmit, or you could also contribute! :D

Haha, yes, well I considered doing a PR, but it seemed a bit presumptuous of me to edit contributing.md as my first contribution!


feat: support fees from Balancer V2

This PR adds support for Balancer V2 along with the new Polygon deployment. I'm afraid I don't have a key for Covalent so I can't check that the Polygon deployment is displaying correctly but it should be fine.

Looks great, thanks @TomAFrench!


echo is missing the -e option

https://github.com/sandstorm-io/ekam/blob/master/Makefile#L34
The -e option allows echo to interpret \n, \t, etc. So use echo -e "======\nSUCCESS\n=====" instead.

Do you observe the output being incorrect on your machine? If so, what distro?
-e is actually a non-standard option implemented by Bash. make invokes /bin/sh which on Debian-derived distros is actually Dash, not Bash. Dash's echo does not support -e (it will literally print -e if you try to pass this flag), but it interprets escapes by default (POSIX unhelpfully leaves it implementation-defined whether escapes are interpreted by default). So using -e here would actually produce incorrect output, whereas currently it is correct (on my machine).
Weirdly, on OSX, where /bin/sh is actually Bash, when invoked as sh it exhibits Dash-like behavior in this respect, but on Debian if I symlink /bin/sh to bash I get Bash behavior even when invoked as sh. So I suppose if you're using a distro where /bin/sh is Bash, you might see the wrong output?
Sadly, using /bin/echo won't solve this problem as on some platforms (OSX) it does not implement -e either.
So -e definitely won't work, but my current solution works on all machines I own. If it doesn't work on yours, maybe I just need to write multiple echo statements.

I'm running Arch Linux which has its /bin/sh symlinked to bash. And you're right, it looks like -e is a BASH-specific option. On a Ubuntu system running /bin/sh symlinked to dash, it works without the -e option.
Supposedly, running bash with the program name sh will cause it to use set -o posix to enable more posix-like features. But alas, this still doesn't fix echo's behavior across all systems.
There are threes ways I think this could be fixed:
a) Break up the echo into multiple calls.
b) Use printf instead, e.g. printf "=====\nsomething\n===== works fine
c) Detect what shell is running with sh --version, then set a variable ECHO to either echo or echo -e and use `$(ECHO) "====\nsomething\n===="
Honestly, I don't think it's worth the effort but if you really wanted it to look the same on all systems, I would go with printf. That would require minimal changes.

Oh, duh, printf! I actually figured this out once before and then forgot -- the Sandstorm Makefile only uses printf for exactly this reason. Durr. Thanks for the reminder.

Ahh, no problem. :grimacing:


Mounted pgadmin storage to host machine

I believe a lot of people might use this to get up and going quickly. PGAdmin saves files locally, in the respective docker volumes. I think it would be a good idea to mount the storage to the machine, such that queries can be added and saved seamlessly.

LGTM. Thank you.


Use Navigator.prototype for GPC signal injector

This fixes #855.

Reviewer:

Description:

Steps to test this PR:

Automated tests:

[ ] Unit tests
[ ] Integration tests

Reviewer Checklist:

[ ] Ensure the PR solves the problem
[ ] Review every line of code
[ ] Ensure the PR does no harm by testing the changes thoroughly
[ ] Get help if you're uncomfortable with any of the above!
[ ] Determine if there are any quick wins that improve the implementation

PR Author Checklist:

[ ] Get advice or leverage existing code
[ ] Agree on technical approach with reviewer (if the changes are nuanced)
[ ] Ensure that there is a testing strategy (and documented non-automated tests)
[ ] Ensure there is a documented monitoring strategy (if necessary)
[ ] Consider systems implications

Heads up @dharb I know we discussed this quite some time ago.


feature request: fancy box

a fullscreen lightbox would be a nice add-on.
http://fancyapps.com/fancybox/

Wouldn't the license be an issue? http://fancyapps.com/fancybox/#license
Of course, there are other lightboxes, but I wouldn't know which one to pick.

The older version is licensed under MIT/GPL.

well I was really pleased with shadowbox… but development has been stopped.
http://www.shadowbox-js.com/ And it had a license as well.
Any other suggestion of good decent lightbox's?
A good Lightbox should have scalable media (video, images, maps, iframe content, etc…) I think.
And be compatible with mobile.

Shadowbox has a custom non-commercial license and seems to use components which are also not FOSS licensed.
Simple Modal is another modal plugin, but it is not a typical lightbox.

@jeduan Reveal is not fullscreen, and only supports displaying content that is (hidden) inside the page. Fancybox and the other tools mentioned here are all full-featured lightboxes, not simply fancy dialogs.

If I'm getting this right, what you are looking for is a way to easily embed external content like the Youtube demo from http://fancyapps.com/fancybox/demo/ ?

My primary need is loading AJAX content into modal dialogs.

Yeah, stumbled on that, too.
I used the code below to achieve that. Hopefully it will be useful for you.
https://gist.github.com/1775746

Thanks, that is very helpful.

Thanks Jeduan, it's very usefull !


Make it easy to find out the k8s and flux version - UI

The UI counterpart to #2285
See full acceptance criteria in the linked issue.
Acceptance Criteria

When I open Weave GitOps I see the version of Weave GitOps that is running on the footer with the same behavior as today.
To the left of the Weave GitOps version I will see the flux versions as flux: v0.20.0.
To the left of the Flux version I will see the k8s: v1.23.0.

Design, provided by @JamWils

@opudrovs here is a quick design for you.  I think we're going to need to make a dedicated settings page in the app moving forward for some of this data.

@JamWils added version numbers with styling consistent with the current project styling and based on the quick design. If some changes are required for more precise styling (for example, to make the text lighter) I would need a Figma design.


Stats report is using system created date instead of migrated created date

The stats report is not looking at our migrated field, but must be looking at the actual system creation date.
This is ok, except when we migrate data.  This morning we got a report that 7324 items were uploaded last week.

override the date being queried by sophia w/ our migrated date

If we change system_create_dtsi  to date_uploaded_dtsi in Sufia::QueryService, that should give us what we want.

The stats page isn't rendering because of:
NoMethodError: undefined method `[]' for nil:NilClass> - "/opt/heracl
es/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/sufia-7.4.1/app/services/sufia/statistics/term_query.rb:26:in `query'"

Maybe we can fix that so we can have a good feature test of the stats page that demonstrates the issue is resolved?


Quality factor without ground truth?

Is it possible to have some kind of quality factor to quantify if the object is being tracked accurately? For us, ground truth is not available all the time this means that we cannot calculate the ADD values.
I was wondering if one could use your (from paper) Energy equation to calculate some kind of quality factor which can be just used as an indicator and not as a hard truth of a good object matching/tracking.
Great job btw, really impressive and innovative work!! Thank you for this and thank you in advance for your kind help.

I think it is a major limitation of this work, that you actually cannot easily calculate a quality factor.
The relevant measures are implicitly available in the Hessian and gradient equations, but more work is needed to get to a quality "probability" from there..

While it is not implemented, it would be straightforward to compute the joint probability. In general, all information for this is available in the CalculateGradientAndHessian methods of the region, depth, and texture modalities (for the region modality, just use the data_line.distribution value at 0, and for the depth and texture modalities compute the probability using epsilon or error together with the standard deviation values). Like for gradient vectors and Hessian matrices, one can compute the joint probability for each modality and later combine those values in the Link object.
In addition to using the joint probability as indicator for the tracking quality, one could of course also think about other factors, such as the percentage of measurements with a certain quality, etc. In general, I would encourage you to just play around with different options and see what works best.


Update new issue management approach and remove daily build config

Purpose
$subject please

Shall we remove daily build badge as well?


Offline Capabilities

FirebaseDatabase has setPersistenceEnabled(true), and keepSynced for reference or query.
If geofire support this?

GeoFire does work with persistence but there is no option to use keepSynced on a GeoQuery.


VM Power On

[ ] I am using the latest SDK version
[ ] This API is compatible with my vCenter version (You can get the info from 'vcenter_version' in each sample)
[ ] I have searched existing issues and Troubleshooting wiki

Environment

sdk package version:

python version:

vSphere version:

Operating System/Shell (used to run SDK-based apps):

Steps or code snippet to reproduce
 From this sample
 # Power on the vm
    print('# Example: Power on the vm')
    client.vcenter.vm.Power.start(vm)
    print('vm.Power.start({})'.format(vm))

Actual behavior
there is no operation start in guest_client.py
Expected behavior

@tahamian Can you elaborate what's the issue and what is the expectation?

oh, I was just thinking if we use
from vmware.vapi.vsphere.client import create_vsphere_client

and create a connection, we can use the client  connection to power on the VM, but if we use
from com.vmware.vcenter.vm.guest_client import Power

and try and create a stub config, there is way to power on the VM,
from guest_client.py
 operations = {
            'get': {
                'input_type': get_input_type,
                'output_type': type.ReferenceType(__name__, 'Power.Info'),
                'errors': get_error_dict,
                'input_value_validator_list': get_input_value_validator_list,
                'output_validator_list': get_output_validator_list,
                'task_type': TaskType.NONE,
            },
            'shutdown': {
                'input_type': shutdown_input_type,
                'output_type': type.VoidType(),
                'errors': shutdown_error_dict,
                'input_value_validator_list': shutdown_input_value_validator_list,
                'output_validator_list': shutdown_output_validator_list,
                'task_type': TaskType.NONE,
            },
            'reboot': {
                'input_type': reboot_input_type,
                'output_type': type.VoidType(),
                'errors': reboot_error_dict,
                'input_value_validator_list': reboot_input_value_validator_list,
                'output_validator_list': reboot_output_validator_list,
                'task_type': TaskType.NONE,
            },
            'standby': {
                'input_type': standby_input_type,
                'output_type': type.VoidType(),
                'errors': standby_error_dict,
                'input_value_validator_list': standby_input_value_validator_list,
                'output_validator_list': standby_output_validator_list,
                'task_type': TaskType.NONE,
            },

its just kind of inconsistent, shouldnt we be able to power on VM using the both methods of connection?
Thats all i was trying to point out

sorry this i realized what I was trying to do, I was trying to use the stub configuration for Power,
from com.vmware.vcenter.vm.guest_client import Power

and after looking at the api documentation, there is no way to power on the VM, but that is not the case if we use
from vmware.vapi.vsphere.client import create_vsphere_client

we are able to power on the VM, thought it might have been an inconsistency, but the api does not allow to power on vm.
Thanks


java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;

Covariant return breaks runtime compatibility with Java 8.
Adding casts to source code fixes this issue.

java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;

According to Felix:
https://github.com/apache/felix/pull/114
Java 9 introduces overridden methods with covariant return types for the following methods in java.nio.ByteBuffer:
position(int newPosition)
limit(int newLimit)
flip()
clear()
mark()
reset()
rewind()

In Java 9 they all now return ByteBuffer, whereas the methods they override return Buffer,
resulting in exceptions like this when executing on Java 8 and lower:
java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer
This is because the generated byte code includes the static return type of the method, which is not found on Java 8 and lower because the overloaded methods with covariant return types don't exist (the issue appears even with source and target 8 or lower in compilation parameters).
The solution is to cast ByteBuffer instances to Buffer before calling the method.

Also two abstract methods were added to Buffer in Java 9:
slice()
duplicate()
Which return Buffer, and are also implemented by ByteBuffer in previous versions of Java, but return ByteBuffer.
The solution in this case is to cast to ByteBuffer before calling these two methods.

Refer to Issue #141
Array types need to remain as ByteBuffer [] for compatibility reasons, as array types cannot be cast to supertypes, eg ByteBuffer [] cannot be cast to Buffer [], casts can be performed outside of arrays.  #141 was created by the changes made here.

It turns out that this is a suboptimal solution to this problem, the OpenJDK team created a new complier flag for later Java platforms, to generate Java 8 compatible bytecodes.  We should use the release compiler flag, instead of the source target flags.

8


Processing gateway event error: failed to decode Protobuf message: buffer underflow topic="eu868/gateway/ac1f09fffe0cac0b/event/up" qos=2

Processing gateway event error: failed to decode Protobuf message: buffer underflow topic="eu868/gateway/ac1f09fffe0cac0b/event/up" qos=2

I'm closing this issue. This is not related to the Docker Compose example. As well, the issue contains no details on how to reproduce the issue.


Using a script to render the markdown for 'private' portion of API doc

Hi,
I have certain endpoints in my API that are private / that I do not wish to have on the root page of the docs, but rather on a separate url. I have marked every endpoint as (private) in Markdown, is there any way to parse this notation (either when it's in Markdown or HTML), and then make those HTML divs "invisible" in one page and visible in another one?
I was wondering if you have any tips on how to implement this with Slate. Any script libraries I could tack into /javascripts? I'm sorry if this is kind of a really general/broad question, as I'm pretty new to this.

Hmmm...if you create a partial in source/includes/_foo.md.erb you can use syntax in this file like
<% if current_page.url = '/meow.html' %>
  secret stuff to only display on meow page
<% end %>

Then, in two files, index.md.erb and meow.md.erb, just list foo in the includes list. Does that work for you?
I'm going to close this because it's a question, but feel free to continue commenting and let me know if this works, or if you have follow up questions!

I was not aware that partials could be extended to md.erb files, and your solution solves my problem very efficiently. Thank you so much!

:+1: no problem!

@lord is this possible with current version? On Ruby 2.4 the conditional current_page.url seem invalid


Unreachable code

xcb: v1.4.0
My program is panicking with the following message:
thread 'main' panicked at 'internal error: entered unreachable code: Could not match extension event.
I put some logs in the file error.rs, and the extension that has raised the error is the render extension.
The render case is clearly missing in the match expression in version v1.4.0, but it seems that this has been fixed in the main branch.
Is there a plan tol deliver a new version of the crate?
Thanks

v1.5.0 is published


The requested module '../../axios/index.js' does not provide an export named 'axios'

I am manually upgrading polymer 2.0 project to 3.0 one. I replaced 'link' with 'import',  *.html with *.js and bower.json and bower_components with package.json and node_modules.
But when I ran 'polymer serve', I got this problem. What can I do?

And in the cmd window, I could see this note. Can you let know how to handle this, too?

My npm version is 6.2.0
polymer is ^3.0.0-pre.21
axios is ^0.18.0
Please, help me...
In polymer 2.0 script it was coded like this

And I changed it
import {axios} from "../node_modules/axios";

Polymer CLI does not accept CommonJS modules, only ES modules.
Consider using Webpack instead, or use this module as a workaround:
https://github.com/bundled-es-modules/axios

I used axios-es6 instead of axios, but error is the same.
The requested module '../../axios-es6/dist/axios.min.js' does not provide an export named 'axios'

@vtolkanov axios-es6 is not an ES module, as it is compiled with Webpack to UMD bundle.
You will basically get the same error when attempting to load any UMD module with Polymer CLI.
By the way, Polymer CLI has its own AMD loader which defines window.define but not window.define.amd thus making impossible using of UMD modules even for es5-bundled build.
In case you are interested, here is an example of using Polymer 3 with Webpack:
https://github.com/web-padawan/polymer3-webpack-starter

Thank you for your kindness! I am very new to polymer 3, so I have so many trouble. Plz, help me.

Hi, honestly no idea. Depends on how you include the script. You should be able to exclude it frim minifying, it could be the reason.

I've solve this problem, as you said. And now it works.  Also, next time please submit any issues related to the tooling (including polymer serve) to https://github.com/Polymer/tools repo, and you can also ask questions in the Slack channel.

Closing per https://github.com/Polymer/polymer/issues/5342#issuecomment-415958751 Amazing help @web-padawan :tada:

hey @vtolkanov how did u fix the problem with Axios, did u find an es6 module version? we are using pure polymer cli setup witout webpack and want to keep it in that way but still wanna use axios client
Thanks in advanced

As mentioned above there is ES module here but not sure if it has been published to npm (as far as I know its maintainers are still on bower): https://github.com/bundled-es-modules/axios

Oh thanks @web-padawan I was confused thinking that that link above was just a rollup.config.js config file.

Hi, if external js does'nt support es6 module simply you can add the js into script and import the script into index.js


Feature: Build and release in GitHub Actions

I'm not sure if auto release working

No packaging yet


 When I tried to use the creep cube in the overworld it cause huge server lag and then the owner said we now have two ends and two nethers

um... There is no way to have two nethers or ends. How did the owner end up to that conclusion? Also MeeCreeps doesn't do anything with dimensions at all

Oh well maybe it was something else idk just trying to do my part

Sorry

But it did cause huge serve side lag for everyone. That I know Bc everytime I used it everyone would say wow that lag spike. And it was to perfectly timed to be coincidence everytime

Can you describe exactly what you were doing with the MeeCreeps?

I right clicked the ground to summon the meecreep and the server spiked

That's weird. Also MeeCreeps have been used a lot on servers and I never had a report like this. Can you reproduce that lag? i.e. does it happen every time you summon a meecreep?

Well the owner banned the item but it happened several times in a row. Maybe it’s bc of their server plugins he has or something. It isn’t a private server for me and my friends. It’s a public white list server

Having this happen too, It's spawning dimensions.

How can you see there are two nethers actually? Where does that manifest itself?


Mr

Azure documentation issue guidance
Thanks for opening an issue in the Azure technical documentation repository.
We use GitHub issues as the primary channel for customer and community feedback about the Azure documentation.
Creating an issue
We prefer that you create documentation feedback issues using the Feedback link on the published article - the feedback control on the doc page creates an issue that contains all the article details so you can focus on the feedback part.
You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
[ ] A link to the published documentation article that you have feedback about.
[ ] Clear, specific feedback that the author can act on.

Pull requests and article contributions
If you know the change that is needed in an article, we encourage you to submit the changes directly using a pull request. If the change is large, or if you want to contribute an entire article, follow these guidelines:

[ ] Don't surprise us with a big pull request or a pull request with a new article! Submit an issue that describes the details of the proposed large change or new article.
[ ] Include the service or technology area.

We'll route the issue to the appropriate content team for review and discussion.
Tech support and product feedback
If you would like to contact Microsoft about other things, such as product feedback or tech support, please review these guidelines:

If you need technical support using Azure, the paid and free support options are described here: https://azure.microsoft.com/support/options/.

Each article in the Azure technical documentation contains a product feedback button - it's best to submit product feedback directly from a relevant article. Otherwise, you can submit product feedback for most Azure products in the following product feedback forum: https://feedback.azure.com/forums/34192--general-feedback.

@MarkPhillips00763 Thanks for reaching out. In order to best address your question, could you provide us with the URL of the MS Doc that you were following, if any?

@MarkPhillips00763 Any update here?

@MarkPhillips00763 We will now proceed to close this thread, but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Resolve repo sync error in PR 683

Delete two files that are deleted and correctly redirected in master in the private repo, to resolve a merge conflict in https://github.com/MicrosoftDocs/cloud-adoption-framework/pull/683.

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

Looks good; merging.


Badges are broken

Several of the badges are broken:

@lcortesg Can you make the v0.0.4 realease?

@aweinstein Yes! but first I would need the changes of PR#93 merged into main to do it via CI


Design BD structure

Design and describe BD structure using any suitable application and pin the result to this task.
Our web application should provide 4 different functions for users:

Show news. Each news object should have a title, description, and one or many images. Users should be available to like and dislike news.

Provide a catalog of different products. Products should be divided into subcategories, which in turn should be divided into categories. Each product should have a name, description, characteristics (as a text field), and price. Authorized users should be allowed to save products into the cart and to create orders from products stored in this cart.

Users should be able to view and create advertisements for the purchase/sale of real estate. Each advertisement object should have a title, description, type (purchase/sale), one or many images, coordinates (latitude and longitude) for google maps, address, owner contacts, price (owner should be able to set any concrete price or value that mean negotiated price) and link to the user - owner.

Users should be able to view and create advertisements for the provision of any services. Each advertisement object should have a title, description, contacts, price (as text field, to allow the user to indicate the price and calculation method. E.g. '10$ each hour' or '100$ for one day', or '30 BYN per square meter') and link to the user - owner.

User data should be stored in two tables: main user table with, email (as username), password hash, is_activated flag (the only user that confirmed email can use it's account), is_deleted flag (to not remove deleted users from DB), account_type (to implement different permissions), registration_date and any other technical info.  Additional profile table should store personal info: phone, first name, last name, middle name, address, date of birth, sex, photo, etc.

Made a draft of db structure.
Came up with solution to the problem of different filters for different product categories, though it requires db level typecast, so it might become even more of a problem. We'll probably end up not using it. In this case we just need to drop "ProductSpec" and "CategoryProperty" tables.
I've got some questions about real estate purchase/sale announcement and service announcement details, but it'd be better to discuss in Skype.

Made a complete DB structure diagram.


Verify generated stuff in CI

trying this out to see if it catches the current issue

#11031

@ixdy jenkins should not be passing this

Why shouldn't it be passing it? It doesn't run anything in the Travis or Shippable configs.

Jenkins, Shippable, etc should all run verify-generated-*, which is failing
at HEAD.
On Thu, Jul 9, 2015 at 5:49 PM, Jeff Grafton<EMAIL_ADDRESS>wrote:

Why shouldn't it be passing it? It doesn't run anything in the Travis or
Shippable configs.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11032#issuecomment-120187574
.

Jenkins only runs the e2e tests and nothing else right now.

We should fix that? Not sure

I like the way it is. Jenkins is fast since it doesnt duplicate the checks that shippable is already running.

This is ready for review - who knows anything about shippable?  The fact that shippable failed here actually means success because the build is broken in this branch.

@wojtek-t

This looks fine to me, though I'd actually like to see everything passing. Shippable bails after the first thing that fails, which in this case is ./hack/verify-generated-conversions.sh, so none of the rest of the tests are running. I'd like to see it all pass before merging, ideally.

rebase - now that you saw it fail and the CI breaking error is fixed, it should pass.

Given that shippable is taking 2+ hours to run tests, remind me why we don't want Jenkins to do it?

This is green now

LGTM

Nobody wants to take responsibility for OKing this ? :)  rebased and pushed again, and I'll self merge

This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a temporary error. The following address(es) deferred:
<EMAIL_ADDRESS>Domain eikaas.no has exceeded the max emails per hour (34/30 (113%)) allowed.  Message will be reattempted later
------- This is a copy of the message, including all the headers. ------
Received: from o6.sgmail.github.com ([<IP_ADDRESS>]:42499)
by cpanel30.proisp.no with esmtps (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.85)
(envelope-from<EMAIL_ADDRESS>id 1ZEhbV-0021NB-Ey
for<EMAIL_ADDRESS>Mon, 13 Jul 2015 19:33:27 +0200
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=github.com;
h=from:reply-to:to:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe;
s=s20150108; bh=UHOGXP+Up48jm8CFXgw7RCA8SBc=; b=s8+IcZHxAbmrqnPD
iw47WZju8KwmfHdrdNXCzrO6Od9vy8dl0mtu+yF9+tHjWHZ05s595qsqgh+6+5nw
lJGFm7160t6AOXwFm/3Py6AUtHQCPLx5kZHDAS9b5eFMWG0wNFYL8ptbx0vrJFwZ
Zo7F7IzIW9ldhs9yvM8bPbzebuI=
Received: by filter0814p1mdw1.sendgrid.net with SMTP id filter0814p1mdw1.2498.55A3F65C19
2015-07-13 17:33:16.915641742 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [<IP_ADDRESS>])
by ismtpd-020 (SG) with ESMTP id 14e887a5a9c.1b33.21d218
for<EMAIL_ADDRESS>Mon, 13 Jul 2015 17:33:16 +0000 (UTC)
Date: Mon, 13 Jul 2015 10:33:16 -0700
From: Kubernetes Bot<EMAIL_ADDRESS>Reply-To: GoogleCloudPlatform/kubernetes<EMAIL_ADDRESS>To: GoogleCloudPlatform/kubernetes<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>In-Reply-To<EMAIL_ADDRESS>References<EMAIL_ADDRESS>Subject: Re: [kubernetes] Verify generated stuff in CI (#11032)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_55a3f65ca7061_45993fa4d4f892c0155084b";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: k8s-bot
X-GitHub-Recipient: eikaas
List-ID: GoogleCloudPlatform/kubernetes
<kubernetes.GoogleCloudPlatform.github.com>
List-Archive: https://github.com/GoogleCloudPlatform/kubernetes
List-Post<EMAIL_ADDRESS>List-Unsubscribe<EMAIL_ADDRESS>https://github.com/notifications/unsubscribe/AF9fZ9MyAuvApydlYxyuuhayRXO3QyQ0ks5oc-3cgaJpZM4FVt6U
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address<EMAIL_ADDRESS>X-SG-EID: D8AxvQssagt16ZlBezT4ZE8ej34nUdhd0RF2VqeF0hxYEFYO0d7q5FNqe077Vf0TelGDWtxokO7IDV
gCKY4y3UEgf0ICvT9tJYrdzER+2jL3VbGsgGNuJxTT/W77Ldkr0S35l8e9mTmMNLO/DITRS+8V9aBD
4vficKcJWUnGCMc=
X-Spam-Status: No, score=-1.3
X-Spam-Score: -12
X-Spam-Bar: -
X-Ham-Report: Spam detection software, running on the system "cpanel30.proisp.no",
has NOT identified this incoming email as spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
root@localhost for details.
Content preview:  GCE e2e build/test passed for commit 8dff1b5e346093b64dd59f6ea78f15a532bdbf7b.
* Build Log
* Test Artifacts
* Internal Jenkins Results
[...]
Content analysis details:   (-1.3 points, 4.0 required)
pts rule name              description

0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: github.com]
-0.0 RCVD_IN_MSPIKE_H4      RBL: Very Good reputation (+4)
[<IP_ADDRESS> listed in wl.mailspike.net]
-0.3 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.0 HTML_MESSAGE           BODY: HTML included in message
1.1 HTML_IMAGE_ONLY_16     BODY: HTML: images with 1200-1600 bytes of words
-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
-0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Spam-Flag: NO
----==_mimepart_55a3f65ca7061_45993fa4d4f892c0155084b
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
GCE e2e build/test passed for commit 8dff1b5e346093b64dd59f6ea78f15a532bdbf7b.

Build Log
Test Artifacts
Internal Jenkins Results

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/pull/11032#issuecomment-121000402
----==_mimepart_55a3f65ca7061_45993fa4d4f892c0155084b
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
GCE e2e build/test passed for commit 8dff1b5.

Build Log
Test Artifacts
Internal Jenkins Results

—Reply to this email directly or view it on GitHub.

----==_mimepart_55a3f65ca7061_45993fa4d4f892c0155084b--

LGTM

What's the value of having all of these steps broken out separately in the test configs vs. just running one script that runs all the checks and tests? The latter would make it easier for developers to do exactly what shippable does.

I made the smallest possible change, though I agree


Error For Dice Score

Under certain circumstances, the parsing of the results of the dice score command result in an error:
Computing DC between the two images with 'plastimatch dice --dice'
... Done.
Traceback (most recent call last):
  File "/app/src/main.py", line 69, in <module>
    compare(src_path, ref_path, report=report)
  File "/app/src/main.py", line 34, in compare
    file_checker.compare(src_path, ref_path)
  File "/app/src/checks/FileCompare.py", line 25, in compare
    entry = check(src_path, ref_path).run()
  File "/app/src/checks/FileCompare.py", line 66, in run
    raise e
  File "/app/src/checks/FileCompare.py", line 63, in run
    check_passed = self.check()
  File "/app/src/checks/ImageFileCheck.py", line 37, in check
    return self.check_dice()
  File "/app/src/checks/ImageFileCheck.py", line 64, in check_dice
    dice_summary_dict = pypla.dice(
  File "/usr/local/lib/python3.8/dist-packages/pyplastimatch/pyplastimatch.py", line 171, in dice
    float(str(dice_summary[1]).split("\\t")[3][:-2])]
ValueError: could not convert string to float: ''

The error is caused by this line for an output that looks as such:
dice_summary = [b'CENTER_OF_MASS', b'ref\t       1.37534\t       13.5159\t       23.6297',
                b'cmp\t       1.37534\t       13.5159\t       23.6297',
                b'TP:        182496', b'TN:       3580704', b'FN:             0',
                b'FP:             0',
                b'DICE:      1.000000',
                b'SE:      1.000000', b'SP:      1.000000'
]

The error seems to be that [:-2] on 0 effectively returns an empty string which then causes the float type casting to fail with the above error.
@denbonte can you elaborate what purpose the [:-1] is / was meant to serve and weather it's save to remove?

Fixed with commit 583225ce46786041a753bb48cb670e2e80c82bc2, deployed in release v0.4.6.


Rules - One C rule and one Ruby rule

Summary by CodeRabbit
Release Notes

New Features

Introduced a rule to detect potential use-after-free vulnerabilities in C code.
Added a rule to identify hardcoded passwords in Ruby controller classes, enhancing security practices.

Tests

Implemented test cases for valid and invalid usages of C-style strings in C++.
Created test cases for HTTP basic authentication in Ruby on Rails controllers, distinguishing between secure and insecure practices.
Added snapshots to validate the detection of hardcoded passwords and use-after-free scenarios.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: ESS-ENN:x: petrisorcoderabbitYou have signed the CLA already but the status is still pending? Let us recheck it.


Comment tweaks

Resolves #632
Logging skipping due to zero penalty
ErrorDiff(err) has replaced bot GitHub comment errors but not db logging

What's the easiest way to force an error folks any ideas?


Design a better logo

I am no designer and quickly made the current logo, which looks a bit generic.  Come up with a good logo design.

Have Someone working on the logo


Edit pass on sp-add-ins Develop section

Q
A

content fix?
yes

Edit pass on sp-add-ins Develop section

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/sp-add-ins/access-sharepoint-data-from-add-ins-using-the-cross-domain-library.md
:white_check_mark:Succeeded

docs/sp-add-ins/complete-basic-operations-using-sharepoint-rest-endpoints.md
:white_check_mark:Succeeded

docs/sp-add-ins/create-add-in-parts-to-install-with-your-sharepoint-add-in.md
:white_check_mark:Succeeded

docs/sp-add-ins/create-custom-actions-to-deploy-with-sharepoint-add-ins.md
:white_check_mark:Succeeded

docs/sp-add-ins/create-ux-components-in-sharepoint.md
:white_check_mark:Succeeded

docs/sp-add-ins/customize-a-list-view-in-sharepoint-add-ins-using-client-side-rendering.md
:white_check_mark:Succeeded

docs/sp-add-ins/determine-sharepoint-rest-service-endpoint-uris.md
:white_check_mark:Succeeded

docs/sp-add-ins/get-to-know-the-sharepoint-rest-service.md
:white_check_mark:Succeeded

docs/sp-add-ins/highlight-content-and-enhance-the-functionality-of-sharepoint-hosted-sharepoint.md
:white_check_mark:Succeeded

docs/sp-add-ins/include-a-web-part-in-a-webpage-on-the-add-in-web.md
:white_check_mark:Succeeded

docs/sp-add-ins/make-batch-requests-with-the-rest-apis.md
:white_check_mark:Succeeded

docs/sp-add-ins/navigate-the-sharepoint-data-structure-represented-in-the-rest-service.md
:white_check_mark:Succeeded

docs/sp-add-ins/set-custom-permissions-on-a-list-by-using-the-rest-interface.md
:white_check_mark:Succeeded

docs/sp-add-ins/synchronize-sharepoint-items-using-the-rest-service.md
:white_check_mark:Succeeded

docs/sp-add-ins/upload-a-file-by-using-the-rest-api-and-jquery.md
:white_check_mark:Succeeded

docs/sp-add-ins/use-a-sharepoint-website-s-style-sheet-in-sharepoint-add-ins.md
:white_check_mark:Succeeded

docs/sp-add-ins/use-odata-query-operations-in-sharepoint-rest-requests.md
:white_check_mark:Succeeded

docs/sp-add-ins/use-the-client-chrome-control-in-sharepoint-add-ins.md
:white_check_mark:Succeeded

docs/sp-add-ins/use-the-client-side-people-picker-control-in-sharepoint-hosted-sharepoint-add-in.md
:white_check_mark:Succeeded

docs/sp-add-ins/working-with-folders-and-files-with-rest.md
:white_check_mark:Succeeded

docs/sp-add-ins/working-with-lists-and-list-items-with-rest.md
:white_check_mark:Succeeded

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.


Change finder-frontend ownership to Search and Nav

Ran this past Simon and Bevan but we feel it's only fair that Search & Nav look after finder-frontend, since we're the ones tinkering with it.
There's probably other PRs for me to raise off the back of this. Seal? Anywhere else?

The seal doesn't appear to know about app ownership: https://github.com/alphagov/seal/blob/master/config/alphagov.yml
I guess it gets that from this file?

Phew!

@barrucadu Seal only knows about people, not about apps & repos. Any pull request from a team member will show up on the team's seakl.


DMN Technology Compatibility Kit

Have you ever looked at running the DMN tck with your library?
For more info see https://github.com/dmn-tck/tck
We are looking for a rule engine are don't really like the java route and would much prefer a JavaScript solution. Your library seems like a great fit but we would like to get a feel for how mature or feature complete the library is. Having TCK results might give some insight.
I could spend some time to see if I can run the TCK with this library, but would like to get your gut feeling for the chance of success first.
Thanks

I can confidently admit the running the TCK tests will fail at present. I do not have the full understanding of TCK as of the moment. I am aware of its significance, but unsure of how to get started. I don't know who to reach out to in order to get started. Seems that information isn't available anywhere at the time I researched it many months back.
There are many reasons. Most of them stem from our poor understanding of the specification during the initial phases of this project, and, also creating something that catered more to our in-house stakeholder corpus.
What we have today just "works" for our stakeholders somehow. We welcome you to try it also.
I will highlight some problems below, but TLDR we are just not there yet today and we need your collaboration to get through this one.
Understanding the specs
The specs mainly deal with three things:

How to model rules? Various ways to represent decisions and logic, etc...
How to persist them in a suitable exchange format so that it can be shared among organizations? (XML)
Syntax and grammar rules for FEEL - Friendly Enough Expression Language.

Our implementation
I am sparing lengthy details of the above aspects, and I will focus on our implementation next:

We have not implemented the XML bits of specification. Hence with regards to rule persistence I assume some TCK tests will fail.

We have two different APIs - one for executing standalone decision tables, and the other for decision services. As per specification there are only "decision services". The story behind stand alone decision tables in short was inspired from DROOLS. A lot of our customers were using DROOLS hence decision tables...its only a lot later we realized about decision services.

We have code currently that parses excel files which have rules. Its only later I understand they are never meant to be there in the first place. (Why? Because XML!!!) (Was tempted to say "Batman", but...)

Don't use excel. We have a designer. Currently this is part of oe-cloud. There was a standalone designer I made, but the oe-cloud one is simply better. I will make it available if required. With regards to decision services it makes sense composing decisions visually instead of within excel workbooks. And the library we use for parsing excel workbooks is somewhat not mature at the moment. I mean there may be a better way to use those APIs but that is not the point. It is always XML, remember...

There are a lot of in built functions we have not implemented. There is a section inside the specs which deal with string manipulations. We don't have code to that effect. There are other functions too I can't recollect now. There are some grammar issues to we need to take care of.

During the initial phases, when our comprehension of specs was actually unknowingly "low", and our stakeholders were excited with what we had (decision tables). To that end we did some implementations that support oe-cloud use cases. They work extremely well. But later I realize they are non-compliant with specs.

For decision services, our present APIs take in a JSON representation of a decision graph. And this works quite well. Ideally this should be XML, but frankly speaking I hate having to implement XML here and wish to debate. But that is an exercise for another time.

And regarding the above point, the JSON representation doesn't cater to every decision element mentioned in the specs. For e.g. input nodes. In our API we pass in a payload; the engine looks into this payload and resolves variables in FEEL that reference input. But this is WRONG. Ideally the APIs should not accept a payload. The payload should be encoded in the rule document. So in a sense the rule is a self-contained document, and, the engine is also self contained. It only has to search the graph for what it needs; ideally it never has to "search the payload". Hence an ideal API should accept a rule document (XML). But...ah JSON is much better to work with...any day. We can workaround this, and still make this engine DMN compliant, but, I am as of present undecided what to do here...Similarly we have some confusion regarding knowledge sources...

So as you see...there are many issues. But we have evolved in our understanding of the specs relatively better; we realize many things need to be undone.
I am only one now maintaining this. Not in position to commit to a timeline. Would be glad if you could also pick this up, we can work together...let me know.

Thank you for the very candid and honest answer. I agree with most of the points; rule authoring should be outside of the library. If people somehow want to do it in Excel or any other tool, is up to them. It shouldn't be mandated by (or included with) the engine itself.
Running TCK would mean we would have to accept the rules in DMN XML files as well as input and outputs. I agree with your sentiment that it would be much nicer if this library would stay in the JSON domain and not bother with XML. With regards of the inputs and DMN rules file we could make some sort of preprocessor that accepts XML and transform it to the JSON needed by the engine. The other way around (JSON answer back to XML output) might be more challenging but should still be do-able.
The TCK itself runs in java, but the use of java is not mandated. So we should be safe there as well. It would make for a great test suite for this library. But I understand that this library would probably need quite some love and care (and perhaps breaking changes) to confirm to the TCK.
We'll have a look if it makes sense for our project to go for this library, I feel that having TCK compliance would go a long way to convince stakeholders of the quality and maturity of this library, Without it, people might not "trust:" a library with relative few downloads.  At least we now have a better understanding of the work we would have to invest in this library if we go this route.
PS. Some more information about the TCK process can be found at https://social-biz.org/2017/09/01/update-on-dmn-tck/ His blog has a number of posts on the TCK in case you're interested

Thanks for sharing the link. It was informative. I feel the next order of business should be implementing the XML parts of the specification.
I am mildly shocked to know that the test cases are rather simple. They only test FEEL in-built functions, and some decision table hit policies. Perhaps "that" is the scope of tck; I am not sure. I am not the proper authority on that knowledge.
I guess its time to hit the specs again...


Linter fails because some rules only expect specific format as input

The Issue constructor expect some arguments in order like code, position and additional data. Some rules expect some specific format for the input and this causes sometimes the Linter to fail with the error
Cannot read property 0 of undefined

Here is an example:
For the input "foobar" which is obviously wrong html input, the Linter parse it as one text node.
If you apply the doctype-first rule, it will detect the error and create a new E007 issue but the text node does not have an openLineCol property because is not an element. This causes undefined to be passed as the pos argument causing the failure later at the issue constructor.
function Issue(code, pos, data) {
    // Here pos is undefined
    this.line = pos[0];
    this.column = pos[1];
    this.code = code;
    this.data = data || {};
}

Similar problem to #205. I'm starting to think that using openLineCol for tags and lineCol for other elements is a bad idea...


[Orchestrator manifest] add K8sUnsetType

What does this PR do?

Add K8sUnsetType at position 0
Add k8s deployment at position 18

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

I don't add K8sUnsetType in NodeTypes  as we don't really need it
https://github.com/DataDog/datadog-agent/blob/928f27ca075fe0510e07baed3c7696ec133a1f0a/pkg/orchestrator/util.go#L64-L85


run travis on both 0.4 and 0.5

0.4 still supported according to REQUIRE

Actually, I found a bug in this and would like to withdraw it. How shall I proceed? Merge it and submit another, or is there a way to remove it?

Are you referring to the METADATA PR? You can close that, delete the git tag and make whatever updates you need. You should probably look into https://github.com/attobot/attobot, it makes the tagging process simpler.

Ok, I think I did all that. Let's see.

Why did you close this PR? You should really try to enable Travis CI here.

I closed because the AttoBot has submitted a new  one. Wasn't it what was supposed to do?

This = https://github.com/joa-quim/GMT.jl/pull/3, a pull request on your package, not on METADATA.

Ai this is confusing, if this  is a PR in METADATA at the end would not be one replacing this one?
Anyway, what's the solution? Shall I Reopen this PR and that's it?

Why is it confusing? This pull request is in your package's repository, not METADATA. You closed https://github.com/JuliaLang/METADATA.jl/pull/8354 which was the obsolete METADATA pull request, that's good. You also mistakenly closed this pull request, which is unrelated to the tagging of versions in METADATA.

Maybe because I didn't submit this PR.

You should enable this at https://travis-ci.org/joa-quim/GMT.jl, and have your tests actually run in https://github.com/joa-quim/GMT.jl/blob/master/test/runtests.jl so Pkg.test("GMT") does something non-trivial.

I know I should and actually I have a good set of tests  but don't know how to implement them in CI because they require that GMT, Ghostscript and GraphicsMagick are available.

Should probably use BinDeps to specify how to build the library if a system copy isn't found. You could also try getting it from apt-get via something like https://github.com/JuliaGraphics/Gtk.jl/blob/86c391eed8bf0591ee636c2f77e6465be1b9b995/.travis.yml#L11-L16

I develop on Windows but the apt-get would be a good idea ... if packages on it were not so terribly outdated. Do you know if there is an homebrew alternative? Because that we maintain updated in GMT.

you can do if [ `uname` = "Darwin" ]; then brew install gmt; fi or something to that effect for the osx build
or set dist: trusty to run on a newer distribution version

Thanks.

any update on tests and CI?

Honestly, I'm waiting that another GMT developer that is working on a Python wrapper and more knowledge d in CI stuff the sets up the necessary infrastructure.

any update on tests and CI?

Tried also with Appveyor but the build fails don't know why. Well, on Linux I suspect a too old GMT install but no idea why it fails on Windows nor if it's even trying to build in OSX.

Looks like on appveyor you're trying to download using a url in an environment variable that you haven't set?


Filename interpolation into repeated command

I run tests with kicker. I just realized that it would be very cool if kicker could pass the filename of the file that triggered the event into the command!
Imagine I run kicker -ce "hax0r_tests %s" and I save tests/test_lazerguns.py in my favorite $EDITOR. kicker would then execute hax0r_tests tests/test_lazerguns.py, in which the test runner will only run the tests in that file, making the feedback loop shorter and the developer happier!
Would this be possible to implement?

This would make "ghetto testing" on a per-file basis much easier. +1


Update the initialization timeline for the Godot fragment

This is done to be more consistent with the previous activity based timeline as the discrepancy can cause initialization timing errors.
It also facilitates migration to the fragment based architecture for projects directly integrating the Godot Android library.

Thanks!

Cherry-picked for 3.2.4.


Memory Leaking on C# .NET.

Hello. We have a problem with memory leaking on C# .NET TdLib. Unmanaged memory increases over time, but .NET Memory almost not increases, so we suppose it's a problem under the TdLib.
I tried enable all databases and it made leaking much faster than it's not enabled.
For 24 hours it took almost 500 MB of RAM:

Stable increasing after user authorization:

We tested a lot of times that TDLib properly releases all allocated memory.
TDLib has a cache of users and chats, which speeds up all requests and gives a big flexibility for the application. The size of the in-memory cache grows over time, so if app wants to flush it, it needs to close and reopen TDLib instance. Also, note that default memory allcoators usually don't return memory to operating system, but instead the memory is reused for subsequent unmanaged memory allocations.
Between, when all databases are enabled, TDLib is able to unload messages from the cache, so the memory usage should grow slower in this case.

Ok, we'll try to enable all databases. I'll write about the results in a week later.

Enabling all databases made memory growing more slowly. But disposing TdLib instance doesn't give any effect.
We disposed it  at 00:00 and created new at 01:00, how can u see, it doesn't released memory at all.
*yellow line means that new version of project was deployed and start working.

That is the code which we called:

Local test shows that disposing client releases only .net memory and doesn't effect to unmanage memory (which is used by C++ JsonTdClient?).

Also, note that default memory allcoators usually don't return memory to operating system, but instead the memory is reused for subsequent unmanaged memory allocations.

Your memory profiler is C#-specific and doesn't distinguish between being used and freed (and ready to reuse) unmanaged memory.
Between, how much threads are you using to send requests to TDLib?

Between, how much threads are you using to send requests to TDLib?
It's an asynchronous application, so we use many "await" constructions and it results in many threads are used.

If you don't create threads explicitly, then C# uses only limited number of threads from a thread pool, which is fine..

So how to resolve the problem? Only reopen the application?

Instance recreation should also help, because the new instance will reuse memory freed by the previous instance. But if it has no significant impact for you, then only closing the whole application can help to deal with heap fragmenttion.

Between, how much threads are you using to send requests to TDLib?

If we set less limit threads, will it reduce the memory using?

If we set less limit threads, will it reduce the memory using?

This is very unlikely to help.

Ok, understood. Thank you very much for your help, levlam! :)


Java source build error in Windows 10

I'm getting an error about javalite_toolchain while trying to build java sources via bazel.
my proto-buffer is 3.11.4v;
bazel is 3.0.0v;
java version "1.8.0_251";
Java(TM) SE Runtime Environment (build 1.8.0_251-b08).
I'd appreciate any help!
ERROR: C:/users/jimi/_bazel_jimi/n4ofdyla/external/tink_base/proto/BUILD.bazel:195:1: every rule of type proto_library implicitly depends upon the target '@com_google_protobuf//:javalite_toolchain', but this target could not be found because of: no such target '@com_google_protobuf//:javalite_toolchain': target 'javalite_toolchain' not declared in package '' (did you mean 'java_toolchain'?) defined by C:/users/jimi/_bazel_jimi/n4ofdyla/external/com_google_protobuf/BUILD
ERROR: C:/git/tink/java_src/proto/BUILD.bazel:113:1: every rule of type java_lite_proto_library implicitly depends upon the target '@com_google_protobuf//:javalite_toolchain', but this target could not be found because of: no such target '@com_google_protobuf//:javalite_toolchain': target 'javalite_toolchain' not declared in package '' (did you mean 'java_toolchain'?) defined by C:/users/jimi/_bazel_jimi/n4ofdyla/external/com_google_protobuf/BUILD
ERROR: Analysis of target '//proto:aes_ctr_java_proto_lite' failed; build aborted: Loading failed

This is probably due to https://github.com/bazelbuild/bazel/issues/10335, meaning that we will need to update something within Tink for bazel 3.
Until then, plase use with bazel 2.

Thanks, it builds with bazel 2.


DROOLS-1025 - AddRemove rules tests - not(not) tests 2

Added new class with generated incremental compilation tests.
Extracted failing test to AddRemoveRulesTest.

Incorporated by https://github.com/droolsjbpm/drools/commit/b0943c56509c20d4b20da19e22c40149931b0030


Can I have other file instead of conftest.py?

Hi, I have gone through the documentations.
In general I think you have made an amazing feature, with really good chance of growth, so good luck!
I am working on large app where conftest is already taken by other testing methods, there is no way I can remove, replace or rename it. I am sure that will mess all pipeline.
It would be easier if I could have some other file for configuration pylenium. Is that possible? How can I do so?
Once again, great lib, nice intro video, good luck, hope to see this reaching as high as cypress and even more haha

The fixtures within conftest.py are required for Pylenium to function as expected. However, they are just fixture functions, so you can just copy and paste them into your existing conftest.py at the Project Root


Statistics TextViews are not showing in Achievements Fragment

Summary:
Statistics TextViews are blank in Achievements Fragment.
Steps to reproduce:
Go to Achievements. See Statistics.
Device and Android version:
Pixel 4 API 27
Nexus 9 API 26
Samsung J2 API 23
Commons app version:
3.0.0-latest master
Screen-shots:

@nicolas-raoul @madhurgupta10 Is this issue occurring for everyone.

Would you mind circling in red the part(s) that you think is problematic?
By the way here is mine (the numbers 278 0 0 24 look plausible):

@nicolas-raoul Sorry for not being clear. As you can see in the screenshots the TextViews under the red square are black which was present before in the app. You can also see this in your attached screenshot.

 Somedays before
 Now

Ah sorry I missed that!

@Ayan-10 thanks for the issue, do you know the last commit when it was working fine?

@madhurgupta10 I was looking into it but I couldn't able to find that commit. But I will let you know If I can find it. Although I find the cause of this issue and I fixed It. Please look into #4416 .
Thanks.

By the way "git bissect" is a great tool to find the commit 🙂
On Mon, 17 May 2021, 00:29 Ayan Sarkar, @.***> wrote:

@madhurgupta10 https://github.com/madhurgupta10 I was looking into it
but I couldn't able to find that commit. But I will let you know If I can
find it. Although I find the cause of this issue and I fixed It. Please
look into #4416
https://github.com/commons-app/apps-android-commons/pull/4416 .
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commons-app/apps-android-commons/issues/4415#issuecomment-841832893,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYKBQV3TXQKO3LOECS663TN7QGRANCNFSM446A7G7Q
.

@nicolas-raoul Thanks for sharing. This is a great tool to find a bad commit. I find that commit. The commit is mine, but when I made the PR, it was running perfectly. I attached the screenshots also. As you can see in #4341 . I don't know what happened. This is the commit that I found.
baaec02c839b05a7fe6038b8b1576d309db987d2 is the first bad commit
commit baaec02c839b05a7fe6038b8b1576d309db987d2
Author: Ayan Sarkar<EMAIL_ADDRESS>Date:   Thu Apr 8 21:29:26 2021 +0530

    Make the whole label clickable (#4341)

 app/src/main/res/layout/fragment_achievements.xml | 156 +++++++++++++---------
 1 file changed, 92 insertions(+), 64 deletions(-)


Properly extract package name for installing tgz of scoped packages

Will add test[s] + extract logic to a function if we consider this a decent solution.
Aims to resolve #1414.

Let’s do it? Needs a test from https://github.com/facebookincubator/create-react-app/pull/1537.

Added a test. Let’s see what happens.

Rebased this to see if it passes with the node 4 patch. Figured it was the easiest method than triggering a re-merge by github and test.

All suites passed except simple which was botched by lint (should we move lint)?
I think this is good, so merging.


add prometheus integration and fix the logout issue for ldap

#2507 #2633

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@9636d5f). Click here to learn what that means.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             master    #2638   +/-   ##
=========================================
  Coverage          ?   50.23%
  Complexity        ?     2061
=========================================
  Files             ?      413
  Lines             ?    12647
  Branches          ?     1294
=========================================
  Hits              ?     6353
  Misses            ?     5845
  Partials          ?      449

Impacted Files
Coverage Δ
Complexity Δ

...lo/portal/spi/configuration/AuthConfiguration.java
5.84% <0%> (ø)
1 <0> (?)

Continue to review full report at Codecov.

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

Coverage increased (+0.004%) to 53.784% when pulling 34e7833efabe13be3a0fdbff945eb6fb78ffa772 on nobodyiam:ldap-fix into 9636d5f5e952bc6d30fbde55a6cff13acd6e1327 on ctripcorp:master.


Right Arrow Key Not Working on Mojave

Required information
In order to help us sort your issue, we ask that you provide the following information:

[ ] Mac model:3,1
[ ] macOS version: 10.14.6
[ ] Monitor setup: 6 displays; (3) 1440p over (3) 4K
AerialLog.txt

Description of issue / Feature request
Right Arrow key isn't functioning with v2.0.9 on macOS 10.14.6; audible error sound plays with each attempt. I understand it's broken and closed in Catalina; should this still work on Mojave?

It still works in my 10.14.6 vm here, but people have been having weird issues with the latest security update for 10.14.6.
A couple of things to start :

Check in Settings Advanced that's the option is enabled
You mention having an error sound, that implies something else has focus. What about other keypresses, do they make the same noise ? Or do they quit ?

That may narrow it down a bit, thanks and sorry about that.

Please reopen if you still need assistance


CI python 3.6 bug fix

From this issue it was found that the ubuntu latest-version of the github action runner was updated to 22.04, there are no tarballs in 22.04 for any python 3.6.* versions.
This PR introduces a fix to allow us to run the python 3.6 test without issues.
Category

[ ] slack_bolt.App and/or its core components
[ ] slack_bolt.async_app.AsyncApp and/or its core components
[ ] Adapters in slack_bolt.adapter
[ ] Document pages under /docs
[x] Others

Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've run ./scripts/install_all_and_run_tests.sh after making the changes.

For some reason the Github runner is using ubuntu 22.04 instead of the correct os version of ubuntu 20.04 to run tests with python 3.6 refer to the logs
On my fork this seems to work as expected not  sure why the runner is using the latest version here

@WilliamBergamin Usually testing with the latest is recommended, as we don't need to do tests with any specific OS distribution and version. I also observed this issue caused by the behavior change in the GitHub Actions infra side for python-slack-sdk project. Here is my fix for it: https://github.com/slackapi/python-slack-sdk/commit/f2f3fd63e7b86abdb29a66f28b897402802ddafe I am not sure why your change does not work here, but if my change works well for bolt-python, applying the same change may help.

@WilliamBergamin It seems that, with your change, we need to adjust the main branch protection setting every time we change the OS image setting. Meaning that "build (3.10)" and "build (ubuntu-latest, 3.10)" are non-equivalent. You need to head to https://github.com/slackapi/bolt-python/settings and then go to "Code and automation" > "Branches" > "Branch protection rules" > Edit "main" branch > Adjust the list for "Require branches to be up to date before merging".
Considering that, simply changing the runs-on setting for all looks like easier to maintain to me. As I said above, we don't have any requirements for the OS version. Using -latest is just a recommendation by Github for stability in long-term maintenance. What do you think?

@seratch I agree think we can fix the os version and update it manually, this is the only place I've seen recommend using the latest tag, I've been told it leads to unexpected dependency errors like the one we are encountering


Support customers level template bundles

What are you trying to accomplish with this PR?
After allowing alternate template bundles in beta.8, the liquid logic included in script-tags.liquid snippet to check which bundles to load and which bundles to prefetch, was updated to use template from template.name. This creates a problem for any template that's included in the customers/ directory because the value that's used to create the template name in the liquid logic is taken from the chunk inside the webpack plugin. This is a problem because bundles/entry points inside the customers/ directory are flattened down to the same level as the other files, which produces files like this:
template.login.js
template.account.js
template.order.js

Those file names are used to create the blocks inside of script-tags.liquid. This used to be ok before because if you were on a customers/ template e.g. login.liquid, {{ template.name }} would produce 'login', but now since switching to {{ template }} the output has changed to 'customers/login'. The resulting output looks like this:
{%- if template == 'login' -%}
    <script type="text/javascript" src="https://<IP_ADDRESS>:3001/template.login.js" defer="defer"></script>
{%- else -%}
    <link rel="prefetch" href="https://<IP_ADDRESS>:3001/template.login.js" as="script">
{%- endif -%}

The problem here is that template == 'login' will never evaluate to true, so this bundle will never get loaded. This pull requests alters the script-tags.html template to check if the chunk includes customers/ in its path, and if it does, prepends customers/ to the template check inside of the liquid logic.
Additionally, after poking around a bit, I noticed that bundles for alternate templates in the customers/ directory weren't being loaded in due to a conditional inside of get-template-entrypoints.js. Templates not inside customers/ are getting run through a new isValidTemplate function, but the customers/ templates are not. As a result, any alternate customers/ template is not being seen as valid, and thus not being included. This pull request updates get-template-entrypoints.js to replace the old valid template check with isValidTemplate that allows alternate templates to pass through.
Please provide a link to the associated GitHub issue.
https://github.com/Shopify/slate/issues/806
Checklist
For contributors:

[x] I have updated the docs to reflect these changes, if applicable.

For maintainers:

[ ] I have :tophat:'d these changes.

Hey @tshamz! Great PR! Was able to give it a test run, everything you proposed to fix is fixed and works great. This PR is good to merge.
However, I found a few more holes our logic:

If a customer template bundle shares code with another template bundle, the chunk created still results in a liquid condition that doesn't include customers/ prefix, e.g:

{%- if template == 'index' or template == 'login' or template == 'product' -%}
<script type="text/javascript" src="{{ 'template.index<EMAIL_ADDRESS>| asset_url }}" defer="defer"></script>
{%- else -%}
<link rel="prefetch" href="{{ 'template.index<EMAIL_ADDRESS>| asset_url }}" as="script">
{%- endif -%}

The problems you fixed still exists in style-tags.liquid, the snippet for including our stylesheet bundles.
Problem 1 written above still exists in style-tags.liquid

If you wish to expand this PR to fix those problems, that would be 💯. If you'd rather not, we can merge this and I'll create followup issues to tackle the changes.
There have been a number of bugs associated to these snippets. They are super powerful and would really benefit from some tests to guarantee stability. Again, not needed for this PR but I can create a separate issue.

I figured number 1 was gonna be a problem at the time. I think underscore templates are a nightmare to read and I had been working for a while when I ran into this so I didn't really have the mental capacity to try and decipher what was going.
I added a fix for this and copied the same logic over to the style-tags.html file as well. I did not make it around to writing some tests but I'll noodle on it and if i have some spare time put something together.

@tshamz awesome! I'll give this a test run and we can merge it as is. I'll create a followup issue about the shared chunks.

Gave it a test. Looks solid. Awesome contribution! Thanks @tshamz