Provided a makeServer function on config.js to allow more access to the mirageJS configurations

First PR for discussion in https://github.com/miragejs/ember-cli-mirage/issues/1989
There is really only a small bit of code in a a few files.
addon/ember-data.js
addon/index.js
addon/start-mirage.js
app/initializers/ember-cli-mirage.js
All the other files are test related with most as a clone of test project 1 into test project 3 to show makeServer working.
mirage/config.js can now be written as
import { Server } from 'miragejs';
import { discoverEmberDataModels } from 'ember-cli-mirage';

export function makeServer(options) {
  options.routes = routeHandlers;
  discoverEmberDataModels(options);
  return new Server(options)
}

export function routeHandlers() {
  this.resource('user');
}

Bump

Ok – I think this is what we should do:

/*
  The named `makeServer` function export gives you a lower-level way to hook
  into how your Ember app instantiates your Mirage JS server.

  Typically, the `/mirage/config.js` file contains a single default export which
  is a function defining all your Mirage route handlers. Ember CLI Mirage then
  uses this function, along with all the other modules you've defined in
  `mirage/models`, `mirage/fixtures`, mirage/factories`, and
  `mirage/serializers`, to create your Mirage JS server when your app boots up
  in development and testing.

  You can now opt in to having more control over exactly how your Mirage server
  is instantiated, as well as the ability to use imports directly from the
  `miragejs` npm package, by exporting a single named function called
  `makeServer` instead.

  `makeServer` receives a single argument called `config`, which contains all
  the factory/fixture/serializer/model modules that exist in your project's
  `/mirage` directory. This saves you from having to import each module
  explicitly and then pass it into your Mirage server, just like you're used to
  with the default setup.

  The `config` argument maps exactly to everything inside of your `/mirage`
  directory - notably, it does not contain the autogenerated Mirage model
  definitions derived from your Ember Data models, which is an important feature
  of Ember CLI Mirage that is enabled by default. To replicate this behavior
  when using `makeServer`, we have provided an additional import called
  `discoverEmberDataModels` from the `ember-cli-mirage` package that you can use
  to augment your config with these models so that your Mirage schema is
  automatically inferred from your host application's Ember Data models and
  relationships. The snippet below shows how to do this. Note that the order
  here matters if you also have models defined in your `/mirage/models`
  directory, as those model definitions would "win" in the event of a conflict
  with the ones autodiscovered from Ember Data. (However, most of time if you
  are inferring your Mirage schema from Ember Data, you shouldn't need to define
  additional models.)

  Finally, your route handlers just need to be passed to the `routes()` key in
  your Mirage config. You can do this inline, or you can make them a separate
  function, and organize that function however you choose.

  The only thing needed to enable this behavior is that you delete the default
  function export and instead export a single named function called
  `makeServer`. You should also add `miragejs` to your project's dependencies in
  your `package.json` file, since you are now importing directly from it. Note
  that this gives you the added benefit of being able to upgrade `miragejs`
  independently of `ember-cli-mirage`.

  Eventually, `ember-cli-mirage` will shed its re-exports of everythign from
  `miragejs', and become a small wrapper library delegating the rest of the work
  to `miragejs`. This will help align the Ember Mirage users with the rest of
  the Mirage JS community.
*/

// Example with inline routes
import { createServer } from "miragejs";
import { discoverEmberDataModels } from "ember-cli-mirage";

export function makeServer(config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
    routes() {
      // this.namespace = '/api'

      // this.resource('user')
    },
  };

  return createServer(finalConfig);
}

// Example with routes in an external function
import { createServer } from "miragejs";
import { discoverEmberDataModels } from "ember-cli-mirage";

export function makeServer(config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
    routes
  };

  return createServer(finalConfig);
}

function routes() {
  // this.namespace = '/api'

  // this.resource('user')
}

Basically just change discoverEmberDataModels to return the getModels() result, rather than doing any merging. And then remove the named routeHandlers export. Let's just keep that up to them.
Finally, let's undo the changes to the blueprint. We have some more work to do to deprecate the ember-cli-mirage imports – for example, if they are going to use this, they'll need to install miragejs themselves to import it. (Right now miragejs is a dependency of ember-cli-mirage, so if we wanted to change the blueprint we would need to update index.js to addProjectsToPackage('miragejs'). But then we'd need to think of a migration path for existing users! Let's keep it simple and not do all these changes right now.)

Yep, I forgot the mirageJS doesnt carry through, which is why all the files for import export like belongsTo and hasMany for example. Until these are shed, could we add one more to the pile and just import/export createServer to allow the blueprint to promote the newer way for new installs now? (just re-export createServer instead of addProjectsToPackage('miragejs') would do it pretty unobtrusively)
import { createServer, discoverEmberDataModels } from "ember-cli-mirage";

Didnt think about this syntax, yea if you want the merge to happen here no problem.
models: { ...discoverEmberDataModels(), ...config.models },

The above isnt calling the routes handler correctly is it, shouldnt it be (Ill figure it out in testing)
// Example with routes in an external function
import { createServer } from "miragejs";
import { discoverEmberDataModels } from "ember-cli-mirage";

export function makeServer(config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
    routes: routes()
  };

  return createServer(finalConfig);
}

function routes() {
  // this.namespace = '/api'

  // this.resource('user')
}

actually createServer already is exported in export * from 'miragejs';
index.js
export { default } from 'miragejs';
export * from 'miragejs';
export {discoverEmberDataModels} from './ember-data';

Given
if (config.routes) {
      assert(!config.baseConfig, "The routes option is an alias for the baseConfig option. You can't pass both options into your server definition.");
      config.baseConfig = config.routes;
    }

Which should be be passing into makeServer, routes or baseConfig? Which is the preferred way?

could we just add createServer as one more export from 'ember-cli-mirage'?

Sure, that's fine 👍

should we use routes or baseConfig?

routes() was added so we should go with that. I think baseConig shouldn't be populated basically in the config option passed in, since typically that would come from the default export in mirage/config.js.

Your whole comments above with examples are great, where should I put that? In the docs? Maybe a new nav called "server configuration"

All the test are passing, but getting a linting error
/Users/brian.gantzler/source-personal/ember-cli-mirage/test-projects/03-app-that-uses-make-server/mirage/config.js
  5:5  error  Parsing error: Unexpected token ..

Its complaining about the ...config. Any idea how to get rid of this linting error? or do I exclude the config.js from linting
export function makeServer(config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
  };

  return createServer(finalConfig)
}

Ok fixed the linting
When trying to check the documentation, when running ember s got the following
 Could not find module `fetch` imported from `dummy/instance-initializers/setup-fetch`

added ember-fetch to the package.json, then got the following
[DEP0066] DeprecationWarning: OutgoingMessage.prototype._headers is deprecated
Error while processing route: index Cannot read property 'pathname' of undefined TypeError: Cannot read property 'pathname' of undefined
    at Class.beforeModel (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-aOqs56aH.tmp/assets/dummy/pods/application/route.js:11:1)

Needless to say, have not successfully run the demo app
This PR should have the suggested changes with the exception the blueprint is still altered but is instead
import { createServer, discoverEmberDataModels } from "ember-cli-mirage";

To account for the correct import

Ok, are you able to run the docs app on master? I would try that first and make sure it works on your machine.
(Am I correct in remembering you had trouble getting it running recently?)

Yes it would not start due to an error you fixed (https://github.com/miragejs/ember-cli-mirage/commit/fabd3885cb3a504bf2717af5b417e897801ed776), once it started I thought I was good, but when navigating to the url I now get the above errors.
Yes, I get the same missing fetch on master, add ember-fetch and then get the next error, did not continue fixing errors.
I was looking at the tests directory and there are not really tests, however I think I could write an integration for a fake component that gets data from the a mirage source. If I then use the new config to do that, I could remove the test app 03.  I assume you would like me to look into that given test-03 was a concern earlier?

I think test-03 is fine bc we can delete it if it ever becomes a problem.
We should figure out why the demo app is not working for you though eh?

I am on the master branch,
Yes it now started up, but when I visit localhost:4200 I get the following
Error: Could not find module `fetch` imported from `dummy/instance-initializers/setup-fetch`
    at missingModule (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:247:1)
    at findModule (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:258:1)
    at Module.findDeps (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:168:1)
    at findModule (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:262:1)
    at requireModule (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:24:1)
    at r (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:176:1)
    at resolveInitializer (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/addon-tree-output/ember-load-initializers/index.js:10:1)
    at registerInstanceInitializers (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/addon-tree-output/ember-load-initializers/index.js:33:1)
    at loadInitializers (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/addon-tree-output/ember-load-initializers/index.js:69:1)
    at Module.callback (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/dummy/app.js:13:1)
    at Module.exports (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:106:1)
    at Module._reify (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:143:1)
    at Module.reify (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:130:1)
    at Module.exports (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:104:1)
    at Object.requireModule (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-d6MH0x6H.tmp/assets/vendor/loader/loader.js:27:1)
    at Object.<anonymous> (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/node_modules/fastboot/src/ember-app.js:213:18)
    at VMSandbox.run (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/node_modules/fastboot/src/vm-sandbox.js:18:15)
    at EmberApp.createEmberApp (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/node_modules/fastboot/src/ember-app.js:212:30)
    at EmberApp.retrieveSandboxedApp (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/node_modules/fastboot/src/ember-app.js:237:17)
    at new EmberApp (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/node_modules/fastboot/src/ember-app.js:61:21)
    at FastBoot._buildEmberApp (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/node_modules/fastboot/src/index.js:114:17)
    at new FastBoot (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/node_modules/fastboot/src/index.js:52:10)
    at /Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli-fastboot/index.js:335:29
    at Layer.handle [as handle_request] (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/express/lib/router/index.js:317:13)
    at /Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/express/lib/router/index.js:335:12)
    at next (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/express/lib/router/index.js:275:10)
    at /Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/ember-cli/lib/tasks/server/middleware/broccoli-watcher/index.js:54:11
    at watcher.then.errorHandler.buildError (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/broccoli-middleware/lib/watcher-middleware.js:35:7)
    at tryCatcher (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/rsvp/dist/lib/rsvp/-internal.js:39:19)
    at invokeCallback (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/rsvp/dist/lib/rsvp/-internal.js:211:31)
    at /Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/rsvp/dist/lib/rsvp/then.js:26:14
    at flush (/Users/brian.gantzler/source-personal/ember-cli-mirage/node_modules/rsvp/dist/lib/rsvp/asap.js:80:5)
    at processTicksAndRejections (internal/process/task_queues.js:75:11)

