allow optional title for textual_multilabel.

@miq-bot add_label ui

@miq-bot add_label enhancement

cc @abonas @simon3z @h-kataria @dclarizio

(for images I had to add a commit using this enhancement)
Before:

After:

@miq-bot add_label UI

@moolitayer, thanks for the screenshots!  That really does help when reviewing changes.
I get the feeling that #3326, #3327, and #3328 are all really part of the same change.  Is that correct?
If so, can you create these all as one PR?  I think managing the dependencies between the PRs will get too complicated.  I'd rather see the PRs represent a single unit of change that adds an entire feature rather than several PRs that have to be merged together to add a feature.
Does that make sense?

@blomquisg hi,
trying to follow @chessbyte guidelines from a recent email:

The smaller the PR, the easier it is to review and merge.  So, preference is for many small PRs rather than fewer larger PRs.
I separated backend/ui since they are different in content and can be review by different people.

as for the title issue lets wait for responses from the cc list above.
Thanks!

trying to follow @chessbyte guidelines

Well, good thing we're presenting a unified message :disappointed:

@simon3z @blomquisg
popup div will not help with copy/paste.
as for resizing tried that (with the help of @hkay and @ewinchell) it seems a table does not handle such big amount of text well:

I out of ideas.

@moolitayer we meant something like:  http://www.w3schools.com/jquerymobile/tryit.asp?filename=tryjqmob_popup_content

I'm ok with hover over support as far as this PR goes.  There are useful applications of it.  How (correctly or incorrectly) the caller actually uses it is outside of this PR.
I think my only issue with this PR is that the key for the raw text is called :text, whereas the other summary partials use :value.  It just makes it inconsistent.
Perhaps instead:
    - items[:values].each do |values|
      %tr
        - values.each do |item|
          - if item.kind_of?(Hash)
            %td{:title => item[:title]}
              = item[:value]
          - else
            %td
              = item

(Renamed the iterators, and thus the final object is called item which contains a key called :value)

In addition, does it make sense to not carry the conditional and just fix all the callers to use Hashes?  There can't be that many of them I would guess.

@Fryguy ok if we want this regardless of #3327
Anyway to display large values (as #3327) we need something that is usable (fully visible, copy/paste, etc.) and we need @dclarizio and @h-kataria opinions.
Also putting the entire text as title and the partial visible text as value is not such a clean solution (at the very least should be the opposite)

Also putting the entire text as title and the partial visible text as value is not such a clean solution

+1
If this is only truncation / eliding, and not an actual separate piece of data, it seems like something better handled on this side, and not back at hash construction.
In fact, this seems like something that could (should?) be handled entirely in JS -- recognise that the table cell contains too much, clamp its size, and then float the full value on hover, or something.
(It also seems that it'd look measurably less awful, if not maximally useful, if we just respected the \ns in the string.)

In fact, this seems like something that could (should?) be handled entirely in JS -- recognise that the table cell contains too much, clamp its size, and then float the full value on hover, or something.

Yes, in fact I am not too much convinced that we need this PR (#3326). We should rather have something like you just described.

@Fryguy, ping

@Fryguy are we still interested in this change?
It is no longer needed for providers/containers.
Also is there a way to rerun Travis?

ping @Fryguy
still interested in this pr?

I don't see why we'd merge it without a caller using the new functionality.

yeah I agree with @matthewd ...If we are not using it, let's drop it.


Add blog section

Introduce new functionality to create blog posts on OpenSLO site.

Some nit picks, good job!

Thanks, your suggestions commited ;)


Avoid repeating const keyword in flutter_iconset.tpl

Fixes #19

Thanks.  I'll release this weekend.

Thank you, for such a great service!

Released. Thanks!


QA SV Callset Loading

Just making a ticket to track results and link any follow up work.

Results from first pass:
StrVCTVRE_score has changed from type double to keyword. We probably want to fix that, it likely means there are null-y or false-values that were incorrectly handled
A lot of fields now have "index" : false , which is because we are actually using the disable_index property now as opposed to in the old pipeline. This is a good thing. I checked and all of the fields where this is set are okay to have it except for variantId as I think we do have some queries that use this field. SO that field needs to have indexing re-enabled
There are some expected new fields: adding new_call and prev_num_alt to genotypes, adding samples_new_call , gnomad_svs_AC  and  gnomad_svs_AN
there are some unexpected new fields: docId , end_locus_contig, end_locus_position
rg37_locus is now missing from the data, which should not have changed

In the old indices the samples_gq_sv_X_to_Y  and sample_num_alt_X fields are only present in the document if they have values. In the new index, those fields are always in the document and are null if there are no values. We want to keep with the old way of handling those fields.
I noticed some transcriptConsequenceTerms have duplicate values in the list
For the variantId the format seems to be pretty different - the old IDS look like phase2_DUP_chr18_1698 and the new ones look like cohort_2911.chr1.final_cleanup_BND_chr1_222 - this might ba an issue with the file we were delivered and not the pipeline
gnomad_svs_AC  and  gnomad_svs_AN  should be integers not doubles

Old Index:
{
  "_meta": {
    "datasetType": "SV",
    "genomeVersion": "38",
    "sampleType": "WES",
    "sourceFilePath": "/Users/hsnow/Downloads/CMG_gCNV_2022_annotated.ensembl.round2_3.strvctvre.bed"
  },
  "properties": {
    "StrVCTVRE_score": {
      "type": "double"
    },
    "contig": {
      "type": "keyword"
    },
    "end": {
      "type": "integer"
    },
    "geneIds": {
      "type": "keyword"
    },
    "genotypes": {
      "properties": {
        "cn": {
          "type": "integer"
        },
        "defragged": {
          "type": "boolean"
        },
        "end": {
          "type": "integer"
        },
        "geneIds": {
          "type": "keyword"
        },
        "new_call": {
          "type": "boolean"
        },
        "num_exon": {
          "type": "integer"
        },
        "prev_call": {
          "type": "boolean"
        },
        "prev_overlap": {
          "type": "boolean"
        },
        "qs": {
          "type": "integer"
        },
        "sample_id": {
          "type": "keyword"
        },
        "start": {
          "type": "integer"
        }
      },
      "type": "nested"
    },
    "num_exon": {
      "type": "integer"
    },
    "pos": {
      "type": "integer"
    },
    "samples": {
      "type": "keyword"
    },
    "samples_cn_0": {
      "type": "keyword"
    },
    "samples_cn_1": {
      "type": "keyword"
    },
    "samples_cn_2": {
      "type": "keyword"
    },
    "samples_cn_3": {
      "type": "keyword"
    },
    "samples_cn_gte_4": {
      "type": "keyword"
    },
    "samples_qs_0_to_10": {
      "type": "keyword"
    },
    "samples_qs_1000_to_1010": {
      "type": "keyword"
    },
    "samples_qs_100_to_110": {
      "type": "keyword"
    },
    "samples_qs_10_to_20": {
      "type": "keyword"
    },
    "samples_qs_110_to_120": {
      "type": "keyword"
    },
    "samples_qs_120_to_130": {
      "type": "keyword"
    },
    "samples_qs_130_to_140": {
      "type": "keyword"
    },
    "samples_qs_140_to_150": {
      "type": "keyword"
    },
    "samples_qs_150_to_160": {
      "type": "keyword"
    },
    "samples_qs_160_to_170": {
      "type": "keyword"
    },
    "samples_qs_170_to_180": {
      "type": "keyword"
    },
    "samples_qs_180_to_190": {
      "type": "keyword"
    },
    "samples_qs_190_to_200": {
      "type": "keyword"
    },
    "samples_qs_200_to_210": {
      "type": "keyword"
    },
    "samples_qs_20_to_30": {
      "type": "keyword"
    },
    "samples_qs_210_to_220": {
      "type": "keyword"
    },
    "samples_qs_220_to_230": {
      "type": "keyword"
    },
    "samples_qs_230_to_240": {
      "type": "keyword"
    },
    "samples_qs_240_to_250": {
      "type": "keyword"
    },
    "samples_qs_250_to_260": {
      "type": "keyword"
    },
    "samples_qs_260_to_270": {
      "type": "keyword"
    },
    "samples_qs_270_to_280": {
      "type": "keyword"
    },
    "samples_qs_280_to_290": {
      "type": "keyword"
    },
    "samples_qs_290_to_300": {
      "type": "keyword"
    },
    "samples_qs_300_to_310": {
      "type": "keyword"
    },
    "samples_qs_30_to_40": {
      "type": "keyword"
    },
    "samples_qs_310_to_320": {
      "type": "keyword"
    },
    "samples_qs_320_to_330": {
      "type": "keyword"
    },
    "samples_qs_330_to_340": {
      "type": "keyword"
    },
    "samples_qs_340_to_350": {
      "type": "keyword"
    },
    "samples_qs_350_to_360": {
      "type": "keyword"
    },
    "samples_qs_360_to_370": {
      "type": "keyword"
    },
    "samples_qs_370_to_380": {
      "type": "keyword"
    },
    "samples_qs_380_to_390": {
      "type": "keyword"
    },
    "samples_qs_390_to_400": {
      "type": "keyword"
    },
    "samples_qs_400_to_410": {
      "type": "keyword"
    },
    "samples_qs_40_to_50": {
      "type": "keyword"
    },
    "samples_qs_410_to_420": {
      "type": "keyword"
    },
    "samples_qs_420_to_430": {
      "type": "keyword"
    },
    "samples_qs_430_to_440": {
      "type": "keyword"
    },
    "samples_qs_440_to_450": {
      "type": "keyword"
    },
    "samples_qs_450_to_460": {
      "type": "keyword"
    },
    "samples_qs_460_to_470": {
      "type": "keyword"
    },
    "samples_qs_470_to_480": {
      "type": "keyword"
    },
    "samples_qs_480_to_490": {
      "type": "keyword"
    },
    "samples_qs_490_to_500": {
      "type": "keyword"
    },
    "samples_qs_500_to_510": {
      "type": "keyword"
    },
    "samples_qs_50_to_60": {
      "type": "keyword"
    },
    "samples_qs_510_to_520": {
      "type": "keyword"
    },
    "samples_qs_520_to_530": {
      "type": "keyword"
    },
    "samples_qs_530_to_540": {
      "type": "keyword"
    },
    "samples_qs_540_to_550": {
      "type": "keyword"
    },
    "samples_qs_550_to_560": {
      "type": "keyword"
    },
    "samples_qs_560_to_570": {
      "type": "keyword"
    },
    "samples_qs_570_to_580": {
      "type": "keyword"
    },
    "samples_qs_580_to_590": {
      "type": "keyword"
    },
    "samples_qs_590_to_600": {
      "type": "keyword"
    },
    "samples_qs_600_to_610": {
      "type": "keyword"
    },
    "samples_qs_60_to_70": {
      "type": "keyword"
    },
    "samples_qs_610_to_620": {
      "type": "keyword"
    },
    "samples_qs_620_to_630": {
      "type": "keyword"
    },
    "samples_qs_630_to_640": {
      "type": "keyword"
    },
    "samples_qs_640_to_650": {
      "type": "keyword"
    },
    "samples_qs_650_to_660": {
      "type": "keyword"
    },
    "samples_qs_660_to_670": {
      "type": "keyword"
    },
    "samples_qs_670_to_680": {
      "type": "keyword"
    },
    "samples_qs_680_to_690": {
      "type": "keyword"
    },
    "samples_qs_690_to_700": {
      "type": "keyword"
    },
    "samples_qs_700_to_710": {
      "type": "keyword"
    },
    "samples_qs_70_to_80": {
      "type": "keyword"
    },
    "samples_qs_710_to_720": {
      "type": "keyword"
    },
    "samples_qs_720_to_730": {
      "type": "keyword"
    },
    "samples_qs_730_to_740": {
      "type": "keyword"
    },
    "samples_qs_740_to_750": {
      "type": "keyword"
    },
    "samples_qs_750_to_760": {
      "type": "keyword"
    },
    "samples_qs_760_to_770": {
      "type": "keyword"
    },
    "samples_qs_770_to_780": {
      "type": "keyword"
    },
    "samples_qs_780_to_790": {
      "type": "keyword"
    },
    "samples_qs_790_to_800": {
      "type": "keyword"
    },
    "samples_qs_800_to_810": {
      "type": "keyword"
    },
    "samples_qs_80_to_90": {
      "type": "keyword"
    },
    "samples_qs_810_to_820": {
      "type": "keyword"
    },
    "samples_qs_820_to_830": {
      "type": "keyword"
    },
    "samples_qs_830_to_840": {
      "type": "keyword"
    },
    "samples_qs_840_to_850": {
      "type": "keyword"
    },
    "samples_qs_850_to_860": {
      "type": "keyword"
    },
    "samples_qs_860_to_870": {
      "type": "keyword"
    },
    "samples_qs_870_to_880": {
      "type": "keyword"
    },
    "samples_qs_880_to_890": {
      "type": "keyword"
    },
    "samples_qs_890_to_900": {
      "type": "keyword"
    },
    "samples_qs_900_to_910": {
      "type": "keyword"
    },
    "samples_qs_90_to_100": {
      "type": "keyword"
    },
    "samples_qs_910_to_920": {
      "type": "keyword"
    },
    "samples_qs_920_to_930": {
      "type": "keyword"
    },
    "samples_qs_930_to_940": {
      "type": "keyword"
    },
    "samples_qs_940_to_950": {
      "type": "keyword"
    },
    "samples_qs_950_to_960": {
      "type": "keyword"
    },
    "samples_qs_960_to_970": {
      "type": "keyword"
    },
    "samples_qs_970_to_980": {
      "type": "keyword"
    },
    "samples_qs_980_to_990": {
      "type": "keyword"
    },
    "samples_qs_990_to_1000": {
      "type": "keyword"
    },
    "samples_qs_gt_1000": {
      "type": "keyword"
    },
    "sc": {
      "type": "integer"
    },
    "sf": {
      "type": "double"
    },
    "sn": {
      "type": "integer"
    },
    "sortedTranscriptConsequences": {
      "properties": {
        "gene_id": {
          "type": "keyword"
        },
        "major_consequence": {
          "type": "keyword"
        }
      },
      "type": "nested"
    },
    "start": {
      "type": "integer"
    },
    "svType": {
      "type": "keyword"
    },
    "transcriptConsequenceTerms": {
      "type": "keyword"
    },
    "variantId": {
      "type": "keyword"
    },
    "xpos": {
      "type": "long"
    },
    "xstart": {
      "type": "long"
    },
    "xstop": {
      "type": "long"
    }
  }
}

New Index:
{
  "_meta": {
    "datasetType": "SV",
    "genomeVersion": "38",
    "hail_version": "0.2.109",
    "sampleType": "WGS",
    "sourceFilePath": "gs://seqr-datasets/v02/GRCh38/RDG_WGS_Broad_Internal_SV/v00/phase3.concordance.fixChrX.sampleIDS.fixHeader.StrVCTVRE.vcf.gz"
  },
  "properties": {
    "StrVCTVRE_score": {
      "type": "double"
    },
    "algorithms": {
      "index": false,
      "type": "keyword"
    },
    "bothsides_support": {
      "index": false,
      "type": "boolean"
    },
    "contig": {
      "index": false,
      "type": "keyword"
    },
    "cpx_intervals": {
      "properties": {
        "chrom": {
          "index": false,
          "type": "keyword"
        },
        "end": {
          "index": false,
          "type": "integer"
        },
        "start": {
          "index": false,
          "type": "integer"
        },
        "type": {
          "index": false,
          "type": "keyword"
        }
      },
      "type": "nested"
    },
    "docId": {
      "index": false,
      "type": "keyword"
    },
    "end": {
      "type": "integer"
    },
    "filters": {
      "type": "keyword"
    },
    "geneIds": {
      "type": "keyword"
    },
    "genotypes": {
      "properties": {
        "cn": {
          "index": false,
          "type": "integer"
        },
        "gq": {
          "index": false,
          "type": "integer"
        },
        "new_call": {
          "index": false,
          "type": "boolean"
        },
        "num_alt": {
          "index": false,
          "type": "integer"
        },
        "prev_num_alt": {
          "index": false,
          "type": "integer"
        },
        "sample_id": {
          "index": false,
          "type": "keyword"
        }
      },
      "type": "nested"
    },
    "gnomad_svs_AC": {
      "type": "integer"
    },
    "gnomad_svs_AF": {
      "type": "double"
    },
    "gnomad_svs_AN": {
      "type": "integer"
    },
    "gnomad_svs_ID": {
      "type": "keyword"
    },
    "pos": {
      "type": "integer"
    },
    "rg37_locus": {
      "properties": {
        "contig": {
          "type": "keyword"
        },
        "position": {
          "type": "integer"
        }
      }
    },
    "rg37_locus_end": {
      "properties": {
        "contig": {
          "type": "keyword"
        },
        "position": {
          "type": "integer"
        }
      }
    },
    "samples_gq_sv_0_to_10": {
      "type": "keyword"
    },
    "samples_gq_sv_10_to_20": {
      "type": "keyword"
    },
    "samples_gq_sv_20_to_30": {
      "type": "keyword"
    },
    "samples_gq_sv_30_to_40": {
      "type": "keyword"
    },
    "samples_gq_sv_40_to_50": {
      "type": "keyword"
    },
    "samples_gq_sv_50_to_60": {
      "type": "keyword"
    },
    "samples_gq_sv_60_to_70": {
      "type": "keyword"
    },
    "samples_gq_sv_70_to_80": {
      "type": "keyword"
    },
    "samples_gq_sv_80_to_90": {
      "type": "keyword"
    },
    "samples_new_call": {
      "type": "keyword"
    },
    "samples_no_call": {
      "type": "keyword"
    },
    "samples_num_alt_1": {
      "type": "keyword"
    },
    "samples_num_alt_2": {
      "type": "keyword"
    },
    "sc": {
      "type": "integer"
    },
    "sf": {
      "type": "double"
    },
    "sn": {
      "type": "integer"
    },
    "sortedTranscriptConsequences": {
      "properties": {
        "gene_id": {
          "type": "keyword"
        },
        "gene_symbol": {
          "type": "keyword"
        },
        "major_consequence": {
          "type": "keyword"
        }
      },
      "type": "nested"
    },
    "start": {
      "index": false,
      "type": "integer"
    },
    "svType": {
      "type": "keyword"
    },
    "sv_callset_Het": {
      "type": "integer"
    },
    "sv_callset_Hom": {
      "type": "integer"
    },
    "sv_type_detail": {
      "type": "keyword"
    },
    "transcriptConsequenceTerms": {
      "type": "keyword"
    },
    "variantId": {
      "type": "keyword"
    },
    "xpos": {
      "type": "long"
    },
    "xstart": {
      "index": false,
      "type": "long"
    },
    "xstop": {
      "type": "long"
    }
  }
}

Some thoughts:

gnomad_svs_AC and gnomad_svs_AN are missing in the old index.
Ran this command:

comm -3 <(cat old_index_mappings.json | jq '.properties |keys[]') <(cat new_index_mappings.json| jq '.properties | keys[]') | grep -v 'samples_gq_sv'
	"docId"
	"gnomad_svs_AC"
	"gnomad_svs_AN"
	"samples_new_call"

which I think confirms everything else posted above!

Gotcha.  Yep, I was a little confused because the old pipeline does have those fields, but I see that they were recently added: https://github.com/broadinstitute/seqr-loading-pipelines/commit/d92c2ba462a7211180ed66bfdc1ab340d933b536#diff-be234aa7d0b8d8e6a8b4c25e68e7ac3e35fe18638515a4900e2e5c16ae13a6c3R51

Some rg37_locus are empty... I think this is fine.
GET r0652_pipeline_test__wgs__grch38__sv__v02__vcfv00__20230404/_count
{"query": {
    "bool": {
      "must_not": {
        "exists": {
          "field": "rg37_locus"
        }
      }
    }
  }
}

{
  "count" : 517,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  }
}

yeah liftover does fail in some cases so that is expected

Also of note is that filters and bothsides_support are always null.

GET r0652_pipeline_test__wgs__grch38__sv__v02__vcfv00__20230404/_count
{"query": {
    "bool": {
      "must_not": {
        "exists": {
          "field": "bothsides_support"
        }
      }
    }
  }
}
{
  "count" : 28329,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  }
}

