union with count limit

Hi,
Thank you for the great tool.
Here is my problem:
when dealing with large amount set of data, such as
{"tag": "1", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "2", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "3", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "4", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
...
{"tag": "100000", "ip": "<IP_ADDRESS>", "category": "some_cat2"}

When use union function to union ip by category or tag, the zq command is: union(ip) by category.
The result would be a large list of ip, such as
{"union": ["<IP_ADDRESS>", "<IP_ADDRESS>", "<IP_ADDRESS>", ... "<IP_ADDRESS>"], "category": "some_cat1"}

What I want was to set a limit in union, to limit the length of "union", and split this union with at most the number of limit. For example above, if I set the limit to be 2, union(ip) by category limit 2, the result would be:
{"union": ["<IP_ADDRESS>", "<IP_ADDRESS>"], "category": "some_cat1"}
{"union": ["<IP_ADDRESS>", "<IP_ADDRESS>"], "category": "some_cat1"}
...
{"union": ["<IP_ADDRESS>", "<IP_ADDRESS>"], "category": "some_cat1"}
{"union": ["<IP_ADDRESS>", "<IP_ADDRESS>"], "category": "some_cat1"}

Hi @allukaZod! Thanks for your interest in Zed.
In your final table output below, I think you probably meant to have some entries with some_cat2? In any case, I think I understand the question, and if so, it's an interesting one. I'm looking into if Zed has the building blocks to do this with what's already there. I'll circle back after I've done more research.

Hello again @allukaZod. I've got something close to what you were seeking. The approach using the currently-available building blocks in Zed creates the full sets via union() and then emits them in batches of the requested size after the fact. The approach is admittedly a little hacky and we might design a more direct way to achieve this in the future. For now I've wrapped the functionality in a User-Defined Operator so that way you don't have to reckon with it in the main part of your Zed pipeline. That said, it also provides an opportunity to understand some of the more advanced parts of the language like the spread operator and lateral subqueries.
Here's the user-defined operator in a file called batches.zed:
op emit_batches(complex_val, batch_size, group):
(
  over [...complex_val] with group =>
  (
    {id:(count()-1)/batch_size,val:this}
    | collect(val) by id
    | yield {group:group, batch:collect}
  )
)

And some sample data in a file data.json similar to what you showed:
{"tag": "1", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "2", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "3", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "4", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "5", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "6", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "7", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "8", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "9", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "10", "ip": "<IP_ADDRESS>", "category": "some_cat1"}
{"tag": "11", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "12", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "13", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "14", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "15", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "16", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "17", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "18", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "19", "ip": "<IP_ADDRESS>", "category": "some_cat2"}
{"tag": "20", "ip": "<IP_ADDRESS>", "category": "some_cat2"}

And an example that ties it all together:
$ zq -I batches.zed 'union(ip) by category | emit_batches(union, 2, category)' data.json
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}

However, I did bump into a new bug #4943 while working on this. The effects are evident if we use batch the same input data into groups of three.
$ zq -I batches.zed 'union(ip) by category | emit_batches(union, 3, category)' data.json
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>"]}

i.e., for some_cat2 we should have had three groups of 3 and one group of 1 like we had for some_cat1.
Anyway, I figured I'd share what I've got thus far in case you can make use of it despite that bug. I'll update again when we have that fix for #4943. Let me know if you have any other questions in the meantime.

Thanks a lot for the suggestion, that's exactly what Im looking for!
Ane yes, some_cat2 shour be the other group.

@allukaZod: Not sure if you're still watching this issue, but FYI, the issue #4943 I mentioned above has been fixed, so that last example shown previously now generates the correct expected output.
$ zq -I batches.zed 'union(ip) by category | emit_batches(union, 3, category)' data.json
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat1",batch:["<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"]}
{group:"some_cat2",batch:["<IP_ADDRESS>"]}

This fix is currently in Zed's tip of main and will be included in the next GA release, which I estimate will come out next week.


Title: HelperBird chrome extension enhancement [Code]