Adding  "ember-fetch": "^8.0.1", to the devDependancies, yarn, then re-run gets this
TypeError: Cannot read property 'pathname' of undefined
    at Class.beforeModel (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/dummy/pods/application/route.js:11:1)
    at UnresolvedRouteInfoByParam.runBeforeModelHook (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/router_js.js:782:1)
    at /Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/router_js.js:691:1
    at invokeCallback (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/rsvp.js:493:1)
    at publish (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/rsvp.js:476:1)
    at /Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/ember-testing/lib/ext/rsvp.js:19:1
    at invokeWithOnError (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/backburner.js:347:1)
    at Queue.flush (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/backburner.js:229:1)
    at DeferredActionQueues.flush (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/backburner.js:426:1)
    at Backburner._end (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/backburner.js:960:1)
    at Backburner._boundAutorunEnd (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/backburner.js:629:1)
    at run (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/vendor/babel-polyfill/polyfill.js:4580:1)
    at /Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/vendor/babel-polyfill/polyfill.js:4597:1
    at flush (/Users/brian.gantzler/source-personal/ember-cli-mirage/tmp/broccoli_persistent_filtersimple_replace-output_path-PhXytBhA.tmp/assets/vendor/babel-polyfill/polyfill.js:1709:1)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

Do not know what this error is so couldnt continue
I would think if you cloned the repo you would get the same thing

Noticed that there were some dependency updates on master. Rebased and now the docx app runs again. Did have a slight missing entry. Fixed that.
PR should be good to go now.

Hopefully we have gotten past all the hurdles and we can get this merged so I can get the Original PR that started all this finished 👍

Only last q is, should we change the default blueprint? I kinda think we should leave it alone since makeServer is more of a power user feature and currently undocumented.

In order to reduce the foot print of ember-cli-mirage at some point you would have to deprecate and make the makeServer function mandatory. If we change the blue print now, fewer people will be affected by the change, they just ignore the boiler plate code and change the route function as before, if they need the more advanced its setup for them and ready to go.
If I were a new user, I would have liked that you saved me an eventual change down the road. If you dont plan on deprecating and removing then old way, then I would say yes, maybe not change the blueprint.

Definitely plan on deprecating + removing but, I think you might be underestimating how confusing this would be for someone new to the addon, especially since it's not documented anywhere on the site yet, and all the examples show something different when referencing the mirage/config.js file. I think we should leave the blueprint alone for now and change it when we decide to tackle the rest of the migration step.
Thanks for keeping pushing on this + sorry it's taken me a while to go back and forth!

Maybe you might to add some comments above the make function similar to what type script does for boilerplate code.
// DO NOT DELETE: this is how TypeScript knows how to look up your controllers.
declare module '@ember/controller' {
  interface Registry {
    'application': Application;
  }
}

I like it at the top, because I would move the routes to another file, but we could move it to the bottom maybe? I didnt put the enitre comments you added above in the blueprint, that seems a bit much, but we could put the whole thing there if we moved it to below the routes function.  Or maybe an abbreviated set of those comments

K, Ill change it back then, give me a few

Yeah I think we could come up with some way to document it via comments but it feels like rushing it, I say we just wait until we can actually document this.

I thought about this and Ill add just these points.
As a new user, if I cant find what I need in ember-cli-mirage, I might go to the mirageJs website and there all the examples talk about configing the server a completely different way, if I saw the make server function, I would see some common code between MirageJs and ember-cli-mirage to help bridge that gap.
Second, the followup will be the work I did for reverse engineering the serializers much the way you do with models. I would like it to be part of this addon instead of its own but either way the point is the same, it will only be supported under the makeServer option (why we started down this road), which means in order to use the new feature, they would be forced to change the config rather than add an import and a  property to the options config (new users only of course, cause thats where the blueprint comes into play)
I started looking through the examples in the guides and under the functions tab the first example is this
// mirage/config.js
this.get('/movies', () => {
  return [ 'Interstellar', 'Inception', 'Dunkirk' ];
});

It says config.js, but clearly is not showing the entire config, just the part your interested it, so in overview when it lists this
// mirage/config.js
export default function() {
  this.namespace = 'api';

  this.get('/movies', () => {
    return {
      data: [
        { id: 1, type: 'movies', attributes: { name: 'Interstellar' } },
        { id: 2, type: 'movies', attributes: { name: 'Inception' } },
        { id: 3, type: 'movies', attributes: { name: 'Dunkirk' } },
      ]
    };
  });

}