I looked at the underlying vcf and that appears accurate:
bblanken@wmbbe-67c SV_WGS_Phase3_GREGoR_20230328-2 % cat phase3.concordance.fixChrX.sampleIDS.fixHeader.StrVCTVRE.vcf| grep 'BOTHSIDES_SUPPORT'
##FILTER=<ID=BOTHSIDES_SUPPORT,Description="Variant has read-level support for both sides of breakpoint">

This is NOT the case on the previous callset (r0384_rare_genomes_project_gen__structural_variants__wgs__grch38__20220329).

filters and bothsides_support are always null

Is this using the test VCF or the real VCF Alba delivered? If the real VCF, respond to the email and mention this change as thats not expected

👍 It's the real VCF.  Also seeing the issue with cpx_intervals but not convinced that it's not a bug on our implementation yet.

Looks to me like cpx_intervals is fine... it's just null for every variant included in our test project.  I see the fields present in the VCF in the correct format... and we've created the index with the appropriate types so I think we're ok.

Sanity checking some frequencies of null values:

Field
New Callset
Old Callset

gnomad_svs_AF
18301 / 28329
128779 / 191140

sv_type_detail
25832 / 28329
171992 / 191140

StrVCTVRE_score
27625 / 28329
174654 / 191140

Looks like the new VCF (gs://seqr-datasets/v02/GRCh38/RDG_WGS_Broad_Internal_SV/v01/phase3.concordance.fixChrX.sampleIDS.fixHeader.StrVCTVRE.fixFilter.vcf.gz) loads alright and has filters & bothsides_support alright!  However, there are cases where bothsides_support is missing rather than True or False... and further investigation of the VCF itself showed this to be a result of filters still being occasionally missing and hail importing filters as NaN.

the filters is worth following up on as I think it normally explicitly sets pass. For bothsides_support I think its fine to assume that missing can be treated as False, but if you want to you can confirm with Alba

Yep!  We have lots of PASS and also some missing.  The previous callset did not seem to have missing... so worth seeing what Alba says.

Looks like the issue has been resolved!
GET r0652_pipeline_test__wgs__grch38__sv__v02__vcfv01__20230410/_count
{"query": {"exists": {"field": "filters"}}}

{
  "count" : 28329,
  ...
}

GET r0652_pipeline_test__wgs__grch38__sv__v02__vcfv02__20230418/_count

{
  "count" : 28329,
  ...
}

First pass here was completed.


fix to apply command line arguments in k4run again

Hi Andrea,
Thanks for this patch! Could you add a comment explaining why exactly these lines are needed, what they are supposed to do, and what issue they fix for DIRAC?
It also looks to me like this results in a rather long printout on every invocation of k4run. Just running pythia8 alone, I already get
~/repo/k4fwcore/k4FWCore/scripts ((6f24aa0...))$ ./k4run ~/repo/fccsw/Examples/o
ptions/pythia.py
# WARNING: Found 1 duplicates among the 10 genConfDb files :
# WARNING: --------------------------------------------------
# WARNING:   -<component name>: <module> - [ <duplicates> ]
# WARNING: --------------------------------------------------
# WARNING:   -CreateExampleEventData: k4ProjectTemplate.k4ProjectTemplatePluginsConf - ['k4TestFWCore.k4TestFWCorePluginsConf']
# WARNING: Fix your cmt/requirements file !!
 -->  Pythia8 -->  HepMCToEDMConverter -->  StableParticles -->  out

Option name: Pythia8.OutputLevel Pythia8.OutputLevel 0
Option name: out.OutputLevel out.OutputLevel 0
Option name: out.filename out.filename output.root
Option name: out.outputCommands out.outputCommands ['keep *']
Option name: out.remoteFilename out.remoteFilename
Option name: Pythia8.PythiaInterface.OutputLevel Pythia8.PythiaInterface.OutputLevel 0
Option name: Pythia8.PythiaInterface.Filename Pythia8.PythiaInterface.Filename /cvmfs/sw.hsf.org/spackages2/k4gen/0.1pre02/x86_64-centos7-gcc8.3.0-opt/nyi7pl2fn5zuj65majyzpffuu6pokt6i/share/k4Gen/data/Pythia_standard.cmd
Option name: Pythia8.PythiaInterface.printPythiaStatistics Pythia8.PythiaInterface.printPythiaStatistics True
Option name: Pythia8.PythiaInterface.doEvtGenDecays Pythia8.PythiaInterface.doEvtGenDecays False
Option name: Pythia8.PythiaInterface.EvtGenDecayFile Pythia8.PythiaInterface.EvtGenDecayFile Generation/data/DECAY.DEC
Option name: Pythia8.PythiaInterface.UserDecayFile Pythia8.PythiaInterface.UserDecayFile
Option name: Pythia8.PythiaInterface.EvtGenParticleDataFile Pythia8.PythiaInterface.EvtGenParticleDataFile Generation/data/evt.pdl
Option name: Pythia8.GaussSmearVertex.OutputLevel Pythia8.GaussSmearVertex.OutputLevel 0
Option name: Pythia8.GaussSmearVertex.xVertexSigma Pythia8.GaussSmearVertex.xVertexSigma 0.5
Option name: Pythia8.GaussSmearVertex.yVertexSigma Pythia8.GaussSmearVertex.yVertexSigma 0.5
Option name: Pythia8.GaussSmearVertex.zVertexSigma Pythia8.GaussSmearVertex.zVertexSigma 40.0
Option name: Pythia8.GaussSmearVertex.tVertexSigma Pythia8.GaussSmearVertex.tVertexSigma 0.18
Option name: Pythia8.GaussSmearVertex.xVertexMean Pythia8.GaussSmearVertex.xVertexMean 0.0
Option name: Pythia8.GaussSmearVertex.yVertexMean Pythia8.GaussSmearVertex.yVertexMean 0.0
Option name: Pythia8.GaussSmearVertex.zVertexMean Pythia8.GaussSmearVertex.zVertexMean 0.0
Option name: Pythia8.GaussSmearVertex.tVertexMean Pythia8.GaussSmearVertex.tVertexMean 0.0
Option name: EventDataSvc.OutputLevel EventDataSvc.OutputLevel 0
Option name: EventDataSvc.input EventDataSvc.input
Option name: HepMCToEDMConverter.OutputLevel HepMCToEDMConverter.OutputLevel 0
Option name: StableParticles.OutputLevel StableParticles.OutputLevel 0
Option name: StableParticles.accept StableParticles.accept [1]
ApplicationMgr    SUCCESS
====================================================================================================================================

The output of Gaudi jobs can already be a bit cluttered, so I'd like to avoid adding these printouts. The output of k4run <optionsfile> -h does not let you do what you are trying to do?

This is needed to actually apply the command line arguments to the properties (not just for DIRAC), it got lost in https://github.com/key4hep/k4FWCore/pull/39/files#diff-bf40c8105fb694b5f17d061ec4fd472791c8907ad3358653775956d61e249237L135-L138
The prints should maybe be changed to use logger and this print here could be done at debug level (but for another PR).

Hi Valentin,
sorry for the bad commit message...
And thanks Andre for the clarification!
Should I change the print line then?

Good catch! The lost lines should have been noticed in some test. I added https://github.com/key4hep/k4FWCore/pull/49 for the future.
Yes,  please remove the print line, then I'll merge.

ok, I'll merge now and add the logging before the next tag


Reinstall deconz without change in homebridge-hue & HomeKit

Hello @ebaauw
I need your help. Since I have some problems currently with my deconz I intend a complete reinstallation of this bridge.
Since I don't want HomeKit to know that I have reinstalled this bridge in the background, my question to you would be what do I have to adjust in the new ZLL database so that homebridge-hue does not recognize any change or how does homebridge-hue recognize that it is a new bridge?
The Zigbee devices get the same names.
But that should not be enough or?
Or is that perhaps not possible at all? 😅
Thank you!

Homebridge Hue identifies Zigbee devices by their mac address and creates the HomeKit UUID from that.  That means you can move Zigbee devices between Zigbee gateways / bridges without impact to HomeKit, as long as they’re exposed by the same Homebridge Hue instance.
Non-Zigbee resources (CLIP sensors, groups, scenes) are identified by the resource ID, which will likely change with re-installation.  For CLIP sensors, you can patch the database table.  Groups and scenes are more tricky, since, unlike the Hue bridge, deCONZ bases their resource IDs on the Zigbee IDs.  If you’re lucky they will be read from the lights, causing deCONZ to re-create these using the same resources.

Good morning,
thank you for your quick help and sorry for the delayed reply from me.
I just want to tell you that all devices have been taken over again except for two pieces.
Since I have not created any scenes or groups, etc., they were not affected.
In summary, the move worked very well!
Thank you and have a nice day!


Stacked Bar Onclick captures multiple datapoints

When capturing onclick event with stacked bar, if clicking on/near the border between two elements the click fires twice.
Use the docs and to reproduce add to data:
onclick: function(id, element){
console.log(id);
}
http://c3js.org/samples/chart_bar_stacked.html

Oddly I'm getting a TypeError when using the onclick handler with the grouped bar chart. Marking as bug.

The problem seems to be that C3 calculates if a mouse click is within a bar using a bit of boundingbox maths in chart.internal.isWithinBar, and adds in an offset value that catches 'near misses' to this box. It does this for each bar at a given x value in the chart so several can actually report a click if it happens near adjacent bars. If this offset is fudged to say -1 the problem goes away but then really small / narrow bars are very difficult to click instead.
chart.internal.isWithinBar = function (that) {
var mouse = this.d3.mouse(that), box = that.getBoundingClientRect(),
seg0 = that.pathSegList.getItem(0), seg1 = that.pathSegList.getItem(1),
x = Math.min(seg0.x, seg1.x), y = Math.min(seg0.y, seg1.y),
w = box.width, h = box.height, offset = 2, // offset causes the multiple onclick problem
sx = x - offset, ex = x + w + offset, sy = y + h + offset, ey = y - offset;
return sx < mouse[0] && mouse[0] < ex && ey < mouse[1] && mouse[1] < sy;
};

Updating to the latest version of C3 and D3 seemed to have fixed this for me (at least better than the last version I was using).

Should be fixed by #2684


Install quits after selecting IP address

Hi all,
I'm new to PiVPN but have a fresh install of Raspbian all ready.  The OS is update to date and when I run the command: curl -L https://install.pivpn.io | bash
I click ok to This installer will transform your Raspberry Pi....
I click OK to static IP needed..
I select eth0 (available)
I choose to use my current network settings
Then it says "FYI : IP Conflict" and other text saying "It is possible your router could still try to assign this IP to a device..." etc
I click OK and the installer quits to command line reporting:
::: Static IP already configured.
: error fetching interface information: Device not found
: error fetching interface information: Device not found
Any ideas guys? I'm lost.

To add to this..
This file: /etc/dhcpcd.conf
Does appear to have been written to with static IP details:
A hook script is provided to lookup the hostname if not set by the DHCP
server, but it should not be run by default.
nohook lookup-hostname
interface
static ip_address=192.168.x.xxx
static routers=192.168.x.xxx
static domain_name_servers=192.168.x.xxx

OS details:
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

This issue seems to be happening a lot ... so today // tomorrow wil to some testing about this ... meanwhile ... can you uninstall pivpn
pivpn uninstall
Update the system first
sudo apt-get update
sudo apt-get upgrade

then try rerun pivpn!!

Thanks for the response :)
I've ran the update and upgrade but still getting the same issue:
: error fetching interface information: Device not found
: error fetching interface information: Device not found
Thanks for supporting this! Looking forward to the fix 👍