Which pre-existing extension will you be working on?
A Full set of tools for Chrome Extension to be implemented. This includes a lot of features such as Dyslexia Mode, Full Immersive Reader, Text to Speech, Voice Typing, Word Prediction, Screenshot, Color Blindness, Reading List, Bookmarks
Describe your enhancement/improvement
Need proper syntaxin and irrelevant file removal
the file base should be systematic
Comments wherever required
Add any other context or screenshots about the enhancement here.
No response

Would like to work on the same under JWOC @whiteHatpro


Test1

Add folder name test

Hello Hany
Now You have your application folder
Just add the files at any time


GLSL constant-buffer reflection alignment issue

Slang reports the wrong offset for scale in the following CB:
layout(set = 0, binding = 0) uniform PerFrameCB
{
vec2 offset;  // This is reported as 0, which is correct
vec2 scale;   // This one is reported as 16, but it should be 8 since it can be packed together with offset into a single vec4
};

Browsing the code on my phone, I think I see the root cause. In type-layout.cpp Std140LayoutRulesImpl::GetVectorLayout, the alignment is computed as:
RoundUpToPowerOfTwo(elementInfo.size * elementInfo.alignment)

But it seems like it should be:
RoundUpToPowerOfTwo(elementInfo.size * elementCount)
I'll put together a fix soon, but you could try to patch this yourself if you want to test the fix ASAP.

I am working on a PR that should fix this issue, but in looking at the code I can see that my implementation of std430 is also wrong, and I'll need to construct some test cases for that too.


Add checks for malformed NSURL

If there are cases where the provided NSURL is malformed, we can do a simple check to make sure if that's true:
if (url && url.scheme && url.host) {
    // crack on
}

@alexanderdean should this feature be set up as a sort of precondition to the emitter being created successfully?  As in if the URL is non valid then we simply throw an exception or is this to just not attempt sending unless the URL is valid?

Hey @jbeemster - yes I think we should throw an exception on invalid URI - i.e. fail fast...


build eosio-cleos-only package

for the case where we want to just have cleos on a machine without nodeos running. (eg for ops machine).

oops wrong repo.


SqlAgentOperator setting up schedule with DSC

Details of the scenario you tried and the problem that is occurring
i have successfully created and operator with dsc but how do you add a schedule for the operator?
Verbose logs showing the problem
N/A
Suggested solution to the issue
The DSC configuration that is used to reproduce the issue (as detailed as possible)
# insert configuration here

SQL Server edition and version the target node is running
SQL 2016
SQL Server PowerShell modules present on the target node

The operating system the target node is running
Windows 2016
Version and build of PowerShell the target node is running
5.1
Version of the DSC module that was used ('dev' if using current dev branch)
12

Do you mean that you want to schedule an agent job? 🤔

When you create a new operator you can add there on duty schedule

Ah, I see. That is not yet supported. How would you suggest this functionality is added? Should it be one or more properties added to the resource SqlAgentOperator, or does it need to be a new resource?

well i am fairly new to all this but the same module would work

It's alright, let's label this as an enhancement and help wanted so that someone else in the community can help figuring out the best way to add this functionality. 🙂


export-model generating incorrect NN

A recent run of export-model from main pointed at a trained network seems to produce a functionally random NN. Here's a comparison of inference on a background event performed using various combinations of a preprocessor and and NN hosted either locally with Torch or with Triton:

The lower sets of output timeseries are what I would expect (and since they're performed with Torch locally, I take them as ground truth), but the upper timeseries show that no matter how the data is preprocessed, the Triton-hosted NN produces nonsense outputs.
By contrast, here is an output timeseries produced by the same model hosted on Triton, but with export done from this branch

Clearly, something funky is happening during NN export in main. I suspect this may be somehow related to changes made in #376 , but I will do a finer-grained commit search later today to confirm.

Looks like there's a difference here. main has kernel_length = 1.5, whereas your branch has kernel_size = 2. Not sure which the network was trained with though.

Ok a more exhaustive search reveals that things broke between 8fd65 and 7f55b5. A quick look at their comparison shows that the only relevant changes between these are in the architecture lib. We changed the class name in the get_norm_layer wrapper to NormLayer but still returned GroupNorm. My model was trained without this bug, and so norm_groups was getting passed to the layer as expected. But once I tried to do inference from main, this bug came into play and norm_groups was functionally be set to None (since the wrapped NormLayer layer wasn't getting used).
This ended up being a pretty simple fix and is implemented in #391


Allow Module manage existing API Gateway

Is your request related to a new offering from AWS?
No.
Is your request related to a problem? Please describe.
I Would like have the possibility to manage the Routes/Integrations separately from API Gateway Creation.
Example, I have 3 ECS different services, managed in different terraform tfstates. All these 3 ECS services will integrate with the Same API Gateway. So i would like create API Gateway, and in ECS Services reference the API Gateway ID and create the integration. If i want delete one ECS service, the only thing I need to do is terraform destroy in ECS service stack and the API Route/Integration will be removed, but the API Gateway and the other 2 Route/Integrations continues existing.
Without this, if i want remove an ECS service, i need to do terraform destroy in ECS Service stack and remove the Route/Integration from API Gateway Terraform code run an update in the API Gateway stack.
Describe the solution you'd like.

Have a new variable api_gw_id. If the create_api_gateway is equal to false, and create_routes_and_integrations is equal true, the module will use  api_gw_id variable to create the route integrations.
Describe alternatives you've considered.
N/A
Additional context
N/A
If this makes sense for you, i can submit a pull request with this feature.

Looking for this as well

Solved it right now with
resource "aws_apigatewayv2_integration" "this" {
  for_each = var.create_routes_and_integrations ? var.integrations : {}

  api_id      = !var.create && var.create_routes_and_integrations ? var.apigateway_id : aws_apigatewayv2_api.this[0].id

and similar changes on other places

It sounds like a good idea, but maintaining this feature as part of the resource module is a very large amount of work that we don't want to do. Almost all terraform-aws-modules create at least the core resources (API GW, in the case of this module) and attach other resources to it (optionally).
Terraform does not allow us to write really flexible code that will support use-cases like this that we can easily maintain.

Isn't it just the above change to support it? for the integrations, routes and authorizers + the variable itself

Yes, it is a start, but then someone would like to reuse the externally created resources, like domain name (aws_apigatewayv2_domain_name) or other resources. The code will have to grow rather quickly.

Ok, I'll just update my local copy each time ;)


feat: #162: isomorphic git bridge

what
Initial implementation of a bridge backed by the isomorphic-git library. Reads / writes directly against the bare repo (.git) instead of the working directory.
Notes

While you can run this directly from the monorepo, any commits made using the bridge will be written to the repository so I recommend using a snapshot version<EMAIL_ADDRESS>with a standalone starter for testing
Because this writes to the bare repo and not the working directory, the "state" of the repo can become confusing after some edits. You can sync your working directory back up in a variety of ways (git stash, git reset --hard <sha> for example), but we probably will need to discuss this 'feature' a bit more as it will probably be even more confusing for users. UPDATE: As a proposed solution to this, I have implemented a mechanism for syncing all your changes to the local filesystem as well. This writes updates to git and to the working directory.
isomorphic currently requires both the author and committer props when making a commit. I am currently setting those both to the same thing.

@kldavis4 While in the mono repo using yarn  dev-isomorphic in the tina-cloud-starter I am getting the following error (After a very slow startup)
Error:
      Unable to find any GraphQL type definitions for the following pointers:

          - /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/__generated__/*.{graphql,gql}

    at prepareResult (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/.yarn/$$virtual/@graphql-tools-load-virtual-030b59469e/0/cache/@graphql-tools-load-npm-7.3.2-ff490ca187-3987ed9bfc.zip/node_modules/@graphql-tools/load/index.js:536:15)
    at loadTypedefs (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/.yarn/$$virtual/@graphql-tools-load-virtual-030b59469e/0/cache/@graphql-tools-load-npm-7.3.2-ff490ca187-3987ed9bfc.zip/node_modules/@graphql-tools/load/index.js:502:12)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async generateTypes (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:562:20)
    at async genTypes (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:606:27)
    at async build2 (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:1978:7)
    at async FSWatcher.<anonymous> (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:2002:11)
AggregateErrorClass: GraphQL Document Validation failed with 5 errors;
  Error 0: GraphQLDocumentError: Unknown fragment "GlobalParts".
    at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/frags.gql:3:8

Error 1: GraphQLDocumentError: Unknown fragment "GlobalParts".
    at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:3:8

Error 2: GraphQLDocumentError: Unknown fragment "AuthorsParts".
    at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:10:16

Error 3: GraphQLDocumentError: Unknown fragment "PagesParts".
    at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:24:8

Error 4: GraphQLDocumentError: Unknown fragment "PostsParts".
    at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:31:10
    at new exports.AggregateError (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/.yarn/$$virtual/@graphql-tools-utils-virtual-21e85bd9d7/0/cache/@graphql-tools-utils-npm-8.2.3-cc714e0951-764d297836.zip/node_modules/@graphql-tools/utils/index.js:1178:16)
    at Object.checkValidationErrors (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/.yarn/$$virtual/@graphql-tools-utils-virtual-21e85bd9d7/0/cache/@graphql-tools-utils-npm-8.2.3-cc714e0951-764d297836.zip/node_modules/@graphql-tools/utils/index.js:1240:15)
    at codegen (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/.yarn/$$virtual/@graphql-codegen-core-virtual-8f39c34102/0/cache/@graphql-codegen-core-npm-2.1.0-f9f684bbd7-86c22a44c4.zip/node_modules/@graphql-codegen/core/index.js:102:15)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async generateTypes (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:569:17)
    at async genTypes (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:606:27)
    at async build2 (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:1978:7)
    at async FSWatcher.<anonymous> (/Users/logananderson-forestry-mac/dev/tinacms/tinacms/packages/@tinacms/cli/dist/index.js:2002:11) {
  errors: [
    Error [GraphQLDocumentError]: Unknown fragment "GlobalParts".
        at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/frags.gql:3:8,
    Error [GraphQLDocumentError]: Unknown fragment "GlobalParts".
        at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:3:8,
    Error [GraphQLDocumentError]: Unknown fragment "AuthorsParts".
        at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:10:16,
    Error [GraphQLDocumentError]: Unknown fragment "PagesParts".
        at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:24:8,
    Error [GraphQLDocumentError]: Unknown fragment "PostsParts".
        at /Users/logananderson-forestry-mac/dev/tinacms/tinacms/experimental-examples/tina-cloud-starter/.tina/queries/queries.gql:31:10
  ]
}

@logan-anderson I'll look into the monorepo issue. There is a snapshot version mentioned in the description that you can use to test outside the monorepo

@logan-anderson the issues that you encountered here have been addressed

@jeffsee55 I spent the morning fixing a couple of bugs related to the index not getting updated, which is why you were seeing some of those issues. (It was only happening in the monorepo for some reason, so I missed it in my testing.)
The overall strategy I am using at the moment is this:

The bridge operates on the "bare repository" and "the index"
The onPut / onDelete are used when running locally to keep the working directory in sync with the bare repository. (Without this, the working directory will show changes relative to the whatever changes the bare repository has)

Can you explain at a high level what's going in the put function? I think I understand it to some extend but was confused by the output I saw (commented with the screenshots).

Here's a high-level overview of the put:

Check if the contents are actually being updated (using hashBlob to compute the oid of the update)
Write a new blob object
Build a new tree structure with the updated blob
Write the new tree as a commit
Update the ref to point to the new commit
Update the index with the new OID
If we are local, call onPut which will update the working directory as well

In general I guess we'll need to nail down what it means to put in this context. Is that a "change not staged for commit", a "staged change", or a commit? How do you see that working?

Currently a put is equal to a commit to the bare repo, in keeping with how the github bridge works. I think until we have some concept of staging changes, it makes sense to keep with this approach.

And one thing we don't have with the datalayer is automatic updates when someone manually edits the markdown file. It seems like with access to Git directly here we could just 'watch' the Git index and if a file has been altered we update it in the DB. Do you think something like that might work instead of watching all the user's markdown files?

I like the idea of automatically updating the datalayer (though I think it is out of scope for this pr). I think we'd still need to watch the content folder, though. The index isn't updated until the user does a git add/rm, and I imagine the user would expect the content changes to reflect the working directory state and not the index.

@kldavis4 this was using the snapshot:
    "@tinacms/cli": "0.0.0-2022510204053",

@kldavis4 is there an option to disable "commit on save" I could see for a lot of folks they may not want a ton of extra commits on a PR for test content updates.

There is not - the current option to avoid this is to use the filesystem bridge. (And this replicates the current behavior when using tina cloud). When we have api (and UI) support for staging commits, this should not be an issue

Thanks @kldavis4 - the latest version fixes the issue I was seeing, now it makes sense.

Currently a put is equal to a commit to the bare repo, in keeping with how the github bridge works. I think until we have some concept of staging changes, it makes sense to keep with this approach.

The general concept of locally every save is a commit makes sense. I think you're right that we can't do much with this until we have a feel for some of the editorial workflow stuff.

The onPut / onDelete are used when running locally to keep the working directory in sync with the bare repository

Does that mean that even when passing the node fs module as the filesystem to isomorphic-git it still doesn't write content to the working directory. It just operates within the .git folder only. Do I have that right? It would make sense, I just hadn't thought it all the way through.


sketch out documentation

resolves #128
This PR creates a mkdoc website to host pgstac and pypgstac documentation

you can preview the web site by doing
pip install mkdocs mkdocs-material
mkdocs serve -f docs/mkdocs.yml


sonar: remove sonar-scan from allow_failures

Signed-off-by: Nicolas Oliver<EMAIL_ADDRESS>

@alext-mkrs I removed sonar-scan from allow_failures list.
Remove Allowed Failure
Done, Travis will now fail if the sonar-scan target end with an error exit code
intel-iot-devkit/master branch must always run sonar scan, and fail the build is it not pass. If sonar found to many bugs, this will not fail the build. That failure will be reported in the sonar dashboard
This is already happening, because intel-iot-devkit/upm project in Travis is configured correctly.
"Internal" PRs must always run sonar scan, and fail the build is it not pass. If sonar found to many bugs, the PR will be marked as failure.
This PR is an example of an internal PR, and it is running sonar (not skipping it),You can see the execution here https://travis-ci.org/intel-iot-devkit/mraa/jobs/264857592
For external PRs, The sonar-scan.sh already skip the scan. We cannot run sonar scan for this because the required env vars are not shared with external PRs. We could create a temporary internal PR to make sonar run the scan and get a preview of the results (this will be manual)
Now, sonar-scan.sh will check the env vars, and skip the execution for external PRs, and end with code 0. So we will see sonar-scan in green, but it will not run the scan. an example of this is https://travis-ci.org/intel-iot-devkit/mraa/jobs/264857592
For forks, check if required variables are set, and skip the scan with a message explaining that if there do not exists. Otherwise, follow the same policy for intel-iot-devkit/master branch and internal PRs
I made a PR in my fork, and it is applying the same policy as in intel-iot-devkit/mraa. For forks that do not have the required env vars configured, it will just skip the scan and end with code 0. The example PR is here https://github.com/dnoliver/mraa/pull/2

A little too late, but I had no time to look sooner - looks good to me.


Propagate CreationTimestamp to Endpoints

Description of changes:

Added CreationTimestamp attribute to endpoints + propagation to Cloud Map
Note that CreationTimestamp is in UNIX format. Seconds since 1970.
In integration tests - removed CreationTimestamp when comparing if endpoints are equal.

Testing:

Manual testing
Kind integrations tests complete successfully

Codecov Report

Merging #200 (4a53176) into main (b5cdcb1) will decrease coverage by 0.20%.
The diff coverage is 70.37%.

@@            Coverage Diff             @@
##             main     #200      +/-   ##
==========================================
- Coverage   72.97%   72.77%   -0.21%
==========================================
  Files          15       15
  Lines        1654     1671      +17
==========================================
+ Hits         1207     1216       +9
- Misses        359      365       +6
- Partials       88       90       +2

Impacted Files
Coverage Δ

pkg/model/types.go
65.75% <42.85%> (-2.43%)
:arrow_down:

...ntrollers/multicluster/serviceexport_controller.go
40.67% <100.00%> (+0.67%)
:arrow_up:

Continue to review full report at Codecov.

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