TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/115623

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/117440

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/118619

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/119653

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/121523

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/121966

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/122006

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/122181


Making mods optional, with sufficient warnings.

In 99% cases, when people are missing mods, it's usually some graphics, or irrelevant mod, and there is rarely a need to halt conversion. If stuff breaks, we can clearly point to missing mods as usual.
Trouble is I often have to read the logs to the people that upload them and then we have conversations like the one on forums right now.

In 99% cases, when people are missing mods, it's usually some graphics, or irrelevant mod, and there is rarely a need to halt conversion. If stuff breaks, we can clearly point to missing mods as usual.
Trouble is I often have to read the logs to the people that upload them and then we have conversations like the one on forums right now.


Try color green on success message + 2 other cosmetic requests

Alpha example code. When scheduling multiple tasks, results of first tasks are hard to spot inside the messages list
Color green the sync success message

1- Issue: When scheduling multiple tasks, results of first tasks are hard to spot inside the messages log list. Coloring green the sync success message makes it easier to spot and see the stats (speed, end/start of list to see the files processed...)
This is only to show how it should look, code is dirty !!
I looked at it but I really did not want to modify all the code as I am not sure how it is better to make it properly
2- can you add the transfer_speed to the History log ? It is really nice to have it directly there for smb
3- can you format elapsed time in messages and history as hh:mm:ss rather than sss.msec ?
These are only cosmetic functions, so no hurry and feel free to ignore the request
Best regards

added a proper commit


Fix bad lebab transforms.

Coverage remained the same at 77.848% when pulling 3cb22dc80c843568c3354089deb6cb11afad5768 on fix-prototypes into d728316770b493a8f343cbb2aa8f98db8aacd386 on master.


don't remove the ability to get package versions via the JSON API

https://github.com/pypi/warehouse/pull/11777 marked the "releases" key deprecated.
This would be painful in poetry, which uses that part of the API to determine the available versions of a package.
Per https://github.com/python-poetry/poetry/issues/6076#issuecomment-1196463451, I think a sensible API and poetry's needs are aligned here:

it makes perfect sense to remove most of the information in releases, clients that need all of the details for a particular version can go to the version-specific endpoint (and this is indeed what poetry does)
but removing the capability even to learn what the available versions are seems like overshoot

perhaps it would make sense to replace "releases" with eg "versions", listing the available versions.
NB parsing the simple API (even in json form) is a less satisfactory approach for poetry.  Eg consider a package like cryptography, for which there are maybe a couple of dozen downloads available at each release: to get the available versions poetry would have to iterate over each of those files and parse their names - rather than simply reading the answer.  Clearly this is much less efficient.

I don't have any conceptual reason not to add a versions field to this API.
However, I do just want to point out that I think that parsing the filenames not being as efficient is not entirely accurate.
The legacy JSON API has a ton of extra data inside of it, including the full long description of the project, which has a theoretically unbounded length (and for some projects appear to be approaching 7MB just from the long description alone). You can't state that "simply reading the answer" is more efficient, without first accounting for the fact that you've already wasted time and bandwidth downloading potentially large amounts of data that you're not even using.
Overall, I'd prefer that we look at iterating on the simple API for features that installers need, as that's our golden path here. But I don't think it would be rejected if someone were to write a PR to add a versions key to the legacy json API.

I've no objection to limiting either the amount of data that is allowed to be in a description or the amount of data that is returned in a description; nor to the simple API being made more useful for installers.
I see your hint re a PR - thanks - not sure that I'm likely to get to it in the very near future but it could happen.  Clues as to where the relevant code is certainly welcome anyway, whether for my benefit or someone else's.

Adding to the comments of @dimbleby:

Package names do not always match the PyPI project name that provides them. This is not an issue with the legacy JSON API, but would potentially be an added complication for code parsing the results from the Simple API.
Iteratively parsing the list of package files from the Simple API to match a package version raises the barrier to entry for someone writing a package manager, package version lock manager, etc.... (As someone who has written a package version lock manager in the past year, I will say that tracking various PEPs and pieces of PyPA documentation that may or may not be out-of-date introduces enough cognitive burden for someone, who isn't in the thick of the Python packaging world, as it is. Not intended to be a slight or criticism of anyone or any project, but there is a non-trivial amount of scattered information to absorb and form into a coherent picture.)

But, yes, I also would be quite content to see the Simple API made more useful for installers / lock managers / etc....

The simple API now includes an array that lists all of the versions of a project, which I believe removes the concern over using the simple API for getting this information (AIUI, the concern is that parsing filenames is less efficient than just getting a list of versions from the service).
I'm going to close this issue (and the related PR, sorry I never got around to reviewing it, the pandemic ruined my ability to focus and this fell off my plate) with the expectation that the simple API should suffice now for this use case.


gzip autodetection

The cloud-init project uses a similar technique to natively support gzipped user-data. The alternative path would be to use a script that decompresses the user data and then calls into cloudinit, but this seemed simple enough to bring into cloudinit itself.
And, unrelated, but in the same commit – without the change to test, I found that the top-level tests in coreos-cloudinit_test.go were not running.

@crawford it looks like I missed the great issue migration out of this project, but I think this addresses coreos/bugs#741 – would you be able to give it a look?

@sethp I haven't had a chance to look at this yet. Rest assured I haven't forgotten about it!

Thank you for the feedback! I think I've addressed each point, would you let me know if you're happy with it?

Ah, sorry – I think my messages match the format in CONTRIBUTING now. Please let me know if there's anything else I missed!

This looks good to me. @jonboulle, did you have any concerns?

LGTM


Add form to change a case's status

Fixes VEGA-1238 #minor

Codecov Report

Merging #68 (dc09476) into main (108efcb) will decrease coverage by 0.53%.
The diff coverage is 71.15%.

@@            Coverage Diff             @@
##             main      #68      +/-   ##
==========================================
- Coverage   79.32%   78.79%   -0.54%
==========================================
  Files          34       37       +3
  Lines         745      797      +52
==========================================
+ Hits          591      628      +37
- Misses         97      106       +9
- Partials       57       63       +6

Impacted Files
Coverage Δ

internal/sirius/case.go
100.00% <ø> (ø)

internal/sirius/edit_case.go
38.88% <38.88%> (ø)

internal/server/change_status.go
86.66% <86.66%> (ø)

internal/server/server.go
91.83% <100.00%> (+0.17%)
:arrow_up:

internal/sirius/get_allowed_statuses.go
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Update continuous-delivery.yaml

This PR will not trigger the CD workflow for file changes in .github and subdirectories.

/approve


Make timeout configurable

Fixes #4

Can you squash Added comments to new code into the Add timeout configuration... commit?

Can you update this to also timeout if it is not at max attenuation? This will make it time out in the SINGLESHOT_COMPLETE state.
It will need updating slightly for the fix to singleshot mode and renaming SINGLESHOT_COMPLETE -> SINGLESHOT_WAITING, but that can be a separate PR.

Squash Removed old timeout variable and Added timeout to status dict into the first commit


Consolidate AWS EKS node pool version calculation to be calculated through activity and passed as input

Is your feature request related to a problem? Please describe.

Currently some activities such as CreateASG calculates the AWS EKS node pool version for themselves while others take it as an input which leaves room for diverging logics due to the function being generic/variadic.
Describe the solution you'd like to see

Consolidate all uses to precalculate the node pool version using the corresponding activity and pass it to other activities as input.
Describe alternatives you've considered

Version could be calculated inside the activities using the calculation function, but then all the version components should be passed as input which are changing frequently. If we use a precalculated version input, we can avoid updating usages whenever a new component is used in the version calculation logic, only the activity needs to be updated.

Done, just not closed.


Always got 403 at Camunda startup

Hi,
I'm not able to use your PlugIn. At startup of my application I got following exception:
Caused by: org.springframework.web.client.HttpClientErrorException$Forbidden: 403 Forbidden 	at org.springframework.web.client.HttpClientErrorException.create(HttpClientErrorException.java:83) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:123) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:102) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:785) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:743) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:677) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:586) ~[spring-web-5.2.1.RELEASE.jar:5.2.1.RELEASE] 	at org.camunda.bpm.extension.keycloak.KeycloakIdentityProviderSession.getKeycloakAdminGroupId(KeycloakIdentityProviderSession.java:1043) ~[camunda-bpm-identity-keycloak-1.5.0.jar:1.5.0] 	... 38 common frames omitted
I have an existing Keycloak server and added a new client and the admin group in my realm with all the settings out of the documentation. It seems that the login success but the request for the admin group fails.
Is there something to change in Keycloak what is missing in the documentation?
Best regards

