Move the litmus-service to keptn-contrib

The litmus-service has seen useful changes since the initial release (as can be gauged from these closed issues).
It has generated some positive community response (as seen from joint blogs and webinars) and seen initial adoption.
On behalf of the team working on this integration, would like to propose that litmus-service be moved to the next-stage of usage/recognition, i.e., be included into keptn-contrib.
We would be happy to understand any other requirements that need to be met for this and try to facilitate the same.

FYI: https://github.com/keptn-sandbox/contributing#how-to-be-promoted-to-keptn-contrib-organization
In my opinion unit tests would be great before promoting to keptn-contrib.
Other then that, I'm happy to be the sponsor from the keptn core team. I like litmus-service and the way it works.


Receiving error during load

Operation System: OSX
Beaker Version:Latest Master
Installing from source
ran npm install and npm run rebuild
then npm start and received the following
App threw an error during load
TypeError: electron.protocol.registerSecureSchemes is not a function

Yeah, this has to do with having the right Electron binary. We need to figure out why your master branch isn't getting the right binary.

See my comment here: https://github.com/beakerbrowser/beaker/issues/94#issuecomment-255450140
You'll need to delete your electron-binary cache to run beaker from master.


The check for missing values in 3-argument SHADE too broad

Reported by Steven C Hankin on 27 Jan 2007 00:48 UTC
It appears that when checking for missing values in the coordinates passed to
the 3-argument SHADE command, Ferret is checking the entire coordinate variable
fields cached in memory, rather than the specific subset that has been requested
for plotting.  This bug could be explained if the check is done in C using.
use
"http://data.nodc.noaa.gov/cgi-bin/nph-dods/ghrsst/L2P/AMSRE/REMSS/2005/027/20050127-AMSRE-REMSS-L2P-amsr_l2b_v05_r14551.dat-v01.nc.gz"
stat/i=150:4000 lat
shade/i=150:4000 sea_surface_temperature[lat
canc mem/all
stat lat, lon   ! load the full coordinate fields stored
shade/i=150:4000 sea_surface_temperaturel=1,lon, lat
*** output of this ***
yes? use
"http://data.nodc.noaa.gov/cgi-bin/nph-dods/ghrsst/L2P/AMSRE/REMSS/2005/027/20050127-AMSRE-REMSS-L2P-amsr_l2b_v05_r14551.dat-v01.nc.gz"
yes? stat/i=150:4000 lat
         latitude
         X: 149.5 to 4000.5
         Y: 0.5 to 243.5
         Z:  N/A
         T:  N/A
         DATA SET:

p://data.nodc.noaa.gov/cgi-bin/nph-dods/ghrsst/L2P/AMSRE/REMSS/2005/027/20050127-AMSRE-REMSS-L2P-amsr_l2b_v05_r14551.dat-v01.nc.
gz
Total # of data points: 935793 (38512431*1)
flagged as bad  data: 0
Minimum value: -87.24
Maximum value: 89.15
Mean    value: 2.0872 (unweighted average)
Standard deviation: 49.096
yes? shade/i=150:4000 sea_surface_temperature[lat
-----  a plot is produced ----
yes? canc mem/all
PERMANENT data cleared from memory
TEMPORARY data cleared from memory
yes? stat lat, lon   ! load the full coordinate fields stored
         latitude
         X: 0.5 to 4194.5
         Y: 0.5 to 243.5
         Z:  N/A
         T:  N/A
         DATA SET:

p://data.nodc.noaa.gov/cgi-bin/nph-dods/ghrsst/L2P/AMSRE/REMSS/2005/027/20050127-AMSRE-REMSS-L2P-amsr_l2b_v05_r14551.dat-v01.nc.
gz
Total # of data points: 1019142 (41942431*1)
flagged as bad  data: 57834
Minimum value: -89.43
Maximum value: 89.15
Mean    value: -0.10119 (unweighted average)
Standard deviation: 50.226
         longitude
         X: 0.5 to 4194.5
         Y: 0.5 to 243.5
         Z:  N/A
         T:  N/A
         DATA SET:

p://data.nodc.noaa.gov/cgi-bin/nph-dods/ghrsst/L2P/AMSRE/REMSS/2005/027/20050127-AMSRE-REMSS-L2P-amsr_l2b_v05_r14551.dat-v01.nc.
gz
Total # of data points: 1019142 (41942431*1)
flagged as bad  data: 57834
Minimum value: -179.99
Maximum value: 180
Mean    value: -30.671 (unweighted average)
Standard deviation: 100.58
yes? shade/i=150:4000 sea_surface_temperaturel=1,lon, lat
**ERROR: value out of legal range: X coordinates
missing value where val is needed
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1485

Comment by<EMAIL_ADDRESS>on 31 Jan 2007 22:42 UTC
When the subscripts are saved for a curvilinear grid, there are two sets of
subscripts (subroutine load_curvilinear, my new comments have * !! )

subscript limits

!! i=dim1,j=dim2 subscript within the lon,lat coordinate grid
minss_dim1 = cx_lo_ss(cx_val,dim1)
maxss_dim1 = cx_hi_ss(cx_val,dim1)
minss_dim2 = cx_lo_ss(cx_val,dim2)
maxss_dim2 = cx_hi_ss(cx_val,dim2)

subscript ranges to be used for dimensioning the arguments

!! subscripts for the lon,lat arrays in memory; xpos for lon, ypos for lat

!! dim1 in longitude coord array; dim2 in longitude coor array
xpos_loss_dim1 = mr_lo_ss(mr_xpos,dim1)
xpos_hiss_dim1 = mr_hi_ss(mr_xpos,dim1)
xpos_loss_dim2 = mr_lo_ss(mr_xpos,dim2)
xpos_hiss_dim2 = mr_hi_ss(mr_xpos,dim2)
ypos_loss_dim1 = mr_lo_ss(mr_ypos,dim1)
ypos_hiss_dim1 = mr_hi_ss(mr_ypos,dim1)
ypos_loss_dim2 = mr_lo_ss(mr_ypos,dim2)
ypos_hiss_dim2 = mr_hi_ss(mr_ypos,dim2)

The routine curv_coord_range_sub.F was added for the /MODULO qualifier on
3-argument plot commands. This looks at the index ranges specified and a check
is made for missing coordinates. This routine did not take the subscript limits
into account, but only used the memory-resident subscripts.
There seem to be some details about what happens with some of the map
projections which use 1-D coordinate varibles.


patch: Update device-statuses.md

Update to change references of Applications to Fleets

Please make sure to read the CONTRIBUTING document before opening the PR for relevant information on contributing to the documentation. Thanks!

@balena-ci rebase


add workflows release

Fix #81

why not merged it?

suggest squash commit to one commit. give more context on your commit log.

suggest squash commit to one commit. give more context on your commit log.

@dierbei Yes, please squash your commits, thanks.

Thanks for the suggestion. Wait a minute, I still need to make some adjustments.

@Burning1020 @xiaods Already rebase. please help me to review, thanks.


Web: vscode.dev -  Cannot open a remote repository - 'Error: Cannot get metadata for Uri'

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:  Web - vscode.dev
OS Version:  OS Monterey 12.5.1 (21G83)

Steps to Reproduce:

Log in successfully to github on vscode.dev (shows in bottom left settings-sync)
Attempt to open any of my remote repositories.. all are public .. It will attempt to 'load' for about 30 seconds, then error with the following screen. The text of the error is "Error: Cannot get metadata for Uri(vscode..."
I've tried both going to vscode.dev by itself, then logging-in manually. And also tried going to my github repository, hitting period key (.) to open the web ide .. both error the same way after several seconds of 'loading'
I am on my work machine and we're behind a proxy.. but I'm unsure as to why that would have any effect considering the web-ide is loading fine, and allowing me to sign-in to my github fine (my work uses bit-bucket, so there shouldn't be any .gitconfig issue, even though that would be a local setting anyway).

I opened the network panel and re-requested the web ide (by pressing . from my repo) .. There are dozens of these 'graphql CORS' errors.. the only other error I can find is this 404 highlighted

The GraphQL requests are the GitHub Repositories extension trying to request repository info (current SHA, filetree contents etc), so it makes sense that those requests failing would also cause github.dev and vscode.dev to fail to load.
Would you mind right-clicking on one of the GraphQL requests that fail due to CORS errors and providing the results of Copy as fetch? (You will want to delete the bearer token that is sent with the request before pasting the output here.)
The GitHub Repositories extension also makes requests to the REST API. Do you see only the GraphQL requests failing, and do all GraphQL requests fail?
Do you have details of how the proxy is configured (e.g. so I can try to reproduce the issue you're encountering)?


feat(SideNavigation): Change stripe location

Moving the active stripe from the left to the right for better visual consistency with the header & for better display on mobile devices with a notch.

I'm afraid this change is a no-go from me.
"consistency" is not a strong enough argument because the header is horizontal whereas the side-nav is vertical; you can look at vertical button-group and default tabs as counter-arguments.
And the iPhone notch is an extreme edge case: only applies to some phones, and only on landscape orientation (which is not the default orientation people use their phones in), and side-nav should probably not even be used on mobile so it's an anti-pattern.

I'm afraid this change is a no-go from me.
"consistency" is not a strong enough argument because the header is horizontal whereas the side-nav is vertical; you can look at vertical button-group and default tabs as counter-arguments.
And the iPhone notch is an extreme edge case: only applies to some phones, and only on landscape orientation (which is not the default orientation people use their phones in), and side-nav should probably not even be used on mobile so it's an anti-pattern.

Consistency is the argument here. It is not about vertical vs horizontal. It is about having an active marker 'inside'rather than 'outside'.
Header and SideNav are the components we usually expect to be displayed on the edges of the viewport. When this happens, active stripe is literally on the border of your screen, so visibility of it is decreased. We already have active stripe on the bottom (or in other words inside) of the header button components, whereas SideNav currently more is hidden than actually visible.
I think this change makes a lot of sense and was especially noticeable in layouts demos on mobile devices.

consistency

consistency

You didnt read.

Inconsistent:

tbh I don't see this as inconsistent because they are different directions. But the "outside" vs "inside" comparison makes sense I guess.
It still looks weird for me, especially when submenu is involved.

I think the original reason for the left stripe was so we could omit the right border and have the sidenav-button bleed into the submenu or even the page. Since we are not going for that design anymore, I think this change might be ok.
The inconsistency with tabs and button-group still bothers me. I don't think we can change tabs but maybe we should change the button-group? Although, it could also be placed near the left or right edge of the iTwin viewer and might require different stripe locations depending on which.
Mostly just thinking out loud here, there is no "right answer". I'm interested in @FlyersPh9's thoughts (outside the iPhone notch scenario, which is still a non-issue imo).

Inconsistent:

tbh I don't see this as inconsistent because they are different directions. But the "outside" vs "inside" comparison makes sense I guess.
It still looks weird for me, especially when submenu is involved.
I think the original reason for the left stripe was so we could omit the right border and have the sidenav-button bleed into its submenu. Since we are not going for that design anymore (and instead rely on changing the icon fill), I think this change might be ok.
The inconsistency with tabs and button-group still bothers me. I don't think we can change tabs but maybe we should change the button-group? Although, it could also be placed near the left or right edge of the iTwin viewer and might require different stripe locations depending on which.
Mostly just thinking out loud here, there is no "right answer". I'm interested in @FlyersPh9's thoughts (outside the iPhone notch scenario, which is still a non-issue imo).

I agree sub menu looks weird... Maybe it is worth investigating possibility to mark it as active in other way.. Not sure.
Component is pretty unique, so it is up to us to decide its design. But we need to put into consideration all the use cases and possible issues.

Placing the stripe on the right will help with cameras that cut into the view like the notch or hole punches:

It will also help screens with rounded corners:

It still looks weird for me, especially when submenu is involved.
I think the original reason for the left stripe was so we could omit the right border and have the sidenav-button bleed into its submenu. Since we are not going for that design anymore (and instead rely on changing the icon fill), I think this change might be ok.

I completely agree, I haven't been in love with the visuals since we decided against the sidenav-button bleed, but I know that we needed to drop the bleed for better visual consistency.  I am open to rethinking the visuals in a future update.


Send Property when Checked in by Another

If Swarm has who checked you in, pass that along to Micropub.

dub of #29 :)

I was sitting next to @aaronpk when I did this. I figured if someone had suggested it, he'd say so

Closing as a duplicate of #29, let's continue the discussion there. Sorry I forgot about that thread in Austin!


implementing swagger tags and parameter with asyncHandler

I'm issuing this problem in my node project (see the link below for my proshop project).
swagger can't read :
// #swagger.tags = ['Orders']
// #swagger.description = 'Endpoint for placing an order.'
in my ./backend/controllers/orderController.js file (maybe because I'm using express-async-handler)see the links below:
proshopapp96.herokuapp.com/api-docs/
Proshop project

Hi @Abderrahmenla! The version 2.8.2 has fixed this. If the problem persists, let me know.

it's working fine now! good job!