the same would imply, you are talking about this function, not showing the entire config. So if we went back to export default unnamed, I dont think any of the current docs would be misleading. (By doing so they do have to infer later it doesnt have to be export default, you can name and use. not so much an issue.
So some food for thought. Ill change the blue print back, but easy enough to put back in later

Understood and appreciate the thoughts. I think I just want to do a bit of planning so we can tie up all these loose ends together. Ryan and I are going to be shipping Mirage v1 in a month from now and I want to get ember-cli-mirage users basically reading those docs and get rid of the majority of these ones. I think that will be a good time to revisit this. In the mean time we can document in a guide on this site.

Ok, I think this is good to go?

I agree, other than the blueprint revert that wouldnt matter, I have converted my company app over to use the branch and all the tests worked as expected (thats where i found the qunit thing so its a good thing I did that)

For the next question though, are you open to adding the serializer generation in this addon or do I need to make another (which I can now do because of this PR)

Any idea when this may be merged and I can move onto the serializer generation?

Sorry I think I was waiting for tests to pass last time!
Can you open new issue laying out the serializer APIs you need so we can discuss there?


Is node.Status.Allocatable much better than node.Status. Capacity in calculating total cores?

Allocatable on a Kubernetes node is defined as the amount of compute resources that are available for pods. In production environment, we often reserve 1 or more cpu core for system,  so the difference of total core numbers  is huge in a large cluster(eg 1000 nodes).
If this is a real problem, I can submit a pr for it.

@lemonli Apologies for the late reply. It makes sense to me that node.Status.Allocatable indicates the state more accurately. PR wellcomes!

PR has merged.


_mm_undefined_ps missing on old clang

Packet.h has test code to define _mm_undefined_ps if it's missing on old GCC. Old Clangs, though, also don't have this instruction, causing build failures: example Travis failure.
I was able to work around it in the conda-forge package we're adding with a dumb patch, which I'm only applying for our OSX builds. You shouldn't put this in Adept, because it's incorrect (if _mm_undefined_ps is defined as a function rather than a macro, as it actually is, it'll override that definiton), but there should probably be a version check for clang too.

Could you please fix this? I am seeing the same problem in the FreeBSD port in systems with older clang versions.

Should be fixed in latest push.

Thanks! Please consider making a release because the port sources it from http://www.met.reading.ac.uk/clouds/adept/ which doesn't get latest pushes.

Will do on Monday hopefully - have one further issue to resolve and then need to test with a larger application before I can be sure it's ready for a release.

Thanks!

Support for _mm_undefined_ps was added in clang 3.8, if you wanted to support it there too. (It was added in this commit, which via git branch -a --contains 85a91ffe is present on the release_38 brach.)

I think it can be done with #if __has_builtin(__builtin_ia32_undef128)
This seems to work in the latest commit (only tested on Clang >= 3.8, not Clang < 3.8).

2.0.5 now released at http://www.met.reading.ac.uk/clouds/adept/

Thanks!

With no reports to the contrary, I will assume that 2.0.5 fixes this issue


Open datapackage.json from local file

Desired Behaviour
This feature didn't make it into v0.15.0. This is less useful than:

Open datapackage.json from URL
Open datapackage.zip from local file
Open datapackage.zip from URL

... that were implemented via https://github.com/ODIQueensland/data-curator/issues/284
Will add this to v1.x.x for prioritisation

Some browsers automatically unzip zip files when they're downloaded. This makes this feature a little more desirable

Also my mac is pretty clumsy when it comes to zip files. I eventually got there and managed to put together a test zip file, but it would have been nice to have a JSON option from file to help things along. It's a nice to have though.


Comfy Organization

Hi ,
First off, Comfy is very useful for my projects. And as the codes got bigger, many projects are harder to manage. I found that some useful PR are pending for a while. Namely the translation for pages and live preview.
Can I ask if comfy has existing github organizations now?  Or the community want to create one and get more people to do the project merging and operation tasks?
https://github.com/blog/674-introducing-organizations
I am very happy to help for the project tasks.

Comfy is a Github organization. But it's just me here.
There's not much of a problem with pull request merging as bug fixes and small improvements get merged in pretty quickly. What usually sits around for a long time are pull requests that introduce a lot of changes. Sometimes I want to merge it, but it takes time to polish it before merging. Other pull requests might not get merged if I think they provide less than optimal solution. Very subjective, it's just I want to maintain this project over a long time, so I want to keep everything in a state I can work with.
There are few pull requests open (like the i18n one) that I'll keep open until I'll come up with solution that deals with content internalization properly. There's nothing wrong with using forks if it works for you for the moment.
About helping. There are a few issues open that need to be dealt with. Feel free to tackle those. It always takes considerable time to debug those.


FIX CN parsing to work with OpenSSL 1.1

CN used to be without whitespaces around the = but OpenSSL 1.1 introduced
whitespaces:
1.0.1: subject=/CN=example.com
1.1.0: subject=CN = example.com
This commit makes them optional.

There are already several other PRs for this (#169, #168, #156), but so far none was merged.

PLEASE will somebody merge this in (is this project being maintained or not?)--I just got burned by it.

It was being critical-only maintained, but work is now getting to the point where I can start to dig through pull requests and issues. Whew!


Add ability to paste multiple tags at once

Howdy! There is currently no way to paste multiple (delimited) tags at once.
When a string that contains multiple delimited tags, the handleAddition callback will fire for each delimited tag simultaneously.
The issue is that when a handler like this  handleAddition={tag => setTags([...tags, tag.text])} fires multiple times, set tags has no recollection of the other tags you attempted to simultaneously add. The result is that you will always just get the last pasted delimited value added to your tags, not all pasted values.
I think a decent solution that wouldn't break backwards compatibility would be to add a handleMultipleAddition handler that receives a callback function. The parameter of the callback function would be an array of all pasted in tags. If handleMultipleAddition is undefined, just fall back to the old behavior of simultaneous multiple firing handleAddition.
Reproducing this issue is very easy, it is present in the repo's provided StackBlitz demo. Just past in a string that contains multiple delimited values. For example: "Chuck, geppi" will only add "geppi" as a tag.

Hey, I was able to figure out a workaround

Set allowAdditionFromPaste prop to false.
Put the tag component inside a div (or other container element). Add this

onPaste={event => {
        console.log(event.clipboardData.getData('Text'))
        event.preventDefault()
      }
}

preventDefault prevents this library from picking up the paste event whatsoever! Feed the clipboard text into a helper function if needed (to split by delimiter, remove blank tags, and remove duplicates). For example:
  const splitAndAddMultipleTags = (text: string) => {
    const newTags = text.split(/\r?\n/).filter(tag => tag !== '' && !tags?.includes(tag))
    setTags([...tags, ...newTags])
  }


GraphQL

GraphQL support at /services/graphql and some general cleanup

Codecov Report
Patch coverage: 63.88% and project coverage change: +0.15 :tada:

Comparison is base (01826db) 55.35% compared to head (621ad74) 55.51%.

:exclamation: Current head 621ad74 differs from pull request most recent head 3490254. Consider uploading reports for the commit 3490254 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #44      +/-   ##
==========================================
+ Coverage   55.35%   55.51%   +0.15%
==========================================
  Files          24       24
  Lines        3405     3437      +32
==========================================
+ Hits         1885     1908      +23
- Misses       1520     1529       +9

Impacted Files
Coverage Δ

types/spa.js
65.66% <0.00%> (ø)

types/component.js
53.63% <50.00%> (-0.09%)
:arrow_down:

types/server.js
49.47% <70.00%> (+0.77%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


DRAFT: Geolocation

[x] Refactoring Prometheus gauges out to struct
[x] Implement ip-api lookup methods
[x] Implement database for caching (with expiry)
[x] Implement an appropriate Prometheus gauge for exporting

Should be ready for testing now!


nit: Correct the used SSH key in ansible inventory

We were missing the right ssh key configuration in the generated ansible
inventory, leading to "some" issues.
We also ensure ansible won't complain about the remote host keys. A
better solution might come later, once we're over the deep network
refactoring
As a pull request owner and reviewers, I checked that:

[X] Appropriate testing is done and actually running

/approve


update the encryption and signing specs to reflect the field order we shipped

The Go msgpack encoder we're using has a counterintuitive order for
struct fields when serializing as arrays. We meant to put the final flag
at the end, but it's actually at the beginning (though not for
signcryption mode). Update the v2 specs to reflect this unfortunate
reality.
r? @mlsteele @akalin-keybase

Coverage remained the same at 84.746% when pulling e64539d34dfd48c737c2adafbd367eb674f3303a on jack/flag_order into 72dc788e7609e9c2c2700f22ef0b7f981223ca99 on master.

Oh, man, this is probably my fault, sorry. :( Can you point me to the docs about the struct order?
Why is it too late to fix? I'm guessing we've started writing sigchain stuff with saltpack v2?

@akalin-keybase, we turned on V2-by-default for keybase encrypt and keybase sign last week. There are probably documents in the wild using the current behavior, that would break if we changed it without supporting the current version for all of time. So...we could fix it in v3?

@akalin-keybase I assume it's a low level detail of how Go reflects over struct fields, and not a specific decision the codec makes?
I ran into it first when I was starting to bring https://github.com/keybase/saltpack-python up to speed with v2, though I kind of glossed over it at the time. Then @gherynos ran into it updating https://github.com/Gherynos/libsaltpack, and he messaged me over Keybase chat.

Ah, I see. It's a bit worrisome, since we serialize to arrays in a few other places in KBFS.
Digging into the ugorji/codec source, it looks like it relies on reflect.Value.Field ( https://golang.org/pkg/reflect/#Value.Field ) which doesn't mention any guarantees as to ordering, or whether it may change (although that would probably break a lot of stuff).
https://stackoverflow.com/questions/32392311/reflect-type-field-order doesn't mention any other official sources.
I'll ask around on the golang lists to see what the official word is. I'll also probably file an issue with ugorji/codec to clarify its documentation, too.

At least in the saltpack case we should have some tests that fail now if the order changes. But yes, I agree it's worrisome.

ILT replied to my query: https://groups.google.com/d/msg/golang-nuts/_he7g1TL0K8/8BBCFB0tCgAJ
I'll try to repro, and see if this is a bug in ugorji, or maybe our old fork of it.

Hmm, looks like reflection doesn't inline the fields of the embedded struct:
package main

import (
	"fmt"
	"reflect"
)

type S1 struct {
	Foo int
	Bar int
}

type S2 struct {
	S1
	Baz int
}

func main() {
	mystruct := S2{}

	t := reflect.TypeOf(mystruct)

	for i := 0; i < t.NumField(); i++ {
		fmt.Printf("Found field: %s\n", t.Field(i).Name)
	}
}

Prints:
Found field: S1
Found field: Baz

Yeah, I came to the same conclusion. Must be a bug in ugorji/codec, looking...

It's a bug in our fork of (an old version of) ugorji/codec: see https://play.golang.org/p/IiMPOFv9kF for a program that behaves differently depending on whether ugorji/codec or keybase/go-codec/codec is used.
sigh We should probably update our fork. But now we'll have to be super-careful doing so, and probably do it a repo at a time, so that we don't mess up anything else relying on this old behavior.

Thanks Fred. If we get to this update for saltpack, I'd say we should just stop using inlining for our array structs and hardcode the current behavior, to work around the back-compat issue.

Yeap, SGTM.


Add support for ShellBolt

The Storm has a ShellBolt that shells out to another process to process tuples. As requested in #1024, heron needs to support it.

@caofangkun - this is related with the #1024

@caofangkun How is the ShellBolt support going on? If you need any help, please let us know.


Let util.ResolveName() return parsing errors

Allow util.ResolveName() to return errors from libraries that it uses.

I think this'll fix the problem @hettipeti was seeing in #468.

The Fedora Container Registry is currently undergoing planned maintenance, so our tests that expect to reach it are failing.

bot, retest this please

LGTM

bot, retest this please

bot, retest this please

@rh-atomic-bot r+


building libratbag, can't find libevdev

I'm new so I apologize.
I am trying to build libratbag so I can get piper working to program my mouse, but I've ran into a wall. At first it was gcc, then libudev, but now I'm stuck on libevdev. On fedora, I have 1.5.9-4.fc28 and the devel 1.5.9-5.fc29 installed but meson still can't find it and I'm not sure what is going wrong. Thanks for your time.
meson-log.txt

sudo dnf build-dep <packagename> installs the required bits on fedora, or at least the ones used for the fedora package itself. Then it's just down to using the same config option, usually easiest by looking at the .spec file. Alternatively, and more generically, this post here describes how to fix things one-by-one.In your case, sudo dnf install libevdev-devel should do it, would be a bit strange to have a fc28 and f29 mix here.


show contiv parameters in docker network inspect

When a docker network is created by netplugin/netmaster, it would be good to allow folks to use docker network inspect to know the options that were used by netctl to create the network. this can help correlate the output with contiv networking parameters. For example pkt-tag can show up as an option in the following output:
$ docker network inspect contiv-net
[
    {
        "Name": "contiv-net",
        "Id": "ed6ba9dfa6f7e271c2dc8d0a87c6cb0b773e43de9a6e2a48726433e742b7b4fe",
        "Scope": "global",
        "Driver": "netplugin",
        "IPAM": {
            "Driver": "default",
            "Config": [
                {}
            ]
        },
        "Containers": {},
        "Options": {
            "pkt-tag": "1001"
        }
    }
]

@jainvipin PR https://github.com/contiv/netplugin/pull/257 is raised for this.

#257 resolved this. This can be closed now.


git clone https: vs git clone git@

Tried cloning the repository on both Windows and Ubuntu using the git clone command from the readme:
git clone git@github.com:ethersphere/bee-dashboard.git
Cloning into 'bee-dashboard'...
The authenticity of host 'github.com (<IP_ADDRESS>)' can't be established.
RSA key fingerprint is
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,<IP_ADDRESS>' (RSA) to the list of known hosts.
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
but that failed on both platforms, but the following worked:
https://github.com/ethersphere/bee-dashboard.git

Thank you for putting this forward. Yes<EMAIL_ADDRESS>requires ssh token and using the http might be better. That being said I believe this issue will be resolved by #88 :)


ResponseException in RestTool.php line 335: Unauthorized

ive set up the sdk in laravel but when i try to create a natural user i get
ResponseException in RestTool.php line 335:
Unauthorized

Hi @devngenious - does everything work correctly for other functions? I'm guessing not and hence it is most likely because your Passsphrase/ClientId/Environment combination is wrong somewhere :-/


update(Storage): Send Files from Storage to several chats

What this PR does 📖
1. Send Files from Storage to several chats
https://github.com/Satellite-im/Uplink/assets/63157656/77403c4c-6a2c-407f-ad62-f23cf1396c8b
Which issue(s) this PR fixes 🔨

Resolve #1184

Special notes for reviewers 🗒
Additional comments 🎤

I looked through the automated tests results logs and looks like there is an issue when compiling for Windows:

also i can select the chats but i cant select any files in this view

the chats preview all says ''no messages'' but it has messages they appear in the preview in the sidebar chats list


Add DNS check if IPs are valid

I just disovered that Goss is not having any options to discover whether IPs are valid in DNS check.
Scenario which I would expect goss have extra checks:
Lets say that there is domain 'domain.zone' and is configured to have three A records (<IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>).
Goss checks looks like this (and this is working):
dns:
  domain.zone:
    resolvable: true
    addrs:
      - <IP_ADDRESS>
      - <IP_ADDRESS>
      - <IP_ADDRESS>

However if new IP is added to this pool - goss will still show everything as OK / Passed. What would be nice to have optional argument to check if there is no additinal IPs (for example 'expect_the_same: true').
From my point of view this is very valuable in terms of deteting issues with dynamically adjusted DNS and prevent for spoofing DNS. For example somebody added malisious IP to DNS records. So traffic still going to legitimate IPs - but from time to time is going to 'extra IP' which is not legitimate.
This way goss can help detect this change really quickly.

consist-of is what you can use to accomplish this, see the gomega docs here for details: https://onsi.github.io/gomega/#consistofelement-interface
dns:
  amazon.com:
    resolvable: true
    addrs:
    - <IP_ADDRESS>
    - <IP_ADDRESS>
    - <IP_ADDRESS>
    timeout: 500

dns:
  amazon.com:
    resolvable: true
    addrs:
      consist-of:
        - <IP_ADDRESS>
        - <IP_ADDRESS>
    timeout: 500

output:
.F

Failures/Skipped:

DNS: amazon.com: addrs:
Expected
    <[]string | len:3, cap:3>: ["<IP_ADDRESS>", "<IP_ADDRESS>", "<IP_ADDRESS>"]
to consist of
    <[]interface {} | len:2, cap:2>: [
        {
            Expected: "<IP_ADDRESS>",
        },
        {
            Expected: "<IP_ADDRESS>",
        },
    ]

Total Duration: 0.016s
Count: 2, Failed: 1, Skipped: 0

Feel free to open a new issue or comment on here if this isn't resolved for you.


Utilise frontend:dev:watcher

As of 33 beta we now have a frontend:dev:watcher functionality so we can strip out the existing method of doing this
https://github.com/wailsapp/wails/releases/tag/v2.0.0-beta.33

This is already done


Recurring transaction doesn't recur in the past

Steps to reproduce the behaviour

Add transaction
Set the date to a year in the past
Set recurring period to monthly for n times

Expected behaviour
Should create transactions until today, like desktop app.
Actual behaviour
Only the original transaction created
Software specifications

GnuCash Android version:
System Android version:
Device type:

If bagsying a bug helps secure an issue then I'd like to try this before about Monday.

@ployt0 go for it :)

I can confirm this course of events.
As I don't use the desktop version can I see how recurring transactions should look?

I found several other bugs on my way to fixing this, I can't spare the time to fix this one, it is only good first-issue if the result intended is finding smaller bugs.

Thanks for finding the other bugs. If you were working on master, you should probably be working off the develop where some stuff is already fixed.


fix(sbb-menu): disable page scroll on mobile

Disable scrolling of the page underneath the menu backdrop on mobile and change 'pointer' events to 'mouse' events (e.g. pointerdown --> mousedown) to fix the behaviour in Safari.

Codecov Report

Merging #1614 (af925f9) into master (ab917b0) will decrease coverage by 1.52%.
The diff coverage is 50.98%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##           master    #1614      +/-   ##
==========================================
- Coverage   54.85%   53.33%   -1.52%
==========================================
  Files          49       79      +30
  Lines        1659     3600    +1941
  Branches      406      968     +562
==========================================
+ Hits          910     1920    +1010
- Misses        671     1550     +879
- Partials       78      130      +52

Impacted Files
Coverage Δ

...mponents/sbb-accordion-item/sbb-accordion-item.tsx
0.00% <0.00%> (-37.21%)
:arrow_down:

src/components/sbb-icon/sbb-icon.tsx
91.66% <ø> (ø)

src/components/sbb-image/sbb-image.helper.tsx
62.06% <ø> (-2.45%)
:arrow_down:

src/components/sbb-image/sbb-image.tsx
69.09% <ø> (+6.12%)
:arrow_up:

...mponents/sbb-journey-header/sbb-journey-header.tsx
88.23% <ø> (+1.27%)
:arrow_up:

...onents/sbb-journey-summary/sbb-journey-summary.tsx
81.63% <ø> (ø)

src/components/sbb-link-list/sbb-link-list.tsx
84.00% <ø> (-4.24%)
:arrow_down:

src/components/sbb-link/sbb-link.tsx
60.41% <ø> (-31.02%)
:arrow_down:

src/components/sbb-logo/sbb-logo.tsx
0.00% <ø> (ø)

src/components/sbb-menu-action/sbb-menu-action.tsx
65.21% <ø> (ø)

... and 85 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Basically LGTM However according to MDN and caniuse pointer events should be supported by Safari. What is the behavior you experienced?

You're right, I should have specified that the bug only occurs on Safari mobile and I agree that it should be working but, it just doesn't as soon as you test it outside of the Storybook's iframe (in full-screen mode) with "pointerdown" and "pointerup". As if these events are not detected at all.


cppcheck: error: unrecognized command line option: "--max-ctu-depth=4".

Hi there, thank you for this useful tool.
i have an issue while running static analysis task. max_ctu_depth is not recognized
Action: https://github.com/BaderEddineOuaich/Enigma/runs/1455710276
static-analysis.yml file
# Enigma Static Analysis task using CppCheck
# https://github.com/marketplace/actions/cppcheck-action
name: static-analysis

# analyse on pushs and pull requests on master branch
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:
    name: cppcheck
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: cppcheck
        uses: deep5050/cppcheck-action@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN}}
          github_username: "BaderEddineOuaich"
          github_email<EMAIL_ADDRESS>          #commit_msg: "<optional commit message>"
          #check_library:
          #skip_preprocessor:
          enable: warning,portability,performance
          exclude_check: ./Dependencies/
          #inconclusive:
          #inline_suppression:
          force_language: c++
          max_ctu_depth: 4
          #platform:
          output_file: ./Static-Analysis-Report.txt #(default cppcheck_report.txt)

Thank you

Thanks again from the human side. I'm working on this. The check passed on error ! that is also a bug. Let me fix this and get back to you.

/cib

This action now uses the latest cppcheck (2.22) eliminating this bug. you need to update your workflow file slightly to run latest version of cppcheck. check the readme of this repo, i have updated few things.
default branch has been updated from master to main.

Only limitation: you can not edit commit message for the report while pushing. ( planned for next release)

Please test it and let me know.
Thanks

Hi @deep5050, thank you for the effort!
i updated .yml with the same changes you added. although it seems that the problem still exists.
i noticed in the cppcheck task in https://github.com/BaderEddineOuaich/Enigma/runs/1460906514
that its cppcheck version is still version 1.86, not sure if i should add something in my side to use version 2.22 or its external.

Already on 'master'
Your branch is up to date with 'origin/master'.
fatal: pathspec './Static-Analysis-Report.txt' did not match any files
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
Everything up-to-date
given command cppcheck  --enable=warning,portability,performance -i ./Dependencies/ --inconclusive --language=c++ --max-ctu-depth=4 --output-file=./Static-Analysis-Report.txt .
checking version
Committing reports.......

Thank you!

change
uses: deep5050/cppcheck-action@master
to
uses: deep5050/cppcheck-action@main

it works now after changing master to main!
Thank you for the effort @deep5050


chore(whale-api): whale api migration

What this PR does / why we need it:
Initial steps of migrating whale into the jellyfish ecosystem.
Which issue(s) does this PR fixes?:

Fixes #977
Additional comments?:
Since whale is still seeing quite a bit of activity we need to try to approach this in a way that allows us to bring any updates over from whale into the jellyfish without introducing a lot of refactoring overhead.
I think step one here is simply getting all the files from whale situated into jellyfish where all tests pass and we can run whale within jellyfish without issues. And emphasizing again being able to do so without major conflicts when moving updates over from whale.
packages/whale-api-client is a very straight forward port, no src files has been modified so we can simply just copy the package src from whale to jellyfish without issues. Only thing here was moving the api tests to apps/whale-api as they are dependent on the whale-api source code.
apps/whale-api is mostly straight forward, since the project was relying on custom paths which we cannot support in jellyfish this way we have to update all the imports within whale-api not to rely on these paths.
To solve this I wrote a small temporary migrate.js script that updates all the imports to be either relative or pointing to the new location of whale-api-client. This allows us to simply copy the whale src folder and dump it in when whale is updated. Just run the migrate script and it should all be good to go.

The solution here aims to not touch any src code since the src is in active development outside of jellyfish. Once we have hydrated the PRs in whale and are ready to move our whale development into jellyfish we can remove the migrate and deprecate whale repository.
I think once we have fully migrated over our development efforts we can look at actually refactoring whale-api to match ocean and playground.

Please discuss with other potential avenues or better approaches.

Quick update here to spark some discussion on how to approach this migration.
Now I am imagine the end result here is that we want to consolidate all our development efforts into jellyfish. I am not quite sure how we see ourselves optimally make this transition. Mainly on the back thought that whale still has open PRs.
I think currently my first priority is to get whale working in jellyfish, once that is done I think we can formulate a final strategy for how we want to transfer current work in Whale over into Jellyfish. I do see some older PRs that we can just have each author port over manually.
I have at least set it up to easily move updates to Whale over into this PR as we go so that is not a huge concern atm. The biggest point to be made is that once we start working in jellyfish rather than in whale we want to lock down the src at that time and not do anymore work in whale.
I am still working out some kinks to get tests to work, and I also need to get it running in jellyfish. Once that is done I think we can pull the trigger on transferring work from whale to jellyfish.
Please let me know your thoughts and correct some of my misconceptions where applicable 🙏🏻

For some reason in whale if you delete the package-lock.json file and node_modules folder and do a npm i the following line of code fails.
After poking @canonbrother about this issue we are both rather baffled by why this would be the case since the lock files doesn't seem to change the dependencies in any discernible way.
This is currently presenting a small blocker for progressing on this PR.

I think currently my first priority is to get whale working in jellyfish, once that is done I think we can formulate a final strategy for how we want to transfer current work in Whale over into Jellyfish. I do see some older PRs that we can just have each author port over manually.

Yup, that's sound first priority towards getting DeFiCh/whale project to fit into DeFiCh/jellyfish structure.

Quick update on progress here.
I have finished the initial structured migration of whale into jellyfish. Tests should be passing and builds are executing successfully.
I think the next step here is to finish up whale priority PRs, and once they are merged I do a final port of whale src code and finalize the PR ready for review (meaning we no longer expect anymore merges in whale).
Once that is done I will need an assist in ensuring all the deployment stuff is good to go. Once done this should be good to merge and we can continue any performance tweaking in jellyfish going forwards.

@fuxingloh need your assist/clarification on two subjects.
State of whale in relation to this migration. As it stands whale still has active PRs, so I think that this PR can stay frozen until there are no priority PRs in whale or we decide not to merge anymore PRs and rather focus on moving work over to jellyfish somehow. Please advice what steps you think is the best here in terms of what approach to take as I think its now technically ready to go (just needs a final version of the whale code before we can merge)
Second query is about deployments, I am assuming whale api gets deployed somewhere. I am not seeing an obvious path of deployment, could you point me in the right direction on how we can confirm the jellyfish setup works as needed for deployment purposes now that it will be deploying out of jellyfish > whale.
Will focus on other tasks until we are in a more defined space for finalization on this PR.

State of whale in relation to this migration. As it stands whale still has active PRs, so I think that this PR can stay frozen until there are no priority PRs in whale or we decide not to merge anymore PRs and rather focus on moving work over to jellyfish somehow. Please advice what steps you think is the best here in terms of what approach to take as I think its now technically ready to go (just needs a final version of the whale code before we can merge)

Yup I agree, I think it's 1-2 weeks away and we can freeze DeFiCh/whale development for migration.

Second query is about deployments, I am assuming whale api gets deployed somewhere. I am not seeing an obvious path of deployment, could you point me in the right direction on how we can confirm the jellyfish setup works as needed for deployment purposes now that it will be deploying out of jellyfish > whale.

It's related to this 2 tasks:

https://github.com/DeFiCh/jellyfish/issues/942
https://github.com/DeFiCh/jellyfish/issues/943

Will focus on other tasks until we are in a more defined space for finalization on this PR.

Thanks!

@fuxingloh quick ping for time-frame update


Not pull in win dependencies when not on windows

This should avoid a bunch of unnecessary compiling (even download?) when not used on windows.

Thanks!


use scaffolding v0.4.6.

Signed-off-by: Ville Aikas<EMAIL_ADDRESS>
Summary
Bump to use scaffolding 0.4.6 which fixes stability issue with Fulcio crashing on startup.
Release Note

Documentation

Codecov Report

Merging #2201 (d9b5c37) into main (58d22a8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2201   +/-   ##
=======================================
  Coverage   26.69%   26.69%
=======================================
  Files         131      131
  Lines        7690     7690
=======================================
  Hits         2053     2053
  Misses       5376     5376
  Partials      261      261

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


emit helpful error hint for classmethod with receiver

As per the UI test, this adds a better error message when using #[classmethod] on a function with a receiver.
Will skip changelog as this doesn't affect what code will compile.

I will merge this now so it can go in 0.20. I don't think it's controversial.


Parallelism without Rayon

Rayon introduces a lot of unsafe code to the dependency graph - at about 2000 unsafe expressions according to cargo-geiger, accounting for over 80% of all unsafe code. This undermines the value proposition of the safe Rust decoder: the entire point of it is implementing a decoder in safe code; if you're OK with depending on unsafe code that's probably fine, you should just use libjpeg-turbo.
It would be nice to experiment and see if we can match the performance of Rayon without pulling in all of its dependency tree.
Right now jpeg-decoder uses Rayon for just one line of code: https://github.com/image-rs/jpeg-decoder/blob/97742b3fd692e04eaae4f368110275c7151eacf8/src/decoder.rs#L853
It should be fairly trivial to replicate what Rayon does here using manually spawned threads and an MPMC channel to distribute work items to the threads. flume is a 100% safe code implementation of an MPMC channel that's on par with crossbeam in the use cases that are relevant here. I'm not sure if that's the right approach, but it's probably worth a shot.

I've taken an experimental stab at this. It seems we'll still need crossbeam-utils for scoped threads, but we could still get rid of crossbeam-deque and rayon dependencies which are ~500 unsafe expressions each.

Which might be a very good thing, since crossbeam-deque is pulling some dubiously legal tricks: https://github.com/rayon-rs/rayon/issues/812
and all major single-threaded deque implementations in Rust had serious memory bugs, and crossbeam-deque has even less chance to be correct than the much simpler single-threaded impls...

My initial implementation - full of unwrap(), but probably functional - can be found here: https://github.com/Shnatsel/jpeg-decoder/tree/rayonless
So far it's decoding https://commons.wikimedia.org/wiki/File:Sun_over_Lake_Hawea,_New_Zealand.jpg in 332ms as opposed to 308ms with Rayon, but the code is quite naive so far.
Profile on the same image: https://share.firefox.dev/36T6adS
This shows that the worker threads are under-utilized. Dividing the work into larger chunks should do the trick; I believe that's what rayon does as well.

The addition of some naive batching has put the custom impl in line with Rayon, and even made it faster by a tiny bit - 305ms vs 308ms with Rayon. That means the approach is viable!

This is exciting to see! It looks like it will be possible to avoid the rayon dependency without too much added complexity and without incurring a performance regression.

I've tried adding some heuristics for batching and choosing the number of CPUs, but so far all it did was regress my benchmarks across the board


Firebase reference clean up

Fixes #390
All Submissions:

[X] Have you followed the guidelines in our Contributing document?
[X] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

@phriscage One of the jwt setups within default-jwt-policy.yaml can be removed I think with the removal of firebase. Do you recall if you did that already?


Server streaming of real blocks triggers infinite loop in Helidon's FlowControl mechanism

Description
While testing server streaming for Block Node, I found the outbound connection to the client stops sending data after about 20 seconds.

I was using the 10k TPS recorded blocks
I tested with 3 different gRPC clients (Postman, BN Simulator Consumer, grpcurl)
I tried changing the default to:

final Http2Config http2Config = Http2Config.builder()
                .maxFrameSize(1024 * 4096).build();

but changing the maxFrameSize did not mitigate the issue.
Steps to reproduce

Start the server
Connect a gRPC Server Streaming client
Connect the Simulator producer to the BN server and start sending the 10k TPS recording
Watch the blocks arrive at the simulator. Before block 300, the connection will hang. See screenshot below

Additional context
JProfiler capture of the looping thread:

Breakpoint in the infinite while loop:

The while loop checks to see if getRemainingWindowSize() is less than 1. The value remains below the threshold and the thread is stuck:

Hedera network
No response
Version
Helidon 4.1.1
Operating system
macOS

I tried the following scenarios:
Using 10K TPS Recording.
All clients involved, Consumer Simuator, Postman and grpcurl, died within the first 300 blocks.
Using a single block indefinitely, a small block.
Postman died withing the hour.
consumer simulator also died within 30 mins
grpcurl lasted for around 6 hours and eventually hung up.

Was also able to replicate the issue using a slightly modified version of an example provided by Helidon themselves:
https://github.com/helidon-io/helidon-examples/tree/helidon-4.x/examples/webserver/grpc
Thus confirming that is a Bug on the framework. Will prepare a bug ticket on their repo soon and link to this one.

Helidon fixed this issue with this PR. I've confirmed 4.2.0-SNAPSHOT fixes this issue in the BN but I'll wait until they formally publish 4.2.0 to close this issue.


Log configuration in ruff_dev

Summary This includes two changes:

Allow setting -v in ruff_dev, using the ruff_cli implementation
debug! which ruff configuration strategy was used

This is a byproduct of debugging #6187.
Test Plan n/a

Current dependencies on/for this PR:

main

PR #6187

PR #6193   👈

This comment was auto-generated by Graphite.


Generic client

There is a way to create a pop up for vue but none for people who don't use vue, for example Svelte users

@ghostdevv see this comment https://github.com/antfu/vite-plugin-pwa/issues/65#issuecomment-845202658

@userquin I don't use Svelte Kit, I use Routify

You have the component there inside components folder  just use it as a guide.

@userquin there would be significantly less boilerplate if this vite plugin offered a generic solution, if generic isn't possible then a svelte and react alternatives

@ghostdevv I'm finishing the new docs, you can view the new docs package, and for framework just go to docs/frmawoework directory, PR are welcome. I have included vue (vue 2 and 3 exmaples) and vitepress.

How does this relate to generic/framework specific clients? A little confused :sweat_smile:

@ghostdevv This repo will not include any ui component framework, the new docs will just include some minimal ui snippet so ppl can use it as a guide: we'll include main frameworks without any ui framwork, and so we will have vue, svelte and react.
See this page markdown file: https://github.com/antfu/vite-plugin-pwa/blob/master/docs/frameworks/vue.md
There will be one for each framework with the snippet mentioned above.

Sounds good

@ghostdevv Can you provide a repowith a minimal repro where I can play with svelte and Routify?

@ghostdevv I close this issue, added hint on #88

@ghostdevv see https://vite-plugin-pwa.netlify.app/frameworks/svelte.html#using-svelte

Once clicked on reload button

@ghostdevv I'm working for integrating also svelte: Svelte Kit will not be supported since it has its own service worker module.
I also include some working examples on the examples package: using svelte and Routify.
There will be a basic and a router example similar to vue examples.

I'll take a look soon, thank you @userquin

@ghostdevv see this https://github.com/userquin/vite-plugin-pwa/tree/feat/add-svelte, you can view svelte-basic and svelte-routify in examples directory. Maybe tmr will be merged here, I need to talk with antfu...

That's amazing, thank you so much!

@ghostdevv virtual module for svelte and for react included on 0.10.0 versión. There are also 4 New examples 2 for svelte and 2 for react.
I Will also update the docs site...

@ghostdevv docs ready for svelte and react

Awesome ty


Wrong suggestion when adding compound to subfolder

For example, try adding a compound debug in extensions/html/.vscode/launch.json
It's suggesting configurations in root, not in html extension folder.

This is fine. We allow you to reference any configuration from a sibling folder. We do not treat the configurations in your launch.json any specially.
Let me know if the "Launch Extension" is not offered at all since that would be a bug


feat: new extractor

Closes #63
Closes #87

Thanks for your great work Stephan!
I tried the recent version of the cli with the new extractor, and it fails on "Dynamic options" for this line:
throw this.$t(
            'dialog.importUsers.badServerResponse',
            'Invalid response from Server.\nPlease retry later.',
          );

Works OK after removing the \n.
Is this expected?

Another issue, seems like the @tolgee-key comments ignore the specified --default-namespace parameter.

@OrenChapo thanks for reporting, should be fixed in this PR:
https://github.com/tolgee/tolgee-cli/pull/91


Can't import radio after installing via pip3

Python 3.6.3 |Anaconda custom (64-bit)| (default, Oct 13 2017, 12:02:49)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import radio
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'radio'

Any known issues regarding this?

Hello, trathpai!
We have checked that installation works in an empty virtual environment (in Linux) with command
pip3 install git+https://github.com/analysiscenter/radio.git, so we recommend trying to install radio again in accordance with the instruction.
Best regards,
Alexey


[6.0][Compile Time Constant Extraction] Extract macro added extensions

Cherry-pick of https://github.com/apple/swift/pull/72414

Explanation: visit extension macro generated extensions to collect nominal type declarations for compile time constant extraction
Scope: compile time constant extraction where there's an attached extension macro generating an extension containing a nominal type declaration that should be extracted
Main Branch PR: https://github.com/apple/swift/pull/72414
Resolves: rdar://124119745
Risk: Low, additive change to compile time constant extraction only
Reviewed By: @artemcm
Testing: added test-cases to the test suite

@swift-ci please smoke test

@swift-ci please test


Dropbox will not install when run

Issue description
Dropbox is added to my nixos configuration. When I run dropbox this is the output:
john@n1 ~> dropbox
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 70.5M  100 70.5M    0     0   161k      0  0:07:27  0:07:27 --:--:--  270k
tar: /etc/user/john: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

My home is in /etc/user/john. I'm wondering if this has anything to do with the error.
I sort of think it is failing somewhere on this line. https://github.com/NixOS/nixpkgs/blob/dbb774c5e1a9fde65aa6f1010e0e8a8df2b786c9/pkgs/applications/networking/dropbox/default.nix#L71
Update: Downloaded the file and ran the tar command. Even with ~/.dropbox-dist do_install still runs from the dropbox script.
Steps to reproduce
Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

system: "x86_64-linux"
host os: Linux 4.14.15, NixOS, 17.09.2873.4c3c0e824aa (Hummingbird)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 1.11.16
channels(root): "nixos-17.09.2873.4c3c0e824aa"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

It might be nice if pkgs/build-support/build-fhs-userenv/chroot-user.rb were changed to mount users.extraUsers.john.home to /home. Just not sure how to get that value into the script.


Watcher identifiers or objects?

In the name of keeping our discussions in nicely structured issues...
@trowski proposed using watcher identifiers in an initial event loop proposal here.
I think it would be a good use of the separation of concerns principle to instead create a Watcher object that contained ::enable(), ::disable() and ::cancel() methods.
All thoughts and opinions please!

I actually prefer watcher objects instead (Icicle follows a similar model). Watcher objects will need some method to communicate with the loop, but that's more of an implementation detail then something we'd have to be concerned about specifying/recommending.

I also prefer objects vs. numeric identifiers.

Awesome, @WyriHaximus mentioned briefly on IRC that he preferred objects too so I'll close this issue.
If anyone has anything extra to add just comment and/or reopen it :)

I prefer identifiers. Objects bring an unnecessary overhead for every watcher. This sum not only up for watcher creation but also in memory consumption when you have many watchers.

I'll do some benchmarks later to see how significant the overhead is. Will post scripts and results here when done.

We should also respect responsibilities:
It's the reactors job to manage watchers. Watchers can't (or at least shouldn't depending on the backend) manage themselves. At the very least watcher objects need to communicate back to the reactor, which pretty much defeats the goal.
Additionally, we are going to create a cyclic reference here, which isn't quite great for garbage collection. (Not detectable in simple benches, but possibly in longer running apps)
Thus, I'm all for having the watcher identifiers being anonymous integers or strings.

My main issue is that using scalar objects smells of bad OO design, it feels very procedural. Applying the single responsibility principle gives us two separate responsibilities - the event loop and the event.
In many ways we should probable rename Watcher to Event, so that we have:
interface Event
{
    public function enable();
    public function disable();
    public function cancel();
}

My personal opinion is that even it would need to be a very significant performance impact before I preferred scalar identifiers as I just don't like the design.
But let's run the numbers and see.

@AndrewCarterUK How do you want to realize the enabled state? If you want to keep watcher and loop separated, would every watcher keep his own enabled state? That'd mean that we had to invoke every write watcher in every single tick resulting in a lot of function calls and overhead.

@kelunik - https://3v4l.org/tkBjG
POC:
<?php

class Communicator
{
    private $enableCallback;
    private $disableCallback;

    public function __construct(callable $enableCallback, callable $disableCallback)
    {
        $this->enableCallback  = $enableCallback;
        $this->disableCallback = $disableCallback;
    }

    public function enable(Event $event)
    {
        call_user_func($this->enableCallback, $event);
    }

    public function disable(Event $event)
    {
        call_user_func($this->disableCallback, $event);
    }
}

class Event
{
    private $communicator;
    private $name;

    public function __construct(Communicator $communicator, $name)
    {
        $this->communicator = $communicator;
        $this->name = $name;
    }

    public function enable()
    {
        $this->communicator->enable($this);
    }

    public function disable()
    {
        $this->communicator->disable($this);
    }

    public function __toString()
    {
        return $this->name;
    }
}

class Loop
{
    private $communicator;

    public function __construct()
    {
        $this->communicator = new Communicator(
            function (Event $event) {
                $this->internalEnable($event);
            },
            function (Event $event) {
                $this->internalDisable($event);
            }
        );
    }

    public function createEvent($name)
    {
        return new Event($this->communicator, $name);
    }

    private function internalEnable(Event $event)
    {
        echo 'Enabling ' . $event . PHP_EOL;
    }

    private function internalDisable(Event $event)
    {
        echo 'Disabling ' . $event . PHP_EOL;
    }
}

$loop = new Loop();

$event = $loop->createEvent('foo');

$event->enable();
$event->disable();

That's the way I'd approach it personally. You can share the communication method between all of your events which cuts down on overhead by a fair bit. The overhead you incur is that an enable() or disable() call goes through a couple of layers before it hits the real logic - but I think compromising on good OO principles for this is over optimisation.

Ummmmmmmm.
That's surely how you'd approach this, if you want to force it that way.
But my point is that this still is a violation of responsibilities.
Your approach is IMO just forcing object-orientation on something for the sake of it. … And that's bad OO design.
I'm not discussing that on a performance basis, but on a fundamental layer it's just violating responsibilities. The Reactor operates on the handles, not the handles on themselves.

@AndrewCarterUK The problems I have with this approach:

It creates cyclic references (garbage collection)
It makes the implementation much more complex (Loop, Event and Communicator in between)
In the end the events have to be enabled or disabled in the Loop anyway, what's the real responsibility of Event then?

Also because something feels procedural, it isn't necessarily bad OO design.
That's a common fallacy…
You could also have dummy objects without methods and value instead and map it inside an SplObjectStorage … it's just most comfortable and performant to actually use a string instead of an dummy object. (which actually is mostly a detail)

@kelunik - There aren't any cyclic references problems in the code I posted because the communicator is shared between all of the events.
That said, I'm getting persuaded here. The more I think about it the more the watcher object solution tastes a bit like active record (where the entity is responsible for saving itself). I still can't shake my dislike for the identifiers but I'm interested to here @trowski @assertchris and @WyriHaximus on this one.

@AndrewCarterUK there is an implicit reference through the callback (which references a $this).
And yeah, that's our point; ActiveRecord is a good comparison.

@AndrewCarterUK There aren't currently, as long as you just print in Loop instead of actually enabling and disabling watchers. Btw. it's really Watcher not Event IMO, the event is when the watcher's callback gets invoked.

@bwoebi - One cyclic reference isn't a problem. The cyclic reference is between a set of 4 objects (the event loop, communicator and two closures) that are only created and used once throughout the life of the issue

@kelunik @bwoebi - I see what you are saying now. There is a reference loop between the objects (apologies - I'm writing all this very hungover).

@AndrewCarterUK It's all fine, @bwoebi didn't see the loop at first, too. :-)

I think I would prefer an object to an identifier. Having said that, identifiers have worked well, in JavaScript, for a long time.

@assertchris: What are your reasons?

An object can track its own state.

As we already discussed, it can't. It has to reference the event loop for that anyway, see https://github.com/async-interop/event-loop/issues/4#issuecomment-186658430
Additionally, we still have the cyclic reference issue.

I'm not talking about the state already discussed. If it's an integer, if can't track any state at all.

What state do you want to have?

What if an implementor wants to track when a watcher was created or how long it has been in the event loop or how many times it has been trigged (as a periodical). There are many, many kinds of state that could appropriately be tracked inside a watcher object.

An implementor can't really add these, because the watcher wouldn't be interoperable anymore.

All implementations don't have to be identical to be interoperable. As long as they follow the interface, they are interoperable. they may just choose to expose more data than required by the interface.

But you can use that information only if you know the concrete implementation. It's not any issue for promises for example:
$deferred = new XyDeferred;
$promise = $deferred->promise();

// We know that we have a XyPromise here, so we can safely call an additional method on it
$promise->xy();

But that's not possible for the watchers. They're depending on the actual implementation used, which is not decided by any library author, but rather by the project maintainers of an actual project using the libraries.
So a project would be fine using the watcher options, because it will know the implementation, while libraries will not know it. And TBH, I think I only ever used watchers in libraries with Amp, never in projects, the project always uses the high level API with promises.

So, I think where we are is:

I mentioned a preference for objects over identifiers.
You asked for the reasons for that preference.
I told you my reasons for my preference.

I'm not trying to convince you of anything, and as I stated: identifiers have worked for a long time in other contexts. I'm just telling you the reasons for my preference, as you requested. I don't really want to argue about this anymore though.

I just wanted to know / understand how the additional state can actually be used, but fine then.

I meant to post this a while ago, there is actually a way of doing this without creating cyclic references (just adding more methods):
interface Event
{
    public function isEnabled();
    public function enable();
    public function disable();

    public function isCancelled();
    public function cancel();

    public function isReferenced();
    public function reference();
    public function unreference();
}

interface EventLoop
{
    public function run();
    public function stop();

    public function onReadable($stream, callable $callback): Event;
    public function onWritable($stream, callable $callback): Event;
    public function onError($errno, callable $callback): Event;
    public function onSignal($signo, callable $callback): Event;

    public function defer(callable $callback): Event;
    public function delay(float $time, callable $callback): Event;
    public function repeat(float $interval, callable $callback): Event;
}

I'm leaning in favour of this, especially after the addition of the reference and unreference methods.

there is actually a way of doing this without creating cyclic references

Would you mind sharing how?

I've just shown ^
If you allow the event to be tested for state with the is*() methods you don't have to make the event reference the event loop.

Oh, but that won't work that good. Because streams are essentially always writable, you would have to invoke all write watchers all the time consuming a lot of useless CPU time, if the event loop doesn't know about the watchers state.

@kelunik - I'm not sure I'm understanding the problem?
It's just a case of the event object tracking whether a stream is enabled/disabled/cancelled/referenced rather than internal arrays inside the event loop implementation?

Ahh I think I see what you're saying (did you mean always enabled rather than writable?)
Essentially that if the event loop manages the event state then it can prepare the streams that it passes to the select() call on demand - rather than having to rebuild these every time?
That's a valid problem - that I've got no response too :)

How do we proceed here?

I evaluated the best arguments in this thread to point in the direction of using watcher identifiers (rather than objects).
As a result, that was what I used in the EventLoopDriver interface draft that was merged in a recent PR.
However, that was my analysis of the arguments in this thread - and there are parties in here that have argued for objects (rather than identifiers) who haven't responded to the point that you've made.
I'm happy leaving this as an open issue until @assertchris and @trowski are satisfied or we have more information from experience to inform a decision.

@assertchris @trowski You haven't responded to the made points yet. Can we close this issue?

I'll close this but I'm happy to reopen if new points are made.

@kelunik I did explain how the object reference could be used, but decided not to argue the point further. I still do not wish to argue the point further, so I'm happy as a clam for this issue to be closed.

@assertchris Yes, and I understand that. But we don't have a solution for the issues with it: Either always a circular reference or a performance issue, because every event has to be asked whether it's enabled.

All implementations don't have to be identical to be interoperable. As long as they follow the interface, they are interoperable. They may just choose to expose more data than required by the interface.

For that to work, the user has to create the watcher object, otherwise you're limited to the interface, because the user might use another event loop implementation with other watchers.
Feel free not to answer if you don't want to.

@kelunik I am happy with the watcher references being integers. It is really not that big a deal to me that I would want to still be arguing this.

@assertchris They're strings. ;-P

@kelunik Tell me why that matters. You've pulled me back into a thread I opted out of 2 months ago, just so I can say I'm still ok with scalar variables instead of objects. I don't much fancy the levity...


Allow users to view their own SSH keys

This allows users to view their own SSH keys using the whoami command
closes #123

@smlx just want your eyes over this as it changes the SSHKey struct, which means more information is exported and imported for users.
I don't think it will be a problem though.


Initial Release Pipeline

Creating an initial image release pipeline for the shipwright operator.
This makes use of the travis docker service to build the image and push
it to quay.io when release tags are made and PRs merge in the main
branch.
In the future we will want to dogfood our own operator and use
Shipwright to build and push the image.

/assign @qu1queee

Checking this tomorrow , thanks @adambkaplan

/lgtm

/approve


Maximum call stack exceeded

RangeError: Maximum call stack size exceeded
at deepClone (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:32:19)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:45:20)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
at deepMerge (D:\Videos\JC3MP\JC3MP-TM\packages\justcord-3\util.js:62:12)
Package 'justcord' loaded.