same here

Sorry, my mistake. I created new roles like 'query-groups', 'query-users' and 'view-users' within client 'camunda-identity-service' rather than re-using them from client 'master-realm'.

Hi  @FlowsenAusMonotown,
this is very likely a setup error where you made a small mistake you don't see yourself. Do you have
a) the application.yaml config on Camunda side
b) the setup of your identity service?

Hi @VonDerBeck, this issue is solved by the comment of @rfelgent. I also created the roles in the client and don't use the "realm-management". Now it is working.

Hi  @FlowsenAusMonotown,
great to hear that you were successful :-)

@VonDerBeck The next issue I have is that I now can't login. Which user I have to use? I normally thought I can use every user of keycloak to sign in, isn't it?

First of all I recommend to create an admin user in Keycloak and configure a corresponding admin group. This admin group then goes to your Keycloak Identity Provider Configuration. Afterwards you can log in with this admin. And then go to Camunda -> Authorizations and create access rights for Cockpit, Tasklist etc. for other groups and users. Don't forget authorizations for processes etc. This has nothing to do with Keycloak, it would be the same in case you use the LDAP Identity Provider.

SO I has to start without keycloak plugin -> create the admin user, start with keycloak plugin -> login with the admin -> give access rights via the admin web UI?

1.) Just setup your Keycloak server. Prepare at least a single admin user belonging to an admin group.
2.) Configure the Keycloak Identity Provider accordingly (with the admin group)
3.) Startup Camunda - upon first startup it will automatically create all required authorizations for your admin group
4.) Login with the admin user.
5.) Create other authorizations for non admin groups in case they are required, e.g. authorizations for a ReadOnly group, ...

I have already a Keycloak instance running (also for other apps). There is a admin user existing. I use this user to manage keycloak. The user has no groups belonging to but has the assigned role "admin". This user is in the user list of the master realm. Not in the created realm.
Have I put this user to the "camunda-admin" group?
What do you mean with no. 2? My IdentityProvider looks as follows:
@Component @ConfigurationProperties(prefix="plugin.identity.keycloak") public class KeycloakIdentityProvider extends KeycloakIdentityProviderPlugin { }

You need a user or group in the Keycloak Realm Camunda is connected to.
According to your config you'll need a group "camunda-admin" in this realm. Alternatively you configure a user (and not a group) using 'administratorUserId' property.

OK, I changed it to:
plugin.identity.keycloak:
keycloakIssuerUrl: https://myserver.com/auth/realms/MyRealm
keycloakAdminUrl: https://myserver.com/auth/admin/realms/MyRealm
clientId: camunda-identity-service
clientSecret: a43b7e2c-d7e7-4914-8cc7-e0a95bbbc8ac
useUsernameAsCamundaUserId: true
administratorUserId: a26de9f9-ae21-4243-b45c-f95b45d80ba4
And on startup I see multiple line like this:
KEYCLOAK-01003 GRANT user<EMAIL_ADDRESS>ALL permissions on resource Application.
...
But I still can't login to Camunda with this user. It always shows message "Invalid credentials" but I used the right one. I double check to login with this user in an other application and it works.

You have set 'useUsernameAsCamundaUserId' to true. Are you aware of that? In case you try to login using Camunda's login screen (and not SSO with Keycloak login) the Camunda UserId is now the Keycloak username attribute. You'll find other options within the properties description of the Identity Provider.

@VonDerBeck Yes. Because I also configured Keycloak to use the e-mail address as user id.

Why don't you configure that in Camunda as well, e.g. by using 'useEmailAsCamundaUserId'?