I have exactly the same issue.
I ran the install script
`curl -L https://install.pivpn.io | bash
and was able to select the static IP address and gateway address, then got a FYI: IP Conflict information window and then suddenly exit the setup back to the shell.
I tried to install pivpn on a Raspberry 2 Model B with Raspbian GNU/Linux 8 (jessie) v4.9.57 v7 and a German localization. Enough SD card space is provided. Attempted it with sudo in a zsh and as root in a bash. No error entries in syslog or something like that

I am sorry guys ... not having much time as I have expected ... but will soon do some testing and see if I can replicate this ...

Ok  ... tested it myself ... and I experienced ZERO errors with the config.
seems that the raspbian folks want to hide the old images, so  had to dig around to find the old raspbian images  and here they are: http://downloads.raspberrypi.org/raspbian/images/
seems I cant reproduce the error!
Important to mention that I am at an hotel so I am quite limited and more prone to errors, but they didn't happened.
So I took the steps that a regular, user with little knowledge would take!!
Steps I have taken:
1- downloaded the latest jessie image from the website i mentioned earlier.
2 - burned the image into the sdcard and booted jessie
3 - ran pivpn script ... over WLAN and it went quite smooth!! No errors at all and is all running!!
So mates What I will recommend you, is to Re image your pis with Stretch and follow from there ... I will stop to provide support to jessie for new installs! there are too much issues around here and so litle time, so better start focusing on things that really need to be solved!
I am sorry guys .. hope you can understand my position here! @0-kaladin @redfast00 hope you can agree with me on this!
If any of you can provide me the exact steps to replicate this issue, please post it here, and I will be glad to re open the issue and fix whatever needs to be fixed. until there... is just something you did wrong on your systems! It mitght be a missing package that it is failing to get from updates,  it may be missing file, may be a messed up config in /etc/ ... it can be a gazilion of thigs ... so I need the exact steps to replicate this! ... the regular install .. works just fine!

Thats an issue of language. If your system speaks German the grep and awk in setNetwork doesn't work. i.E. Mask is Maske in german and addr is Adresse. So just dpkg-reconfigure locales to english and it should work.
Perhaps future versions of that script should verify the language or do a export LANG=en (LANGUAGE, LC_ALL?)

I also had this same problem Where it stopped on me. What i did was installed the latest Raspberry pi RASPBIAN STRETCH WITH DESKTOP.
At this time i post it the Version is
Version:April 2018
Release date:2018-04-18
Kernel version:4.14
After i installed that i did not update or upgrade it. I did hooked up a monitor with a keyboard and mouse then i went into the config  to enable SSH and VNC because i use VNC a lot. After that i went into the config once more and Expand the file storage to use all the the SD card. I;m using a 16GB ssd class 10 card for the speed.
Then i rebooted came back in remotely into putty and i installed pipvn using the command Sudo curl -L https://install.pivpn.io | bash
I'm not a programmer so forgive me on that. I'm learning as i go along. Once i did all of that i was able to get to the setup blue screen of the Pipvn and put in my settings Now I'm able to do VPN. Hopefully this will help Someone.

sudo apt-get autoremove --purge while i'm waiting for the image to write to the other SD card. No luck

closing this as this seems to be resolved with the latest changes.
if this still a thing let us know.


JsonLogic - unexpected behaviour from var operator

Environment

Nuget Package: JsonLogic
Nuget Version: 3.3.1
OS: MacOS
.Net Target: net6.0

Describe the bug
Within a none rule, I am using var to retrieve a specific property on that object and check it against a specific value. However when that value is missing I expect var to return null as var should be pointing to the data context within the current element being evaluated within the array. But what actually happens is internally var calls a special secondary data called contextData (the root data object) and returns the value from there if it exists.
To Reproduce
Rule
{
	"none": [
		{
			"var": "additionalDrivers"
		},
		{
			"===": [
				{
					"var": "relationshipToProposer.dataCode"
				},
				"J"
			]
		}
	]
}

Data
{
	"hasAdditionalDrivers": true,
	"additionalDrivers": [
		{}
	],
	"relationshipToProposer": {
		"dataCode": "J",
		"displayText": null
	}
}

Expected
true

Actual Result
false

Expected behavior
Within a none operator, var should only be able to retrieve data from within the currently evaluated item of the array supplied to none.
Additional context
The docs do not mention anything like this sort of behaviour json-logic docs, and the same rule and data produces the expected output in other versions of JsonLogic tool, which leads me to believe this is a bug.

Yeah, that looks to be right.  I'll add a test and fix.  Thanks.

It looks like there is some odd behavior here that (as always with this project) isn't specified completely.  #263 is related.  I'm having trouble getting both of these to work.

Hey, thanks for the quick reply,
I think resolution described in #263 is the bug I am talking about. 😅
Example
Rule:
{
    "some" : [
        { "var":"x"},
        {
            "in": [ {"var":""}, {"var":"y"} ]
        }
    ]
}

Data:
{
    "x": [-1, 0, 1],
    "y": [2, 3, 1]
}

I would expect this to return false and when checking against the other json-logic libraries they agree
.
However, it looks like the issue you linked is suggesting the exact opposite behaviour to what happens in the other json-logic libraries. I don't think it's possible to support both this issue and #263.

Yeah, I definitely want alignment with the original.  I'll have to re-read that issue to find out why I thought it should be the other way.


fix(dashboard): improve performance by memoizing the CardRenderer

feat(cardrenderer): add caching layer on top of the memoized cardRenderer to cache old style and the old onCardAction methods
refactor(dashboard): remove the dashboard template from state and instead just use expandedId.  This will allow us to memoize callbacks depending on a much more granular state

:tada: This PR is included in version 1.97.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.5.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Kustomization Fails when base is an SSH URL

My kustomization.yaml includes:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: customerx
bases:
  - ../bases
  - git::ssh://git@github.com/example/repo.git?sshkey={base64 id_rsa}

Pointing at a private repo on github with an sshkey embedded in the URL.  Kustomize locally successfully builds the correct yaml and can pull from github using the private key but when deploying with the toolkit the customization fails with:
kustomize build failed: accumulating resources: accumulateFile "accumulating resources from 'git::ssh://git@github.com/example/repo.git?sshkey={base64 id_rsa}': open /tmp/path/git::ssh:/git@github.com/example/repo.git?sshkey={base64 id_rsa}: no such file or directory", loader.New "trouble cloning git repo<EMAIL_ADDRESS>in /tmp/kustomize-436177202: exit status 128"

Remote bases are not supported at the moment, see: https://github.com/fluxcd/kustomize-controller/issues/136, #374 and #326

@hiddeco Thanks for the quick response


PYIC-3661: Pass context & scope from state to CRIs

Proposed changes
What changed

Add functionality to take context & scope from journey map state response definitions
Then to pass it between lambdas within the journey parameter by constructing that parameter as a URI with context & scope as parameters

Why did it change

To be able to provide context & scope to CRIs for specific journeys

Issue tracking

PYIC-3661

Checklists
Other considerations

[ ] Update README with any new instructions or tasks


Fixed search and added history export function

In search function was used incorrect reference in line 370 and it fails the search.
Additionally was provided function to export all historical data, as it was inaccessible in previous versions. This function is useful for exporting/importing data and debugging

@nikolaydymura, could you please take the pre-release from Grey and test it with our codebase? He mentioned on Slack the changes where integrated (while PR was not merge-able as is)


Steelseries Arctis 5, the right earcup cant be controlled.

It worked fine, but then I updated firmware of the headset and since than only left earcup is synced to aurora. Any chance of looking into this?

This was fixed in Steelseries Engine 3.13.8.


[BUG] Docker container does not stop running after Data Prepper shuts down

Describe the bug
I'm using the Docker version of Data Prepper (opensearch-data-prepper:2.4.0-SNAPSHOT) built from source (./gradlew :dockerSolution:buildDockerImages). When using a pipeline that includes an Opensearch source, invoking Data Prepper's shutdown API appears to terminate the Data Prepper server but does not stop the Docker container.
Snippet of Data Prepper logs:
...
Found openjdk version  of 17.0
2023-08-10T23:16:46,589 [main] INFO  org.opensearch.dataprepper.parser.PipelineParser - Building [opensearch] as source component for the pipeline [test-pipeline]
....
2023-08-10T23:16:46,940 [main] INFO  org.opensearch.dataprepper.parser.PipelineParser - Building [opensearch] as sink component
....
2023-08-10T23:16:47,223 [main] INFO  org.opensearch.dataprepper.pipeline.Pipeline - Pipeline [test-pipeline] - Initiating pipeline execution
....
2023-08-10T23:16:47,488 [main] INFO  org.opensearch.dataprepper.pipeline.server.DataPrepperServer - Data Prepper server running at :4900
....
2023-08-10T23:16:48,143 [test-pipeline-sink-worker-2-thread-1] INFO  org.opensearch.dataprepper.pipeline.Pipeline - Pipeline [test-pipeline] - Submitting request to initiate the pipeline processing
....
2023-08-10T23:16:51,810 [pool-4-thread-1] INFO  org.opensearch.dataprepper.pipeline.Pipeline - Pipeline [test-pipeline] - Received shutdown signal with processor shutdown timeout PT30S and sink shutdown timeout PT30S. Initiating the shutdown process
....
2023-08-10T23:17:21,813 [pool-4-thread-1] INFO  org.opensearch.dataprepper.pipeline.Pipeline - Pipeline [test-pipeline] - Shutting down processor process workers.
....
2023-08-10T23:17:23,026 [pool-4-thread-1] INFO  org.opensearch.dataprepper.pipeline.Pipeline - Pipeline [test-pipeline] - Shutting down sink process workers.
2023-08-10T23:17:23,027 [pool-4-thread-1] INFO  org.opensearch.dataprepper.pipeline.Pipeline - Pipeline [test-pipeline] - Pipeline fully shutdown.
2023-08-10T23:17:23,057 [pool-4-thread-1] INFO  org.opensearch.dataprepper.pipeline.server.DataPrepperServer - Data Prepper server stopped

Command line:
$ docker ps
CONTAINER ID   IMAGE                                    COMMAND                  CREATED          STATUS          PORTS                    NAMES
08319e699cae   opensearch-data-prepper:2.4.0-SNAPSHOT   "/entrypoint.sh bin/…"   23 minutes ago   Up 22 minutes   <IP_ADDRESS>:4900->4900/tcp   epic_jackson
$ docker top 0831
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                48665               48639               3                   23:16               ?                   00:00:43            java -Dlog4j.configurationFile=/usr/share/data-prepper/config/log4j2-rolling.properties -Ddata-prepper.dir=/usr/share/data-prepper -cp /usr/share/data-prepper/lib/* org.opensearch.dataprepper.DataPrepperExecute
root                49046               48639               0                   23:19               ?                   00:00:00            /bin/bash

Pipeline configuration:
test-pipeline:
  sink:
  - opensearch:
      bulk_size: 2
      document_id_field: getMetadata("opensearch-document_id")
      hosts:
      - [redacted]
      index: ${getMetadata("opensearch-index")}
      password: [redacted]
      username: [redacted]
  source:
    opensearch:
      disable_authentication: true
      hosts:
      - [redacted]
      indices:
        exclude:
        - index_name_regex: \.*
        include:
        - index_name_regex: [redacted]
        - index_name_regex: [redacted]

This is possibly an issue only with the opensearch source plugin - I used the following pipeline and the Docker container stopped correctly (the sink endpoint in both cases is the same).
http-test-pipeline:
    source:
        http:
    sink:
        - opensearch:
            hosts: [redacted]
            username: [redacted]
            password: [redacted]
            index: "httptest"

To Reproduce
See above
Expected behavior
The Docker container stops after the Data Prepper server has shut down
Screenshots
N/A
Environment (please complete the following information):

OS: MacOS 12.6.6
Version: Data Prepper 2.4.0-SNAPSHOT

Additional context
N/A

Additional info:
After the Data Prepper server stopped log line above, API calls to the Docker process are not responsive i.e. there is no longer a process listening on the port
I've also attached a jstack dump that i took on the Docker container:
jstack_3141.txt

I was able to repro the same behavior outside Docker (using the binary from ./gradlew build). Pipeline configuration remained the same.
jstack dump - jstack_dump_2.txt


pull request review required.

I follow the how to use step by step. But it won't automatic merge the pull request.it confused me. plz check this out.

We are not merging the PR automatically.
I have just merged it, and you can expect the OSSChat bot to start working after 10 minutes!
And welcome!

thanks a lot dude. keep doing great things!!

it works!!

Congratulations!


add new production for src3 with tuned NSB for moon data analysis

New Prod config
Self check-list:

[X] I have checked the lstchain config, in particular for:

[X] az_tel instead of sin_az_tel if data to be analyzed have been produced with lstchain <= v0.9.7
[X] "increase_nsb" and "increase_psf" are provided in "image_modifier" (if used)

[X] I have checked the environment in the lstmcpipe config and it is the one used to analyse DL>1 data
[X] I have provided the command (in README), or script (in additionnal .py file) used to produce the lstmcpipe config

Prod_ID
20240426_v0.10.9_src3_dec3476_4822_tunedNSB
Short description of the config
Config for a source with dec within 3476/4822 and NSB tuning:
"image_modifier": {
   "increase_nsb": true,
   "extra_noise_in_dim_pixels": 6.974,
   "extra_bias_in_dim_pixels": 1.825,
   "transition_charge": 8,
   "extra_noise_in_bright_pixels": 4.195
}

lstmcpipe_generate_config PathConfigAllSkyFull --prod_id 20240426_v0.10.9_src3_dec3476_4822_tunedNSB --dec_list dec_3476 dec_4822
Why this config is needed
See wiki page (src 3)
https://www.lst1.iac.es/wiki/index.php/MC_analysis_and_IRF_production#lstmcpipe_productions

Prod started 🚀

@vuillaut, it seems that some jobs from this prod did not finish correctly, can you please check?

hi @morcuended , could you be more specific please? I don't see any job from this prod pending or in fail and I can see the DL2 have been produced

Indeed, my bad, those other pending jobs were from another prod. Files from this one look good. Thanks!


feat: Add Tag popup

This commit implements the magit tag popup.
Completed:

Create tag
Delete tag

Needs improvement:

Prune

Haven't started:

Create release

The prune implementation works but I need to call ls-remote asynchronously as it takes  a bit of time.
I also need to figure out how to show the user the list of local/remote tags to be pruned by selecting the y option 🤔 .
Closes #783

Do you want feedback as you go, or later?

Feedback as I go if possible.
I don't think create release can be done due to lua pattern matching limitations.

What do you need it to do that it cant? I find them to be pretty versatile.

I fixed up some notification related things that I cleaned up recently.

Sorry for the delay, I believe I've fixed the issues. Only problem I'm running into now before I think this is good enough to be merged is when doing the tag prune function and there is more than one tag to be pruned locally/remotely, I need to show the user a list of tags to be pruned and then ask for confirmation. Know any good ways to show a list to users or should I just write it out to stdout?

It looks like how magit goes about this is:

Select p action
Ask user to select remote (prompt: Prune tags using remote)
Ask for yes/no confirmation for each tag to be pruned.

I think we could improve on that slightly:
if #tags_to_prune > 1 then
  -- Present options to user with prompt like "{count} tags can be removed locally":
  -- - remove all
  -- - review each
  -- - abort
elseif #tags_to_prune == 1 then
  -- Just ask to remove this tag, the same as "review each" above, for the one
else
  -- Print something like "no tags found"
end

Looks awesome dude! Really appreciate the contribution.


ZEPPELIN-3374. Improvement on PySparkInterpreter

What is this PR for?
A few improvements on PySparkInterpreter.

Refactor PySparkInterpreter to make it more readable
Code completion features is totally broken, fix it in this PR
Reuse the same test case of IPySparkInterpreter.

What type of PR is it?
[Bug Fix | Improvement | Refactoring]
Todos

[ ] - Task

What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-3374

How should this be tested?

CI pass

Screenshots (if appropriate)
Code completion before

Code completion after

Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

Will merge if no more comments


iPhone 14 iOS build mini only 60% of the screen is shown

Godot version
4.0 beta 7
System information
MacBook Air M1 16gb ram 1tb SSD with Mac OS 13.0 (22A380)
Issue description
Touch input works great on both iPad mini (2021) and iPhone 14 but the screen on the 14 won't fill all the way while on the iPad it's filled edge to edge.
Steps to reproduce
build the attached project for iOS.
on an iPhone 14 is shows part of the screen and black bottom and right boders that cover 2/3rd of the screen.
on the iPad it build perfectly and looks great.
touch demo works on both devices great.
Minimal reproduction project
you can build the project below with Xcode just change the teamID and bundle ID
https://drive.google.com/file/d/1WMLvX-5pH8OOPTXOIIdFSPLFAFzoKs9f/view?usp=sharing

Duplicate of #69267


WIP: Twitter sensor

Description:
TBD
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#TBD
Example entry for configuration.yaml (if applicable):
TBD

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

Wow.. Twitter requires you to fill out a form and explain what your 'app' does in a minimum of 300 characters... I've applied for a developer account so hopefully I get approved soon :confused:

Why not authenticate against the account of the actual user?
That allows access to "private" accounts you follow as well and removed the need for a developer account.

Since the twitter developer request process is so ridiculous, (They literally want an essay to be able to access an API which should be public / just need a simple login) I'm going to abandon this. It was a nice thing to have but a scrape sensor will have to suffice. 😕
If someone has managed to get a developer account and wants to continue this component be my guest. Current status is dry coded since I cannot even get authenticated to test the thing. 😖


feat(ci): New tasks to lint aws ssm get-parameter calls

What does this PR do?
Add 2 new tasks for future auto linting of aws ssm parameters

one task to list params
one to warn about "misusage" of aws ssm get-parameter calls

This PR just creates the new linters, I will activate with a follow-up

Motivation
incident-25366: improve knowledge of our parameters in case of disclosure

Additional Notes
This PR must be reviewed by commits. It includes a refactoring of some linters tasks

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

I feel like the renaming of all linter tasks should have been in separate PR for clarity and simplicity...

It's 2 distinct commits, I guess this is quite similar (and we don't have a strong inclination to prefer one over the other)
I will merge with rebase and merge for the sake of git history


More conhost exceptions via SetConsoleScreenBufferSize

Environment
Windows build number: Version 10.0.18363.1198
Windows Terminal version (if applicable): Commit 62131720aa7a95df7ed397801c373d4eab0fd3d6
Steps to reproduce

Start a conhost cmd shell.
Open the properties and make sure Wrap text output on resize is unchecked.
Compile and run the program below.

#include <windows.h>
int main()
{
	HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
	COORD coord;
	coord.X = 160;
	coord.Y = 100;
	SetConsoleScreenBufferSize(h, coord);
	SMALL_RECT r = { 80, 75, 159, 99 };
	SetConsoleWindowInfo(h, TRUE, &r);
	SetConsoleCursorPosition(h, { 159, 99 });
	coord.X = 80;
	SetConsoleScreenBufferSize(h, coord);
	return 0;
}

Expected behavior
The conhost instance shouldn't crash and there shouldn't be any exceptions logged in the debug output.
Actual behavior
On my current version of Windows the conhost instance crashes. On the latest version of OpenConsole the exception is caught, so it at least doesn't crash, but you can see the error being logged in the debug output.
This is essentially the same bug as #1976, only the overflow is horizontal rather than vertical. It should have been fixed by PR #8309, but I managed to screw that up. I mistakenly thought the Viewport::EndExclusive method returned the bottom right extent of the viewport, but it's actually returning { Left(), BottomExclusive() }, so the overflow calculation doesn't detect a horizontal overflow. See here:
https://github.com/microsoft/terminal/blob/d09fdd61cbb11b7ef2ccdd4820349ffe898ad583/src/host/getset.cpp#L530-L531
and here:
https://github.com/microsoft/terminal/blob/ae550e0969595f062b15c2ff5cc33d4afe8ebc3f/src/types/viewport.cpp#L148-L151
The fix is easy enough. I'd probably just add something like an ExclusiveExtent method to the Viewport class that returns the range I was actually excepting to get from Viewport::EndExclusive. Does that seem reasonable?

Yea that seems sensible to me. Thanks for investigating and putting the fix together!


M.2 2280 support

Given the case is oversized, consider support typical 2280 SSDs.
I have a really basic Creo rest which bolts to the 2230 and 2242 mount points and provides a mount hole for a 2280 at the optimum bolt height. It could either be included or incorporated into the PCB mounting solution.

I dont have one of those on hand. I'll look into it. The pcb I'm talking about is just for the head phone jack and power button and RTC battery. tiny DIY level stuff. My case is 135mm long along the base. The 2280 ssd is 22x80mm That could fit in the bottom easy. The top at the shortest is 104mm long. Vertical its 100mm tall. As is the 2280 would fit anywhere. IMO a remote header would be the best choice.


Auth failed in webhook extension throws errors instead of using permissionDeniedHandler

Description
The webhook extension currently just throws errors to the console when auth fails, instead of using permissionDeniedHandler  and ultimately triggering onAuthenticationFailed in the provider.
} catch (e) {
      console.error(`Caught error in extension-webhook: ${e}`)
      throw Forbidden
    }

Expected behavior
The webhook should be properly integrated with the server auth system, and when authentication via the webhook fails it should return a proper auth failed message to the provider and thus call the onAuthenticationFailed handler.

Thanks! The onConnect hook is not meant for authentication purposes, I've just pushed an update to remove the paragraph from the docs.
If you want to set up authentication, the best way right now is to implement this on your own as a onAuthenticate hook on the server. This method can just call your webhook and everything should work fine. As carecodex mentioned in PR #506, a slow onConnect response will allow someone to access the document before the connection gets rejected.


Documentation: Fixup more missing paragraphs

Add more paragraphs between code blocks and text. This fixes rendering
errors on jekyll.

cc @robszumski @jonboulle one more :)

markdown, the spec that isn't a spec

lgtm :-(


Updating config var to be pass instead of passw

Per comment on closed PR;
https://github.com/InfluxGraph/influxgraph/pull/38

Coverage increased (+0.2%) to 92.398% when pulling c605cea6e7a4023831b09686ac6d48acc6885438 on beardpapa:pass_variable into bad64e4ab74f72791f8356b05ca021204b9ee1cf on InfluxGraph:master.

Thanks for the contribution! 👍


[hotfix] [docs]Fix miss semicolon on SELECT & WHERE clause example sql

What is the purpose of the change
(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)
Fix miss semicolon on SELECT & WHERE clause example sql.
Brief change log
Add semicolon for miss semicolon example sql.
Verifying this change
Since the changes affect the doc examples and there are no tests. I copied the snippets and verified (compiled) them locally.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Thanks for the contribution
IIRC semicolon is just a statement terminator and it always should be used to inform parser that the statement is finished, so it is ok to not specify it in such doc having this in mind. Even more there is no concrete example with concrete environment. For instance if we try to use these examples with Flink SQL Client then yes we need to use semicolon, however if we try to use this with Table SQL then there is no need for that

I know what you mean. But I suggest it's better to unify it in the docs, rather than having some IIRC and others not @snuyanzin

then I don't think the unification is limited only to select.md
you can have a look at
https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/limit/
https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/orderby/
https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/joins/
https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/group-agg/
and many more including chinese version
and you'll see that lots of queries are without semicolon
and also I think it would make sense to ask for instance in ML whether the community is ok with such unification (not sure about this yet..)

then I don't think the unification is limited only to select.md
you can have a look at https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/limit/ https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/orderby/ https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/joins/ https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/group-agg/ and many more including chinese version and you'll see that lots of queries are without semicolon and also I think it would make sense to ask for instance in ML whether the community is ok with such unification (not sure about this yet..)

You might be right in a way. So, who will ask for the mailing list?  @snuyanzin


[Device Support Request] Hue Bulb E14 Color<PHONE_NUMBER>01) power last state

Hello there,
it is possible to add this type of hue bulb last power state value?  (0x4003 i think so)
{
  "node_descriptor": "<Optional byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=4107 maximum_buffer_size=71 maximum_incoming_transfer_size=45 server_mask=0 maximum_outgoing_transfer_size=45 descriptor_capability_field=0>",
  "endpoints": {
    "11": {
      "profile_id": 49246,
      "device_type": "0x0210",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0008",
        "0x0300",
        "0x1000"
      ],
      "out_clusters": [
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [
        "0x0021"
      ],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "Philips",
  "model": "LCT012",
  "class": "zigpy.device.Device"
}

This should already be supported:
https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/philips/zllextendedcolorlight.py#L40
Example of a LCT012 model:

(Clicked "Get Attribute")
When you want to set it to "Restore Last State", enter 0xFF:

0x00 is always OFF
0x01 is always ON (warm-white)

this one has a slightly different signature, it is missing the 64513 cluster, other than that looks exactly the same

the only difference https://github.com/zigpy/zha-device-handlers/blob/1f0bd91c746afe3d1576954ceefd74ee2e37fc63/zhaquirks/philips/zllextendedcolorlight.py#L65

Oh, I didn't even look at it, because the model was the same.
I think something like ZLLExtendedColorLight2 (like ZHAExtendedColorLight2) could be done.
But since the model is the same - I'm just wondering, what firmware version are you running? @vampywiz17
"1.50.2_r30933" seems like it's the latest firmware for the ZLL models.

@TheJulianJES
softwareBuildID:  1.50.2_r30933
seems like latest.


Go mod cleanup to fix canonical SHAs

This uses the canonical releases instead of using git has for the replace in go modules. This PR sets all k8s components to v0.16.6 or for /kubernetes v1.16.6.
Fixes #711
Signed-off-by: Chris Hein<EMAIL_ADDRESS>

Thanks for fixing this.
/lgtm
/approve


Add to the list of Jupyter Kernels

Is this ready to be added to this list: https://github.com/jupyter/jupyter/wiki/Jupyter-kernels?

I will soon. I would like to get some stuff done first.

Will do after #1 and # 32 are done.

Done

Nice!


Fix Deadlock When Deepgram Stream Timeout is Received

Proposed changes

This should address issue https://github.com/deepgram/deepgram-python-sdk/pull/305
Types of changes
What types of changes does your code introduce to the community Python SDK?
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update or tests (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[ ] I have lint'ed all of my code using repo standards
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

NA

This removes any unhandled exceptions from making it to the user... preserves the exception through an option in case someone is using that as a means of doing something higher up.


Ghost column inserted with SELECT INTO

OS: CentOS 6.10
InfluxDB: 1.7.6
I'm looking at how to reduce the amount of historical data storage. I thought I could use a SELECT statement similar to the resample examples. That created a "mean" column, so I tried to get rid of "mean" by using "AS" to create the column with the correct name. That doesn't work because "mean" is still created (it should not.)  Once a field is created in a shard it exists forever in the index.
You should delete the shard completly or wait for it's expiry and a new one to be created.
Important notice: if you delete a shard all measurements having the same database and retention policy will be deleted too. Do the necessary backups before dropping the shard.

The "_1" fields come from a typo error.
It happens when you write a tag as a field during an insert to into the same measurement it already has the tag name.
Your first Insert to has the group by clause:
SELECT MEAN(value) AS value INTO temp_mean FROM ipmi WHERE host = 'linux' AND type = 'fanspeed' AND type_instance = 'FAN3' AND time >=<PHONE_NUMBER>000000000 AND time <<PHONE_NUMBER>000000000 GROUP BY time(15m),host,type,type_instance;
The second one it hasn't:
SELECT time,host,type,type_instance,value INTO ipmi FROM temp_mean;
Also, as you are using the same measurement and retention policy, the index exist even with the prior delete.

If you do not include the "GROUP BY" with the extra tags then they are lost.  They should be gone!

Finally it works as expected:
> SELECT MEAN(value) AS value,FIRST(host) AS host,FIRST(type) AS type,FIRST(type_instance) AS type_instance INTO t2_mean FROM ipmi WHERE host = 'linux' AND type = 'fanspeed' AND type_instance = 'FAN3' AND time >=<PHONE_NUMBER>000000000 AND time <<PHONE_NUMBER>000000000 GROUP BY time(15m),host,type,type_instance;
name: result
time written
---- -------
0    24
> SELECT * FROM t2_mean;
name: t2_mean
time                host      type     type_instance value
----                ----      ----     ------------- -----
1525543200000000000 linux     fanspeed FAN3          2400
1525544100000000000 linux     fanspeed FAN3          2400
1525545000000000000 linux     fanspeed FAN3          2400
1525545900000000000 linux     fanspeed FAN3          2400
1525546800000000000 linux     fanspeed FAN3          2400
1525547700000000000 linux     fanspeed FAN3          2400
1525548600000000000 linux     fanspeed FAN3          2400
1525549500000000000 linux     fanspeed FAN3          2400
1525550400000000000 linux     fanspeed FAN3          2400
1525551300000000000 linux     fanspeed FAN3          2400
1525552200000000000 linux     fanspeed FAN3          2400
1525553100000000000 linux     fanspeed FAN3          2400
1525554000000000000 linux     fanspeed FAN3          2400
1525554900000000000 linux     fanspeed FAN3          2400
1525555800000000000 linux     fanspeed FAN3          2400
1525556700000000000 linux     fanspeed FAN3          2400
1525557600000000000 linux     fanspeed FAN3          2400
1525558500000000000 linux     fanspeed FAN3          2400
1525559400000000000 linux     fanspeed FAN3          2400
1525560300000000000 linux     fanspeed FAN3          2400
1525561200000000000 linux     fanspeed FAN3          2400
1525562100000000000 linux     fanspeed FAN3          2400
1525563000000000000 linux     fanspeed FAN3          2400
1525563900000000000 linux     fanspeed FAN3          2400

Strange that without an aggregation function in the SELECT, tags are dropped completely even though they are referenced in the GROUP BY clause:
> SELECT MEAN(value) AS value FROM ipmi WHERE host = 'linux' AND type = 'fanspeed' AND type_instance = 'FAN3' AND time >=<PHONE_NUMBER>000000000 AND time <<PHONE_NUMBER>000000000 GROUP BY time(15m),host,type,type_instance;
name: ipmi
tags: host=, type=, type_instance=
time                value
----                -----
1525542300000000000
1525543200000000000 2400
1525544100000000000 2400
1525545000000000000 2400
1525545900000000000 2400
1525546800000000000 2400
1525547700000000000 2400
1525548600000000000 2400
1525549500000000000 2400
1525550400000000000 2400
1525551300000000000 2400
1525552200000000000 2400
1525553100000000000 2400
1525554000000000000 2400
1525554900000000000 2400
1525555800000000000 2400
1525556700000000000 2400
1525557600000000000 2400
1525558500000000000 2400
1525559400000000000 2400
1525560300000000000 2400
1525561200000000000 2400
1525562100000000000 2400
1525563000000000000 2400
1525563900000000000 2400

Ok, I think I've broken influxdb. A simple query like this gets no return in over a minute:
SELECT * FROM collectd.autogen.ipmi WHERE host = 'linux' LIMIT 1

Oh.... from top(1) ...
   Aborting the query does not reduce the CPU use of whatever thread is stuck and because influxdb is using go, it would seem that the stuck thread gets migrated around different PIDs making it difficult to figure out what's wrong. How did it get into this state and how does the database recover from it?


Prevent app to crash from incoming message

Hi,
This is a pull request for this related issue https://github.com/howdyai/botkit/issues/1450
Thank you

Fixed by #1474


Updated World Height

Searched for 256 and changed it to 320 and y=0 to y=-64

The world height is not static anymore and changes with the version, so just updating some constants likely is not the proper fix

Additionally, have you checked this to work ?

Additionally, have you checked this to work ?

Nope, I just figured that -64 is the lowest and I don't think it is practical to go beyond 320 as that is the default for newer versions...

Additionally, have you checked this to work ?

Nope, I just figured that -64 is the lowest and I don't think it is practical to go beyond 320 as that is the default for newer versions...

I have tested it now, and it does not make the viewer able to render below y=0.
Additionally, I there are more errors in the console. Whether these come from this pr or not is unknown.
THREE.BufferGeometry.computeBoundingSphere(): Computed radius is NaN. The "position" attribute is likely to have NaN values

please update properly


XMLHttpRequest POST 400 Bad Request

I am using a XML Http Request with POST to try and upload data to your site, but I keep getting 400 Bad request. The content type IS json, and the data IS in json format. Is the site down? Also when I use a GET request i get {result: null, okay: true}. Is that supposed to happen? Im new to this service and I don't know how it works

Hey @owocean, can you share an example of the code you're trying to run?

@bluzi I'm facing the same issue. I'm using browser-based JS. I tried using an ajax request:
$.ajax({
	'url': endpoint,
	'type': 'POST',
	'data': this.someJSON,
	'dataType': 'json',
	'contentType': 'application/json; charset=utf-8'
})

Chrome tells me:
Access to XMLHttpRequest at 'https://www.jsonstore.io/XXXXXXXXXXXXX/t' from origin 'https://XXXXXXXXX.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I then tried fetch, as suggested in the readme's JS section:
fetch(endpoint, {
	headers: {
		'Content-type': 'application/json'
	},
	method: 'POST',
	body: this.someJSON,
});

Now Chrome tells me:
(index):1 Access to fetch at 'https://www.jsonstore.io/XXXXXXXXXXXXX/t' from origin 'https://XXXXXXXXX.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
main.js:142 POST https://www.jsonstore.io/XXXXXXXXXXXXX/t net::ERR_FAILED
Uncaught (in promise) TypeError: Failed to fetch

Then I tried adding no-cors:
fetch(endpoint, {
	headers: {
		'Content-type': 'application/json'
	},
	method: 'POST',
	mode: 'no-cors',
	body: this.someJSON,
});

Chrome tells me:
main.js:142 POST https://www.jsonstore.io/XXXXXXXXXXXXX/t net::ERR_ABORTED 400 (Bad Request)

How do I prevent the CORS issue?

Edit: Seems like I just didn't do JSON.stringify() for the data. Issue resolved.


Is it possible to add transaction/invoice/reference id or something?

If we can change the nominal and tax, is it possible to add other parameters as transaction reference? Ex: IDxxxxx or INVxxxxx

Waiting for this problem too


Create gitter chat

I think it would be nice to have a gitter channel for this repo, so that we can discuss ideas and progress in a public way. I don't think I have the permissions to do this, however. altair-viz is not coming up as an organization I can create gitter rooms for. @ellisonbg what do you think about creating this room?

Saul, great idea! @jakevdp - what do you think about an altair_viz gitter
channel? I am in favor of this at the org level. We will have to look into
the needed permissions in the GitHub settings.
On Fri, Mar 2, 2018 at 12:34 PM, Saul Shanabrook<EMAIL_ADDRESS>wrote:

I think it would be nice to have a gitter channel for this repo, so that
we can discuss ideas and progress in a public way. I don't think I have the
permissions to do this, however. altair-viz is not coming up as an
organization I can create gitter rooms for. @ellisonbg
https://github.com/ellisonbg what do you think about creating this room?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/altair-viz/jupyterlab_voyager/issues/31, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AABr0DMBKAVq0vpKhM40BlTB0ZYtaJhoks5taazFgaJpZM4Sadhp
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

Why not using our vega slack?

(That's also open to public too)

@kanitw I forgot that existed! I am able to get in, but when I open in an incognito tab, it wants a login. I don't think you can have a public slack, right? Has to invite only? I could be wrong though.

We opened our slack channel to everyone. Join it here: https://communityinviter.com/apps/vega-js/join


[bazel] Solve non-hermeticity affecting e2e FPGA tests

In #16828, I saw an FPGA test that reliably failed at a particular commit on my workstation. When I ran bazel clean --expunge and tried again, it passed.
I don't have any real leads, but I think it's worth doing the following:

[ ] Investigate reproducibility of Pip dependencies. I think we're not checking their SHA256 sums. If someone pushes a different release with the same version number to Pip, that could make our build non-hermetic.
[ ] I think it's worth seeing what --experimental_workspace_rules_log_file turns up, per https://bazel.build/remote/workspace#nonhermetic-rules.

I've personally seen a couple issues that aren't reproducible when bisecting, but are when I add bazel clean --expunge

Here's a thought. In #16828, the FPGA test reliably failed locally, but passed on CI. The Verilated test passed locally. When I ran bazel clean --expunge, the FPGA test was somehow fixed. I think that the non-hermetic target should be somewhere in the set difference of the two targets' dependencies.
./bazelisk.sh cquery 'deps(//sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom) - deps(//sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_sim_verilator)

Here's a gist containing the results of the  query above. In graph form:

Since expunging caused the test to start passing, we can probably rule out causes outside of the Bazel sandbox.

It's probably not an untracked dependency of the FPGA test. When I ran bazel clean --expunge, I immediately re-ran the FPGA test and it didn't complain about missing files.

The FPGA test passed on CI, and I should have been using the exact same bitstream, so we can rule out nonhermeticity from Vivado. Thus, we can ignore anything in @bitstreams//....

The FPGA test's bitstream is //hw/bitstream:rom_otp_rma, which is the test ROM spliced with the local ROM, spliced with the RMA OTP image. Since this splicing happens every time we run the test on CI, and we don't see this test being flaky, I think we can rule out nonhermeticity from bitstream splicing.

After those exclusions, nothing else really jumps out at me. Perhaps we should widen our search to include Bazel itself.
The Bazel docs say that bazel clean --expunge does the following:

Resets internal caches.
Deletes entire output base tree, thus it deletes all Bazel temp files.
Stops the Bazel server after the clean, equivalent to the shutdown command.

Given that I have build --disk_cache=~/bazel_cache in ~/.bazelrc, I think that deleting the output base tree is irrelevant (right?). The same inputs should produce the same outputs. This makes me wonder whether bazel shutdown would have done the trick — if so, perhaps we should be looking for a known Bazel issue.
[/braindump]

FWIW both issues for which I've seen this behavior point to da28430b27aa27f33a3e11ade1cf2132d2a03d68 │ [flash_ctrl] Fix hardware info page attribute when I bisect them.

Does vivado escape the sandbox when we splice? Could we be getting stale results from bitstream splices somehow?

I seem to have reproduced the same failure by rerunning the bisect command:
./bazelisk.sh run //util/fpga:bitstream_bisect -- --good 6ac6849fb852d7f171f225e0350dd222cc08a12d --bad 5d721011d1fe9a49b93d52c5ce93f8e364ec566d --fast-command './bazelisk.sh test --test_output=streamed //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom'

# Now the test fails.
./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom

du $(./bazelisk.sh outquery //hw/bitstream:rom_otp_rma)
# 15508   bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.bit

./bazelisk.sh shutdown

# Now the test passes.
./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom

Detailed logs
./bazelisk.sh run //util/fpga:bitstream_bisect -- --good 6ac6849fb852d7f171f225e0350dd222cc08a12d --bad 5d721011d1fe9a49b93d52c5ce93f8e364ec566d --fast-command './bazelisk.sh test --test_output=streamed //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom'

> ./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom
INFO: Invocation ID: ee64c245-ce79-433e-9501-8cc7340b0b33
WARNING: Streamed test output requested. All tests will be run locally, without sharding, one at a time
INFO: Analyzed target //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom (8 packages loaded, 524 targets configured).
INFO: Found 1 test target...
INFO: From GenVivadoImage hw/bitstream/gcp_spliced_rom.update.mem:
2022-12-14 13:01:03,530 [gen_vivado_mem_image.py] Generating updatemem-compatible MEM file for ROM.
INFO: From SpliceBitstream hw/bitstream/gcp_spliced_rom.spliced.bit:

****** updatemem v2020.2 (64-bit)
  **** SW Build 3064766 on Wed Nov 18 09:12:47 MST 2020
  **** IP Build 3064653 on Wed Nov 18 14:17:31 MST 2020
    ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

source /tools/Xilinx/Vivado/2020.2/scripts/updatemem/main.tcl -notrace
Command: update_mem -meminfo external/bitstreams/cache/95d6f38846095f01bfcfe37f28e0afe50e5c98da/rom.mmi -data bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.update.mem -proc dummy -bit bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.tmpsrc.bit -out bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.spliced.bit -force
Loading bitfile bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.tmpsrc.bit
Loading data files...
Updating memory content...
Creating bitstream...
Writing bitstream bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.spliced.bit...
0 Infos, 0 Warnings, 0 Critical Warnings and 0 Errors encountered.
update_mem completed successfully
update_mem: Time (s): cpu = 00:00:22 ; elapsed = 00:00:22 . Memory (MB): peak = 1773.797 ; gain = 631.984 ; free physical = 9803 ; free virtual = 447217
INFO: [Common 17-206] Exiting updatemem at Wed Dec 14 13:52:18 2022...
INFO: From GenVivadoImage hw/bitstream/gcp_spliced_rom_otp_rma.update.mem:
2022-12-14 13:17:45,760 [gen_vivado_mem_image.py] Generating updatemem-compatible MEM file for OTP image.
INFO: From UpdateUsrAccessValue hw/bitstream/gcp_spliced_rom.bit:
[2022-12-15T16:29:59Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0x6e2c3130
[2022-12-15T16:29:59Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0x0
[2022-12-15T16:29:59Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf23f68 with NOOP
[2022-12-15T16:29:59Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf24140 with NOOP
[2022-12-15T16:29:59Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0x0
[2022-12-15T16:29:59Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0x9aac87d3
[2022-12-15T16:29:59Z INFO  opentitantool] Command result: success.
INFO: From SpliceBitstream hw/bitstream/gcp_spliced_rom_otp_rma.spliced.bit:

****** updatemem v2020.2 (64-bit)
  **** SW Build 3064766 on Wed Nov 18 09:12:47 MST 2020
  **** IP Build 3064653 on Wed Nov 18 14:17:31 MST 2020
    ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

source /tools/Xilinx/Vivado/2020.2/scripts/updatemem/main.tcl -notrace
Command: update_mem -meminfo external/bitstreams/cache/95d6f38846095f01bfcfe37f28e0afe50e5c98da/otp.mmi -data bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.update.mem -proc dummy -bit bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.tmpsrc.bit -out bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.spliced.bit -force
Loading bitfile bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.tmpsrc.bit
Loading data files...
Updating memory content...
Creating bitstream...
Writing bitstream bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.spliced.bit...
0 Infos, 0 Warnings, 0 Critical Warnings and 0 Errors encountered.
update_mem completed successfully
update_mem: Time (s): cpu = 00:00:12 ; elapsed = 00:00:12 . Memory (MB): peak = 1725.801 ; gain = 567.984 ; free physical = 9978 ; free virtual = 447423
INFO: [Common 17-206] Exiting updatemem at Wed Dec 14 13:52:32 2022...
INFO: From UpdateUsrAccessValue hw/bitstream/gcp_spliced_rom_otp_rma.bit:
[2022-12-15T16:30:00Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0x9aac87d3
[2022-12-15T16:30:00Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0x0
[2022-12-15T16:30:00Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf23f68 with NOOP
[2022-12-15T16:30:00Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf24140 with NOOP
[2022-12-15T16:30:00Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0x0
[2022-12-15T16:30:00Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0xfce11998
[2022-12-15T16:30:00Z INFO  opentitantool] Command result: success.
Invoking test: sw/host/opentitantool/opentitantool --rcfile= --logging=info --interface=cw310 --exec=fpga load-bitstream --rom-kind=rom hw/bitstream/gcp_spliced_rom_otp_rma.bit --exec=bootstrap --clear-uart=true sw/device/silicon_creator/rom/e2e/epmp_init_otp_rma_prog_fpga_cw310.fake_test_key_0.signed.bin --exec=console --exit-success='PASS.*\n' --exit-failure='((FAIL|FAULT).*\n)|(BFV:[0-9a-f]{8})' no-op
[2022-12-15T16:30:00Z INFO  opentitantool::command::load_bitstream] Loading bitstream: "hw/bitstream/gcp_spliced_rom_otp_rma.bit"
[2022-12-15T16:30:00Z INFO  opentitanlib::util::usr_access] Bitstream file USR_ACCESS value: 0xfce11998
[2022-12-15T16:30:00Z INFO  opentitanlib::util::rom_detect] Current bitstream: "ROM:f32bad4b\r"
[2022-12-15T16:30:00Z INFO  opentitanlib::transport::cw310] Programming the FPGA bitstream.
[2022-12-15T16:30:14Z INFO  opentitantool] Command result: success.
[2022-12-15T16:30:14Z INFO  opentitanlib::bootstrap] Asserting bootstrap pins...
[2022-12-15T16:30:14Z INFO  opentitanlib::app] Asserting the reset signal
[2022-12-15T16:30:14Z INFO  opentitanlib::app] Clearing the UART RX buffer
[2022-12-15T16:30:14Z INFO  opentitanlib::app] Deasserting the reset signal
[2022-12-15T16:30:14Z INFO  opentitanlib::bootstrap] Performing bootstrap...
-- Test timed out at 2022-12-15 16:31:00 UTC --

TIMEOUT: //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom (Summary)
      /usr/local/google/home/dmcardle/.cache/bazel/_bazel_dmcardle/b18e2f72ed2b1e66484b488e136c72a5/execroot/lowrisc_opentitan/bazel-out/k8-fastbuild/testlogs/sw/device/silicon_creator/rom/e2e/epmp_init_otp_rma_fpga_cw310_rom/test.log

To make sure the failure is "sticky", I tried again (this time I didn't wait the full 60 seconds).
> ./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom
INFO: Invocation ID: b3565bbd-2311-4fa3-bf77-ecba9467a04b
WARNING: Streamed test output requested. All tests will be run locally, without sharding, one at a time
INFO: Analyzed target //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
Invoking test: sw/host/opentitantool/opentitantool --rcfile= --logging=info --interface=cw310 --exec=fpga load-bitstream --rom-kind=rom hw/bitstream/gcp_spliced_rom_otp_rma.bit --exec=bootstrap --clear-uart=true sw/device/silicon_creator/rom/e2e/epmp_init_otp_rma_prog_fpga_cw310.fake_test_key_0.signed.bin --exec=console --exit-success='PASS.*\n' --exit-failure='((FAIL|FAULT).*\n)|(BFV:[0-9a-f]{8})' no-op
[2022-12-15T16:31:08Z INFO  opentitantool::command::load_bitstream] Loading bitstream: "hw/bitstream/gcp_spliced_rom_otp_rma.bit"
[2022-12-15T16:31:08Z INFO  opentitanlib::util::usr_access] Bitstream file USR_ACCESS value: 0xfce11998
[2022-12-15T16:31:08Z INFO  opentitanlib::util::rom_detect] Current bitstream: "ROM:fce11998\r"
[2022-12-15T16:31:08Z INFO  opentitanlib::transport::cw310] Already running the correct bitstream.  Skip loading bitstream.
[2022-12-15T16:31:08Z INFO  opentitantool] Command result: success.
[2022-12-15T16:31:08Z INFO  opentitanlib::bootstrap] Asserting bootstrap pins...
[2022-12-15T16:31:08Z INFO  opentitanlib::app] Asserting the reset signal
[2022-12-15T16:31:08Z INFO  opentitanlib::app] Clearing the UART RX buffer
[2022-12-15T16:31:08Z INFO  opentitanlib::app] Deasserting the reset signal
[2022-12-15T16:31:08Z INFO  opentitanlib::bootstrap] Performing bootstrap...
[16 / 17] Testing //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom; 19s local
^C
Bazel caught interrupt signal; shutting down.

Bazel caught interrupt signal; shutting down.
Aspect @rules_rust//rust/private:clippy.bzl%rust_clippy_aspect of //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom up-to-date (nothing to build)
ERROR: build interrupted
INFO: Elapsed time: 20.311s, Critical Path: 19.92s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully
//sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom  NO STATUS

I ran ./bazelisk.sh shutdown and ran the test again, which passed.
> ./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom
Starting local Bazel server and connecting to it...
INFO: Invocation ID: cceaaa71-bc6d-4e2e-93cd-5f67aace75d6
WARNING: Streamed test output requested. All tests will be run locally, without sharding, one at a time
WARNING:root:Closest bitstream to HEAD is 5d721011d1fe9a49b93d52c5ce93f8e364ec566d.
INFO: Analyzed target //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom (378 packages loaded, 14501 targets configured).
INFO: Found 1 test target...
INFO: From SpliceBitstream hw/bitstream/gcp_spliced_rom.spliced.bit:

****** updatemem v2020.2 (64-bit)
  **** SW Build 3064766 on Wed Nov 18 09:12:47 MST 2020
  **** IP Build 3064653 on Wed Nov 18 14:17:31 MST 2020
    ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

source /tools/Xilinx/Vivado/2020.2/scripts/updatemem/main.tcl -notrace
Command: update_mem -meminfo external/bitstreams/cache/5d721011d1fe9a49b93d52c5ce93f8e364ec566d/rom.mmi -data bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.update.mem -proc dummy -bit bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.tmpsrc.bit -out bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.spliced.bit -force
Loading bitfile bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.tmpsrc.bit
Loading data files...
Updating memory content...
Creating bitstream...
Writing bitstream bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.spliced.bit...
0 Infos, 0 Warnings, 0 Critical Warnings and 0 Errors encountered.
update_mem completed successfully
update_mem: Time (s): cpu = 00:00:29 ; elapsed = 00:00:31 . Memory (MB): peak = 1725.801 ; gain = 567.984 ; free physical = 16980 ; free virtual = 439262
INFO: [Common 17-206] Exiting updatemem at Wed Dec 14 14:51:52 2022...
INFO: From UpdateUsrAccessValue hw/bitstream/gcp_spliced_rom.bit:
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0x762d139d
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0x0
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf23f68 with NOOP
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf24140 with NOOP
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0x0
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0xf0216dd1
[2022-12-15T16:31:50Z INFO  opentitantool] Command result: success.
INFO: From SpliceBitstream hw/bitstream/gcp_spliced_rom_otp_rma.spliced.bit:

****** updatemem v2020.2 (64-bit)
  **** SW Build 3064766 on Wed Nov 18 09:12:47 MST 2020
  **** IP Build 3064653 on Wed Nov 18 14:17:31 MST 2020
    ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

source /tools/Xilinx/Vivado/2020.2/scripts/updatemem/main.tcl -notrace
Command: update_mem -meminfo external/bitstreams/cache/5d721011d1fe9a49b93d52c5ce93f8e364ec566d/otp.mmi -data bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.update.mem -proc dummy -bit bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.tmpsrc.bit -out bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.spliced.bit -force
Loading bitfile bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.tmpsrc.bit
Loading data files...
Updating memory content...
Creating bitstream...
Writing bitstream bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom_otp_rma.spliced.bit...
0 Infos, 0 Warnings, 0 Critical Warnings and 0 Errors encountered.
update_mem completed successfully
update_mem: Time (s): cpu = 00:00:12 ; elapsed = 00:00:12 . Memory (MB): peak = 1725.801 ; gain = 567.984 ; free physical = 18623 ; free virtual = 441233
INFO: [Common 17-206] Exiting updatemem at Wed Dec 14 14:52:06 2022...
INFO: From UpdateUsrAccessValue hw/bitstream/gcp_spliced_rom_otp_rma.bit:
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0xf0216dd1
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0x0
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf23f68 with NOOP
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Replaced WRITE_CRC_REG command at 0xf24140 with NOOP
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file old USR_ACCESS value: 0x0
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file new USR_ACCESS value: 0x651137d1
[2022-12-15T16:31:50Z INFO  opentitantool] Command result: success.
Invoking test: sw/host/opentitantool/opentitantool --rcfile= --logging=info --interface=cw310 --exec=fpga load-bitstream --rom-kind=rom hw/bitstream/gcp_spliced_rom_otp_rma.bit --exec=bootstrap --clear-uart=true sw/device/silicon_creator/rom/e2e/epmp_init_otp_rma_prog_fpga_cw310.fake_test_key_0.signed.bin --exec=console --exit-success='PASS.*\n' --exit-failure='((FAIL|FAULT).*\n)|(BFV:[0-9a-f]{8})' no-op
[2022-12-15T16:31:50Z INFO  opentitantool::command::load_bitstream] Loading bitstream: "hw/bitstream/gcp_spliced_rom_otp_rma.bit"
[2022-12-15T16:31:50Z INFO  opentitanlib::util::usr_access] Bitstream file USR_ACCESS value: 0x651137d1
[2022-12-15T16:31:50Z INFO  opentitanlib::util::rom_detect] Current bitstream: "ROM:fce11998\r"
[2022-12-15T16:31:50Z INFO  opentitanlib::transport::cw310] Programming the FPGA bitstream.
[2022-12-15T16:32:04Z INFO  opentitantool] Command result: success.
[2022-12-15T16:32:04Z INFO  opentitanlib::bootstrap] Asserting bootstrap pins...
[2022-12-15T16:32:04Z INFO  opentitanlib::app] Asserting the reset signal
[2022-12-15T16:32:04Z INFO  opentitanlib::app] Clearing the UART RX buffer
[2022-12-15T16:32:04Z INFO  opentitanlib::app] Deasserting the reset signal
[2022-12-15T16:32:04Z INFO  opentitanlib::bootstrap] Performing bootstrap...
[2022-12-15T16:32:06Z INFO  opentitanlib::bootstrap] Releasing bootstrap pins...
[2022-12-15T16:32:06Z INFO  opentitanlib::app] Asserting the reset signal
[2022-12-15T16:32:06Z INFO  opentitanlib::app] Deasserting the reset signal
[2022-12-15T16:32:06Z INFO  opentitantool] Command result: success.
Starting interactive console
[CTRL+C] to exit.

[2022-12-15T16:32:06Z INFO  opentitanlib::io::uart] set_flow_control to false
ROM:651137d1
bootstrap:1
ROM:651137d1
I00000 ottf_main.c:126] Running sw/device/silicon_creator/rom/e2e/epmp_init_test.c
I00001 epmp_init_test.c:29] debug_enabled: 1
I00002 epmp_init_test.c:42] pmpaddr13=0x000041ff, pmpcfg3=0x9b909f00, pmp13cfg=0x9f
I00003 ottf_main.c:100] Finished sw/device/silicon_creator/rom/e2e/epmp_init_test.c
I00004 status.c:28] PASS!

Exiting interactive console.
[2022-12-15T16:32:07Z INFO  opentitantool::command::console] ExitSuccess("PASS!\r\n")
[2022-12-15T16:32:07Z INFO  opentitantool] Command result: success.
[2022-12-15T16:32:07Z INFO  opentitantool] Command result: success.
Aspect @rules_rust//rust/private:clippy.bzl%rust_clippy_aspect of //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom up-to-date (nothing to build)
INFO: Elapsed time: 22.489s, Critical Path: 17.68s
INFO: 8 processes: 2 disk cache hit, 2 internal, 2 linux-sandbox, 2 local.
INFO: Build completed successfully, 8 total actions
//sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom     PASSED in 17.0s

Command: update_mem -meminfo external/bitstreams/cache/95d6f38846095f01bfcfe37f28e0afe50e5c98da/rom.mmi -data bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.update.mem -proc dummy -bit bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.tmpsrc.bit -out bazel-out/k8-fastbuild/bin/hw/bitstream/gcp_spliced_rom.spliced.bit -force
is splicing the bitstream with a stale rom.mmi file (I think the bitstream might also be from the wrong commit, but it's not printed here)

I suspect the entire @bitstreams workspace is stale, so the BUILD file generated by [bitstreams_workspace.py] points to the wrong files in the bitstreams cache directory.
I think we need to dig into "When is the implementation function executed?" in the Bazel docs.

There aren't a lot of inputs that can cause the bitstreams_repo repository rule to trigger.
When jumping around the repo history during bisection, you'll likely want to change the BITSTREAM environment variable for each commit landing. In other words, after reaching a new commit, set BITSTREAM=<git-hash> while performing bazel operations for that commit.

There aren't a lot of inputs that can cause the bitstreams_repo repository rule to trigger.
When jumping around the repo history during bisection, you'll likely want to change the BITSTREAM environment variable for each commit landing. In other words, after reaching a new commit, set BITSTREAM=<git-hash> while performing bazel operations for that commit.

This doesn't trigger the re-evaluation of the bitstream cache and solve the issue.

There aren't a lot of inputs that can cause the bitstreams_repo repository rule to trigger.
When jumping around the repo history during bisection, you'll likely want to change the BITSTREAM environment variable for each commit landing. In other words, after reaching a new commit, set BITSTREAM=<git-hash> while performing bazel operations for that commit.

BITSTREAM=$(git rev-parse HEAD) ./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom This doesn't trigger the re-evaluation of the bitstream cache and solve the issue.

It should trigger a re-evaluation of the bitstream cache, but no guarantees on fixing the bug. If you're not seeing that, something is broken. I note that it certainly does for me.
Relevant output of BITSTREAM=HEAD ./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom
WARNING:root:Closest bitstream to HEAD is 8255b4be17814a0f90c8bafeaba0a522d1f83bdf.

Relevant output of BITSTREAM=$(git rev-parse HEAD) ./bazelisk.sh test --test_output=streamed --cache_test_results=no //sw/device/silicon_creator/rom/e2e:epmp_init_otp_rma_fpga_cw310_rom (done right afterwards):
WARNING:root:Closest bitstream to bca14594ea223e9c5432cc85f16886df3e863cee is 8255b4be17814a0f90c8bafeaba0a522d1f83bdf.

Yeah, I think I was looking at a commit that was missing from the bitstream cache.

I propose that we have bazelisk.sh execute git rev-parse HEAD. It either writes the result to //:scm_revision.txt or puts it in an environment variable: GIT_HEAD. We would make the bitstreams repo depend on //:scm_revision.txt or add GIT_HEAD to environ.
I considered adding a genrule that runs git rev-parse HEAD, but I think that suffers from the same problem — how do we re-run the command whenever we checkout a new commit?

We talked offline about using --workspace_status to add HEAD to a stamped file, and depending on that file such that this happens under the hood.
BITSTREAM=$(git rev-parse HEAD) is going to be useful to bisect into the portion of the commit history we currently occupy