Whenever I start the server and that happens, package.json gets updated and it loses some information.. this is a github changelog below;
@@ -1,29 +1,29 @@
{
  "name": "justcord",
  "version": "0.1.0",
  "description": "A JC3MP-Discord bridge",
  "main": "main.js",
  "repository": {
    "url": "https://github.com/md678685/justcord-3.git",
    "type": "git"
  },
  "author": "md678685<EMAIL_ADDRESS>  "license": "MIT",
  "dependencies": {
    "eris": "^0.5.1"
  },
  "devDependencies": {
    "eslint": "3.13.0",
    "eslint-config-airbnb": "^14.0.0",
    "eslint-plugin-import": "2.2.0",
    "eslint-plugin-jsx-a11y": "3.0.2",
    "eslint-plugin-react": "6.9.0"
  },
  "jcmp_dependencies": [
    "chat"
  ],
  "scripts": {
    "test": "echo 'Not yet implemented, use script \"run_server\" to start emulator' && exit 1",
    "run_server": "cp ./*.js jcmpserver/packages/justcord && cd jcmpserver && jcmp-server && rm packages/justcord/*.js"
  }
}
    "author": "md678685<EMAIL_ADDRESS>    "dependencies": {
        "eris": "^0.5.1"
    },
    "description": "A JC3MP-Discord bridge",
    "devDependencies": {
        "eslint": "3.13.0",
        "eslint-config-airbnb": "^14.0.0",
        "eslint-plugin-import": "2.2.0",
        "eslint-plugin-jsx-a11y": "3.0.2",
        "eslint-plugin-react": "6.9.0"
    },
    "jcmp_dependencies": [
        "chat"
    ],
    "license": "MIT",
    "main": "main.js",
    "name": "justcord",
    "repository": {
        "type": "git",
        "url": "https://github.com/md678685/justcord-3.git"
    },
    "scripts": {
        "run_server": "cp ./*.js jcmpserver/packages/justcord && cd jcmpserver && jcmp-server && rm packages/justcord/*.js",
        "test": "echo 'Not yet implemented, use script \"run_server\" to start emulator' && exit 1"
    },
    "version": "0.1.0"
}
\ No newline at end of file