I changed it but the same result "Invalid credentials". I checked the database and the 'act_id'user' table is empty. I don't now if this is important for this.

Camunda database tables for users and groups are of no interest in case you use any foreign Identity Provider.
1.) The user you configured - it does exist within the Camunda realm, right?
2.) What exactly do you mean by "Because I also configured Keycloak to use the e-mail address as user id" - I only know an option which allows you to login using your email as well, which is on the per realm level.
3.) A working example can be found in the sub directory examples of this realm
4.) In case you want to play around a bit with a working default Keycloak instance setup, you can use the docker image "gunnaraccso/keycloak.server:7.0.0". It's old (based on Keycloak 7.x), but should be sufficient to show the basics. Start it and login with keycloak/keycloak1! - you'll find a test setup inside.

The user is in the "MyRealm".
In the "MyRealm" Realm Settings tab "Login" you can choose "E-mail as username". So the register page will not display input field username anymore.
Can I set another logging level to check the request/response while authenticating?

@VonDerBeck I tried the docker image you recommended. I reconfigured my application using:
plugin.identity.keycloak:
keycloakIssuerUrl: http://localhost:8090/auth/realms/camunda
keycloakAdminUrl: http://localhost:8090/auth/admin/realms/camunda
clientId: camunda-identity-service
clientSecret: 0ca35c49-c721-44dd-a6c2-a5e825e13c84
useEmailAsCamundaUserId: true
administratorUserId: a0513f01-c509-4bef-a59e-3c5f528a742b
Tried to login with "camunda" user and get the same error "Invalid credentials". (I changed the password of the user in keycloak admin ui first und using the new password for login)
I will create a new ticket for this or do you have any suggestions?

In case you set useEmailAsCamundaUserId to true you have to login using your email address. In Camunda you always login with the userId - which in this case is configured to be the email address of Keycloak.
I don't think that this is an issue.

@VonDerBeck I used the e-mail address<EMAIL_ADDRESS>as login username and the new password. But I can't login.
I tried everything from the documentation "Camunda Spring Boot" section.
If you think it is not an issue, what should I do for getting it running?

I will try to reproduce what you are doing. Can you list the exact changes you made to the test Keycloak instance? As this afternoon I have different work to do - I will try to have a look at this tomorrow.

Reproduce:
pom:
`
4.0.0
org.flowsen
flowsen-process
1.0.0

11

org.springframework.boot
spring-boot-dependencies
2.2.1.RELEASE
pom
import

org.camunda.bpm.springboot
camunda-bpm-spring-boot-starter
3.4.0

org.camunda.bpm.springboot
camunda-bpm-spring-boot-starter-webapp
3.4.0

org.camunda.bpm.springboot
camunda-bpm-spring-boot-starter-rest
3.4.0

org.camunda.bpm.extension
camunda-bpm-identity-keycloak
1.5.0

org.springframework.boot
spring-boot-starter-security

org.springframework.security.oauth.boot
spring-security-oauth2-autoconfigure
2.1.5.RELEASE

org.springframework.boot
spring-boot-starter-jdbc

org.postgresql
postgresql
42.2.4

com.h2database
h2
test

org.springframework.boot
spring-boot-maven-plugin

ZIP

repackage

org.apache.maven.plugins
maven-compiler-plugin

${java.version}
          ${java.version}

`
application.yaml
`server:
servlet:
context-path: /camunda
spring:
datasource:
url: jdbc:postgresql://localhost:5432/camunda
username: camunda
password: P0cGCaozrTGUctR8
driverClassName: org.postgresql.Driver
camunda.bpm:
database:
type: postgres
#schema-update: drop-create
authorization:
enabled: true
plugin.identity.keycloak:
keycloakIssuerUrl: http://localhost:8090/auth/realms/camunda
keycloakAdminUrl: http://localhost:8090/auth/admin/realms/camunda
clientId: camunda-identity-service
clientSecret: 0ca35c49-c721-44dd-a6c2-a5e825e13c84
useEmailAsCamundaUserId: true
administratorUserId: a0513f01-c509-4bef-a59e-3c5f528a742b
`
KeycloakIdentityProvider
`package org.flowsen.keycloak;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
import org.camunda.bpm.extension.keycloak.plugin.KeycloakIdentityProviderPlugin;
@Component
@ConfigurationProperties(prefix="plugin.identity.keycloak")
public class KeycloakIdentityProvider extends KeycloakIdentityProviderPlugin {
}`
Application
`package com.globalflats;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Application {
public static void main(String... args) {
    SpringApplication.run(Application.class, args);
}

}`

Hi @FlowsenAusMonotown,
I have just created a simple Maven project consisting of the artifacts you mentionend above - and nothing more. And of course you can't login with that...
Please study carefully the dependency in your pom.xml. You have added Spring Security and Spring Security OAuth2. Which means you have secured your overal application with OAuth2. Unless you haven't configured it otherwise in your WebSecurity configuration, you will get the login mask from Spring itself at any URL you type.

This will never work in the configuration above.
What you should see instead as login at localhost:8080/camunda is:

And with that you can of course login successfully. You can achieve this in your above example by just commenting out the 2 spring-security artifacts in your pom.xml. This will show you, that the Keycloak Identity Provider itself is working perfectly.
In case you want your Application to use SSO and Spring Security OAuth2 - meaning that your login will be redirected to Keycloak itself - please study the "Activating Single Sign On "section in the README.  You'll need a lot more stuff. A complete example can be found at https://github.com/camunda/camunda-bpm-identity-keycloak/tree/master/examples/sso-kubernetes
In case you want to leave Camunda Cockpit as is and keep using the Camunda login, you'll have to configure your WebSecurity accordingly and allow all requests to /camunda/app/*
The difference between both 2 scenarios (without SSO and with SSO) is described in https://blog.camunda.com/post/2019/08/keycloak-identity-provider-extension/
Hope this helps?
Gunnar

@VonDerBeck Thx a lot. Now it is working perfect.


chore: release-please updates Helm value.yaml

Signed-off-by: Giovanni Liva<EMAIL_ADDRESS>

What was the plan with this PR? 🤔


Defining typescript interface for options of method to make screenshots

From https://forum.babylonjs.com/t/define-typescript-interface-for-options-of-method-to-make-screenshots/4713
All test are passed and build successfully complete

Could the interface be moved within the screenshotTools file ? This helps preventing import from tools in ES6 when not necessary.
Thx

@sebavan check it please https://github.com/BabylonJS/Babylon.js/pull/6630/commits/6b367047b53745174d8c4ac9a6687c42c6e67070

LGTM :-) Could you add an entry in dist/preview release/what's new.md ? and all the build will be green and ready to go in.

add an entry in dist/preview release/what's new.md ?

Seems I cant understand.. it it written here what I must not commit dist/preview
https://doc.babylonjs.com/how_to/how_to_start#do-not-commit

This is utterly confusing I agree and I will fix the doc ASAP, the what s new file is the only one that needs to be updated. This is our base to create the changelog for the next release.

Do you mind moving the interface in its own file?

I wanted itm but cant understand system for defining interfaces. In my projects I usual define interfaces in self directory called interfaces and use only one export construction per one file.
But here I dont see similar system or any other. So I make interfaces folder in the /Misc.

iInspectable is already in the misc folder so it is ok to drop that file there as well
no need for a new folder

iInspectable is already in the misc folder so it is ok to drop that file there as well
no need for a new folder

But in this folder already have many interfeces, these may be moved into interfaces folder. I dont did it because my PR not about it and not about refeactoring

I agree but let's do it later then. (Also you have a doc issue)

Also you have a doc issue

I thinked documentation generated automatic, it is not right? Or you about what's new.md file?

I updated file what's news. Is now all ok?

You can see the checks here: https://github.com/BabylonJS/Babylon.js/pull/6630/checks
The documentation problem: "[18:09:46] Missing text for Interface : IScreenshotSize (id: 24186) babylon.d.ts:31576"

Aaaand did I pass this challenge?

YOU DID :)
Congrats my friend!

Yes! Thanks man!
One contributor more haha =)


what i need to do after downloading tibia 11? tibialyzer dosent work

help