weird?

I'm not sure why the package.json gets changed, but that seems to happen regardless of the error. I'll revert the config changes for now.

Justcord 0.2.0 now uses _.merge from lodash, rather than the borked util function.


DryKup, a fork of CoffeeCup

I would like feedback on a fork I am starting.  It is not a replacement of coffeeKup but just a version that executes the code natively instead of being compiled.  This has some obvious advantages and disadvantages.
https://github.com/mark-hahn/drykup
I wanted to make this a pull request but it will share very little code.   Again, feedback would be appreciated as I am just now starting work on this.

#121


Enhancement/29/automated testing

To be merged after #26
Adds linter & CircleCI basic stuff.

the single-quote string is more of a js "standard". Whichever we actually choose, we should stick to it anyways.

Comment alignement fixed, along with explanation for the specific rules :)
Merging to setup the base of the CI \o/


[Bug][gitlab] GitLab 11.1.4 APIs did not return merge_date and led the calculation of PR cycle time fail

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
My GitLab version is 11.1.4. Some pull_requests have been merged, but the GitLab APIs did not return merge_date, resulting in the merge_date field of the pull_request table being empty, and then there is a problem with the calculation logic behind it, the APIs returns the following payload:
[{"id":5,"iid":5,"project_id":1,"title":"feature620-1","description":"","state":"merged","created_at":"2023-06-19T16:50:55.534+08:00","updated_at":"2023-06-19T16:51:13.120+08:00","target_branch":"master","source_branch":"feature620","upvotes":0,"downvotes":0,"author":{"id":1,"name":"Administrator","username":"root","state":"active","avatar_url":"https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon","web_url":"http://<IP_ADDRESS>:8081/root"},"assignee":{"id":1,"name":"Administrator","username":"root","state":"active","avatar_url":"https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon","web_url":"http://<IP_ADDRESS>:8081/root"},"source_project_id":1,"target_project_id":1,"labels":[],"work_in_progress":false,"milestone":null,"merge_when_pipeline_succeeds":false,"merge_status":"can_be_merged","sha":"f44aebb41056fc9d5053599d0d6f270900b68dda","merge_commit_sha":"c68d591a86fcf8ccdf01b319fdb242708cb7340e","user_notes_count":0,"discussion_locked":null,"should_remove_source_branch":null,"force_remove_source_branch":false,"web_url":"http://<IP_ADDRESS>:8081/root/sample/merge_requests/5","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"squash":false},{"id":4,"iid":4,"project_id":1,"title":"Feature618","description":"","state":"merged","created_at":"2023-06-18T14:15:00.749+08:00","updated_at":"2023-06-18T14:16:27.829+08:00","target_branch":"master","source_branch":"feature618","upvotes":0,"downvotes":0,"author":{"id":1,"name":"Administrator","username":"root","state":"active","avatar_url":"https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon","web_url":"http://<IP_ADDRESS>:8081/root"},"assignee":{"id":1,"name":"Administrator","username":"root","state":"active","avatar_url":"https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon","web_url":"http://<IP_ADDRESS>:8081/root"},"source_project_id":1,"target_project_id":1,"labels":[],"work_in_progress":false,"milestone":null,"merge_when_pipeline_succeeds":false,"merge_status":"can_be_merged","sha":"f425c59ed7f6825fa5b816333501c82008d8acd1","merge_commit_sha":"9ddfbb5e809d95ec44a70d4ab310e1d4c4f3fe2e","user_notes_count":1,"discussion_locked":null,"should_remove_source_branch":null,"force_remove_source_branch":true,"web_url":"http://<IP_ADDRESS>:8081/root/sample/merge_requests/4","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"squash":false},{"id":3,"iid":3,"project_id":1,"title":"设置80端口","description":"设置80端口--完成","state":"merged","created_at":"2023-06-18T11:27:06.924+08:00","updated_at":"2023-06-18T11:27:11.581+08:00","target_branch":"master","source_branch":"feature-617","upvotes":0,"downvotes":0,"author":{"id":1,"name":"Administrator","username":"root","state":"active","avatar_url":"https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon","web_url":"http://<IP_ADDRESS>:8081/root"},"assignee":null,"source_project_id":1,"target_project_id":1,"labels":[],"work_in_progress":false,"milestone":null,"merge_when_pipeline_succeeds":false,"merge_status":"can_be_merged","sha":"58b4bbc198ffb1ab1eba42f4ebfdbbb3f75ad777","merge_commit_sha":"85c8e01001535672720d80751a6abd07bab4bc21","user_notes_count":0,"discussion_locked":null,"should_remove_source_branch":null,"force_remove_source_branch":false,"web_url":"http://<IP_ADDRESS>:8081/root/sample/merge_requests/3","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"squash":false},{"id":2,"iid":2,"project_id":1,"title":"feature617-2 commit","description":"添加springboot基础配置","state":"merged","created_at":"2023-06-18T10:48:31.249+08:00","updated_at":"2023-06-18T10:48:36.565+08:00","target_branch":"master","source_branch":"feature-617","upvotes":0,"downvotes":0,"author":{"id":1,"name":"Administrator","username":"root","state":"active","avatar_url":"https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon","web_url":"http://<IP_ADDRESS>:8081/root"},"assignee":null,"source_project_id":1,"target_project_id":1,"labels":[],"work_in_progress":false,"milestone":null,"merge_when_pipeline_succeeds":false,"merge_status":"can_be_merged","sha":"8be390c067b3605d86d934b90ce2c9dd7704e069","merge_commit_sha":"4eeda69fb6338f787489f315a44f9ff819898aca","user_notes_count":0,"discussion_locked":null,"should_remove_source_branch":null,"force_remove_source_branch":false,"web_url":"http://<IP_ADDRESS>:8081/root/sample/merge_requests/2","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"squash":false},{"id":1,"iid":1,"project_id":1,"title":"feature617-1 commit","description":"","state":"merged","created_at":"2023-06-17T22:51:21.079+08:00","updated_at":"2023-06-17T22:51:26.507+08:00","target_branch":"master","source_branch":"feature-617","upvotes":0,"downvotes":0,"author":{"id":1,"name":"Administrator","username":"root","state":"active","avatar_url":"https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon","web_url":"http://<IP_ADDRESS>:8081/root"},"assignee":null,"source_project_id":1,"target_project_id":1,"labels":[],"work_in_progress":false,"milestone":null,"merge_when_pipeline_succeeds":false,"merge_status":"can_be_merged","sha":"e72fa99c78d87cfca6f6b40ecb16fafa65648373","merge_commit_sha":"47c685aefff3fa26d2cf37966c02d3dd34d20ddd","user_notes_count":0,"discussion_locked":null,"should_remove_source_branch":null,"force_remove_source_branch":false,"web_url":"http://<IP_ADDRESS>:8081/root/sample/merge_requests/1","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"squash":false}]
What do you expect to happen
In case this version of gitlab does not return merge_date, consider other solutions to the merge_date problem.
How to reproduce
Use DevLake to collect GitLab v11.1.4 data
Anything else
No response
Version
v0.17
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

https://github.com/apache/incubator-devlake/blob/5ae16b97b7ac80212dc651396f9d9db5f97a7613/backend/plugins/gitlab/impl/impl.go#L115-L135
I think ExtractApiMergeRequestDetailsMeta should move before ConvertApiMergeRequestsMeta.

@xuqiyu

The issue has been translated into English to follow the community guidelines. Please use English next time you created an issue for better communication.
Is it a typo you typed GitLab 1.11.4 initially? I've changed it to v11.1.4, which looks more like the right version.
I noticed that you checked this. Do you want to fix the issue?

Look like this is the same problem to #5486


Add Version Check for third-party providers

Create pkgversion command to verify an upstream version change. The command requires an owner and a repo input and will query both the package version as listed on their latest release, as well as check the metadata file in pulumi/registry.
The command will print an updated release version if there's a version difference between the latest release and the registry version. It will print nothing if they're the same.
This is a very basic, no-frills functionality and I'm almost certain we'll need to expand on it.
I'm also happy to hear thoughts about naming this command differently.
Part of https://github.com/pulumi/registry/issues/853

Is there any reason why if there's a newer version that we wouldn't use the info and just regenerate the yaml file rather than needing to parse the output and then run a second command?

Is there any reason why if there's a newer version that we wouldn't use the info and just regenerate the yaml file rather than needing to parse the output and then run a second command?

Oh I guess no particular reason, other than I had already written it the other way, that works!  It does make it less straightforward to do more logic in the action though, such as limit updates to a provider to a certain amount per month or something.  I like functions to have less complexity where possible, and the other command is already written.

I'm with Paul here - regenerating the metadata file makes sense to me, we can write it to the environment and run the update.
Are we concerned with bad actors hammering our action usage?

this is going to happen on a cron - we should not have to parse output as input to another action IMO

Since the metadata command is doing more that just rewriting the metadata file (which I thought was its only purpose yesterday), I changed this back to just emit the version string. That way we can generate the metadata with the tried and proven command.