Download the beta and click on the "Tibia 11" icon.

i did but my HUD they are using unknown numbers, all wrong if i put Download new adress my Hud change with different numbers, if i put Generate Adress another numbers appear, but both are wrong.. what i do Bro?

HUDs do not work properly yet for Tibia 11, only chat scanning is supported currently.

ok ill be ready when they work! thakns a lot Mytherin i really appreciate your work and knowledge about this usefull program

@Mytherin I'm not sure if it is alright to make requests like this but I would very much like to see some sort of notification for cooldowns added in the future if possible, similar to what the flash client has on it's icons.
As a knight it's very important to keep track and maximize the usage of your exori's which is a lot easier if you can see exactly when the cooldown runs out. Some sort of hud or customizable popup would be incredible!
I would even be willing to pay an subscription fee for more "advanced features" like this if you need some extra incentive, tibialyzer is literally what makes tibia worth playing for me again so I can't thank you enough for keeping this up!

I did such a thing for Tibia 10, but seeing as its life is ending right now I never released it. I also was not able to replicate it for Tibia 11, but if @Mytherin is willing to take a look I will send what I have. It's functional in Tibia 10.98.

@1086339 I'm never going to charge for Tibialyzer simply because I don't want to offer actual support or dedicate anything but voluntary time to the project. As for your suggestion; it won't be possible without actually detecting whether or not a spell was cast which is hard to determine. It is possible to create a "rough" version by looking only at the server log messages; however, just because you type "exori" in chat does not mean you actually cast the spell. As such, I don't think I will add it because it will require more reverse engineering of the Tibia 11 client which I don't want to do.

@Mytherin Actually it is easy to determine. Tibia stores cooldown start and end time and cooldown ids. Proof of concept: http://i.imgur.com/P6w3F1f.gifv. From what I checked Tibia 11 stores it exactly the same, though I wasn't able to find the correct pointers for the values.

I realize that Tibia itself stores it; the problem is that I don't want to figure out where it is stored and how I can find it. Tibia 11, as far as I know, doesn't use static addresses so reliably finding where a particular piece of information is stored is tricky as it is stored in a different place every time. For now I've resorted to developing an understanding of how the information is stored, and then using patterns to try and deduce where the information is. However, that requires quite some effort.
If you want to do so, please, be my guest and implement the cooldown HUD in Tibialyzer and send me a pull request. I like the idea, it's just that implementing will take some time and it's time I don't really have.


Version 0.10.2

Bump version to 0.10.2 and update changelog.

[x] This should be merged after #201.

~I also properly shrinkwrapped the package to npm-shrinkwrap.json, so that's a lot smaller and a lot more reasonable now.~
I completely removed npm-shrinkwrap.json, because it doesn't allow Travis CI to install devDependencies that are necessary to run tests. Then I did some searching around and found this blog that walks through package.json, package-lock.json, and npm-shrinkwrap.json. It's not entirely clear from that blog whether or not we should be using package-lock.json or npm-shrinkwrap.json, because he doesn't explicitly cover what would be appropriate when publishing a plugin type of package on NPM.
However, I googled "hubot plugin npm-shrinkwrap.json" and the only search result was...this very repository. Starting to suspect we had been doing the wrong thing, I searched for "hubot plugin package-lock.json" and got a lot more search results:

Hubot-BotFramework
hubot-rocketchat
hubot-youtube
hubot-home-assistant

And most tellingly, none of those plugins had npm-shrinkwrap.json files!
Due to that, this PR:

[x] removes our npm-shrinkwrap.json file
[x] tweaks .gitignore
[x] regenerated the package-lock.json file

I also figured out that the package-lock.json file saves dev: true for all devDependencies, so we should be able to ignore those dependencies when updating this in st2chatops, and also when generating that project's package lock file. If anybody knows any JS and/or NPM gurus that can double check this decision, please contact them.
I also double checked that our CI builds all actually did pass all of the tests for the node versions that we care about, since they "passed" but should have failed in #200. There's a failure with Node v12, but we don't support that yet so it's not a big deal. We do test it though, and include it as an allowed failure.

Published to NPM. :+1: