added new ontology version 2.0

Changed Datatype Properties to Object Properties with range skos:Concept
hasAccessRestriction
hasCategory
hasLanguage
hasLicense
hasLifeCycleStatus
hasRelatedDiscipline
hasOAISet
Changed cardinality restrictions for automatically filled properties (for the corresponding domain):
hasAccessRestrictionSummary 0-1
hasLicenseSummary 0-1
hasHosting --> removed
hasAvailableDate 0-1
hasNumberofItems 0-1
hasBinarySize 0-1
hasFormat 0-1
hasAccessRestriction for Collection to 0-1
AND changed cardinality for:
hasLicense for Collection to 0-1
Removed cardinalities from resource for:
hasCompleteness
hasNumberOfItems
Extended definitions for
hasAvailableDate
hasCreator
hasLifeCycleStatus
automated fill, default value, vocabs
Removed inverse properties
is actor of
is author of
is contact of
is contributor of
is coverage of
is creator of
is curator of
is depositor of
is editor of
is funder of
is hosting of
is licensor of
is digitising agent of
is metadata creator of
is owner of
is principal investigator of
is rights holder of
is spatial coverage of
has member
has part
is source of
has title image
has metadata
is documented by
is continued by
is derived publication of
is previous version of
Introduced annotation "inverse" indicating the inverse property input option.
Introduced hasIssuedDate for Publication.
Extended domain of hasTableOfContents to Resources.
Extended domain of hasAvailableDate and hasAccessRestriction to owl:Thing.
Removed hasLandingPage from the ontology.
Added automatedfill annotation to hasLocationPath.
Added German translations to class descriptions.
Minor fixes.

I'm afraid we will need to refine it quite a lot:

We definitely want acdh:hasIdentifier to be an object property (otherwise we will be effectively unable to import any data into the repository once the doorkeeper is more strict about checking values match property definitions and such doorkeeper version is ready to release) but this means:

it can't be owl:equivalent to dc:identifier and acdh:hasPid
acdh:hasPid, acdh:hasNonLinkedIdentifier and acdh:hasTemporalCoverageIdentifier

As acdh:hasAccessRestriction, acdh:hasTitle, acdh:hasIdentifier and acdh:hasBinarySize are in practice used for all repository resources (even when they don't have any ACDH class), I would move corresponding restrictions to owl:Thing (as every class inherits from owl:Thing it will mean these restrictions should be applied to all repository resources). Which will by the reduce the number of restriction rules significantly.
acdh:hasAccessRestriction and acdh:hasIdentifier are not automatically managed (an automatically managed property is the one managed exclusively by the repository/doorkeeper).
I would drop all cardinality rules from automatically managed properties because they are useless both for people preparing metadata and the doorkeeper.

Anyway please don't do anything yet. I now need to perform tests against the arche-schema-ingest, arche-lib-schema, arche-doorkeeper and, last but not least, a sample ingestion and it will take a few days.
It means that if we want to try out any ingestions now, we should republish ontology v1.8 as v1.10 and stick to it until we are ready with v2.0 (as with v1.9 the doorkeeper refuses all ingestions).

Phew... that is quite something.
Quick note: acdh:hasBinarySize can only be used for Resource, Metadata, Image and Collection. The other classes all do not contain payload
Please proceed with v 1.8 and we'll fix open issues for 2.0 until mid/end of August

Kiki was working on the translations of the definitions, so we can then include this also.
I am gathering all the remarks here:
https://docs.google.com/document/d/1d9S8paxV2gw2dCLqNXMIHEvcfnb4MWeGe5d6ptVxOsA/edit

My latest commit contains big bunch of changes:

acdh:hasIdentifier made an ObjectProperty which is a must for technical reasons and matches our previous habits (in the data we have always provided it as an URI and never as a string).

Introduced a helper DatatypeProperty class acdh:hasLiteralIdentifier as a common parent for acdh:hasNonLinkedIdentifier, acdh:hasPid and acdh:hasTemporalCoverageIdentifier. The acdh:hasLiteralIdentifier is marked as equivalent to dc:identifier (acdh:hasIdentifier can't be because of DatatypeProperty/ObjectProperty type mismatch with dc:identifier).

Dropped acdh:recommended from all properties marked with acdh:automatedFill (I see acdh:recommended as an indication for the metadata provided/curator and automatically managed properties should not be provided by them; on the other hand the doorkeeper doesn't process acdh:recommended).
Changed domains for all properties which are set/required by ARCHE for all repository resources (no matter their ACDH class) to owl:Thing to reflect the actual repository behaviour (which we want to keep). This applies to acdh:hasUpdatedDate, acdh:hasTitle, acdh:hasIdentifier and acdh:hasAccessRestriction.

In the case of acdh:hasAccessRestriction it's for pragmatic reasons. Experience tells us there is no benefit from resources which can't be accessed and they only make Kiki and Seta report errors (which are not really errors). And the easiest way to assure "everything which is not explicitely restricted is publicly readable" is to assign the default acdh:hasAccessRestriction to owl:Thing.

Removed acdh:automatedFill marking from acdh:hasAccessRestriction and acdh:hasIdentifier as acdh:automatedFill is reserved for properties solely managed by the ARCHE-core and/or the doorkeeper (and both acdh:hasAccessRestriction and acdh:hasIdentifier may come or even must come from the user).
Removed acdh:automatedFill from acdh:hasPid as acdh:hasPid is not solely managed by the doorkeeper. The doorkeeper provides only a PID minting automation but this automation has to be triggered by the user (by providing a proper - empty string - property value) and the user can provide the acdh:hasPid value by hand (which is not possible for acdh:automatedFill).
Cardinality rules removed from properties marked with acdh:automatedFill. Cardinality rules are for metadata creators/curators and they don't care about properties which are solely managed by the ARCHE-core/doorkeeper.
Assured all acdh:recommended annotations have URI values.
Marked acdh:hasUpdatedDate with acdh:automatedFill.
Changed acdh:hasUpdatedDate range to xsd:dateTime (from xsd:date).
Added properties being used by the ARCHE but not mentioned in the ontology (acdh:hasBinaryUpdatedDate, acdh:rawBinarySize, acdh:hasUpdatedRole, achd:hasBinaryUpdatedRole, acdh:createdBy, acdh:aclRead, acdh:aclUpdate, acdh:aclWrite as well as properties used to describe dissemination services).
Removed all cardinality restrictions on properties marked with acdh:automatedFill (as both metadata creators/curators and the doorkeeper don't care about them and if a property is acdh:automatedFill, then we know it will be present).

I will now run tests of all repository components (arche-core, doorkeeper, test ingestions) and tune it as needed until all tests pass. Then there will be time for discussion and applying non-breaking changes (like updating translations). Then I will check if existing metadata don't require updates after the change and prepare migration scripts if needed. Only after that we will be ready to ship the new release.

[x] check that arche-doorkeeper tests pass
[x] check that arche-lib-ingest tests pass
[ ] check that arche-lib-schema tests pass

ARCHE software stack tests don't complain about the current version of the ontology, so we may continue to step 2.
@bellerophons-pegasus, @sstuhec (maybe also @vronk), could you please go trough the current version (after all my changes) and tell if there is something you disagree with?
If we have any translation updates, it's also a good time to make them.

List of discussion points

I think we can remove the class acdh:Concept, because we are using skos:Concept
We should remove all owl:equivalent and add them from scratch, to ensure consistency; maybe even discard some equivalencies?
We need a description and stuff for acdh:hasLiteralIdentifier
add annotation default value to acdh:hasAccessRestriction

I would drop all cardinality rules from automatically managed properties because they are useless both for people preparing metadata and the doorkeeper.

-> I am against it, because in the roottable view we would like to properly display which properties are are must and should be present, regardless if being managed automatically or not
Regarding the use of owl:Thing for acdh:hasAccessRestriction, acdh:hasTitle, acdh:hasIdentifier and acdh:hasUpdatedDate:

does acdh:hasAccessRestriction refers to access to binary content or pure metadata?
make sure that owl:Thing is the right one, i.e. does not interfere with e.g. skos:Concept; alternative would be acdh:Main

(will extend this after break)

I would drop all cardinality rules from automatically managed properties because they are useless both for people preparing metadata and the doorkeeper.

I am against it, because in the roottable view we would like to properly display which properties are are must and should be present, regardless if being managed automatically or not

But it would make it more difficult for metadata creators and curators to distinguish which properties they must provide and which they don't. And I guess they are the main target group for the root table.

does acdh:hasAccessRestriction refers to access to binary content or pure metadata?

Currently to both because currently the arche-core is set up to enforce access rules also on the metadata. Anyway we can easily relax it (make metadata always readable) with a single change of the arche-core config setting (here)
The owl:Thing is "the broadest possible domain". From the software stack implementation perspective it covers every resource existing in the repository (which is not a case for any other class like skos:Concepts or acdh:Main).

I would drop all cardinality rules from automatically managed properties because they are useless both for people preparing metadata and the doorkeeper.

I am against it, because in the roottable view we would like to properly display which properties are are must and should be present, regardless if being managed automatically or not

But it would make it more difficult for metadata creators and curators to distinguish which properties they must provide and which they don't. And I guess they are the main target group for the root table.

If the root table will show automatically filled/default value then the cardinalities could stay, so that they are documented somewhere and at the same time we do not get confused, because the info about what is automatically filled is anyhow also there. Could this be a compromise ;-)?

does acdh:hasAccessRestriction refers to access to binary content or pure metadata?

Currently to both because currently the arche-core is set up to enforce access rules also on the metadata. Anyway we can easily relax it (make metadata always readable) with a single change of the arche-core config setting (here)

As we write on our website all metadata are public and readable. I understand this information is necessary for technical reasons (I think we once discussed that there were some errors that were then solved like this), but I would at least remove the hasAccessRestriction from display from the non-binary items. Because for us/users this only applies to the binaries.
Other:

hasBinarySize should have domain Binary Content + Collection only
I have already commited the German translation changes done by Kiki. So, from my side only the missing one that Martina mentioned (the literalID) should be added. And if someone else has anything to change.

Further discussion points

should we introduce a class Technical?
should we introduce a class DisseminationService?
We should check if any of those properties we are discarding are currently in use and adjust that before the switch

should we introduce a class DisseminationService?

Yes, because we are already depending on it (dissemination services won't work without it)

should we introduce a class Technical?

No opinion on that, I created it just to keep technical stuff clearly separated from the others but I'm not attached to it.

hasBinarySize should have domain Binary Content + Collection only

Ok, just please make a dedicated helper class for it (it there is nothing like that already).

If the root table will show automatically filled/default value then the cardinalities could stay, so that they are documented somewhere and at the same time we do not get confused, because the info about what is automatically filled is anyhow also there. Could this be a compromise ;-)?

I can live with that although the fact the property is marked as "automatedFill" is an equivalent of saying "it has owl:cardinality 1" and stating it twice in different places is only asking for inconsistencies.

Properties in the ACDH namespace not defined in the ontology but present in the metadata on apollo:

https://vocabs.acdh.oeaw.ac.at/schema#hasPublicationDate - https://arche.acdh.oeaw.ac.at/browser/oeaw_detail/33731
https://vocabs.acdh.oeaw.ac.at/schema#hasLocationUrl 9 occurences, e.g. https://id.acdh.oeaw.ac.at/ODeeg/Collections/AT-Vienna-KHM/KHM-ANSA-IV3875
https://vocabs.acdh.oeaw.ac.at/schema#isReferencedBy 12 occurences. It's mentioned in the schema comments as a removed property. Should we just remove it from the database or convert it to something else?
https://vocabs.acdh.oeaw.ac.at/schema#hasCustomXSL this is a property introduced by @csae8092 for his dissemination service. Should we add it to the ontology as a subproperty of acdh:technical? Having all properties we use in the ontology would allow us to to introduce a doorkeeper check denying usage of any unknown property in the ACDH namespace (feature requested by Seta some time ago) and preventing us from ingesting e.g. typos in property URIs.

Statistics for properties missing for already existing resources by resource class:
Missing property statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Collection
	https://vocabs.acdh.oeaw.ac.at/schema#hasOwner 1093 (40.1%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 1093 (40.1%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor 1093 (40.1%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasContact 1089 (39.9%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor 1093 (40.1%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder 1093 (40.1%)
Missing property statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Image
	https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 4 (44.4%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasCategory 4 (44.4%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor 4 (44.4%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasLicense 3 (33.3%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor 4 (44.4%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasOwner 2 (22.2%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder 2 (22.2%)
Missing property statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Metadata
	https://vocabs.acdh.oeaw.ac.at/schema#hasOwner 33 (100.0%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 33 (100.0%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasCategory 33 (100.0%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor 33 (100.0%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasLicense 33 (100.0%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor 33 (100.0%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder 33 (100.0%)
Missing property statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Project
	https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 4 (57.1%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasContact 3 (42.9%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasSubject 4 (57.1%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasRelatedDiscipline 4 (57.1%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasRelatedCollection 2 (28.6%)
Missing property statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Resource
	https://vocabs.acdh.oeaw.ac.at/schema#hasAcceptedDate 24405 (100.0%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasOwner 18232 (74.7%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 18225 (74.7%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor 18175 (74.5%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasLicense 14940 (61.2%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor 18232 (74.7%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder 18232 (74.7%)
	https://vocabs.acdh.oeaw.ac.at/schema#hasCategory 3021 (12.4%)

Please let me know if any of them can be generated automatically.

And one more check - property uses where property domain doesn't match resource class:

acdh:hasLifeCycleStatus with domain acdh:Container:

acdh:Resource class - 1739 occurrences

acdh:hasCollectedStartDate with domain acdh:Container

acdh:Resource class - 13 occurrences

acdh:hasCollectedEndDate with domain acdh:Container

acdh:Resource class - 13 occurrences

acdh:hasCompleteness with domain acdh:Collection

acdh:Resource class - 1730 occurrences

acdh:hasNumberOfItems with domain acdh:Collection - all occurrences listed below are to be deleted and the new doorkeeper version will compute acdh:hasNumberOfItems only for acdh:Collection

acdh:Resource class - 513 occurrences
acdh:Organisation class - 17 occurrences
acdh:Publication class - 10 occurrences
acdh:Person class - 19 occurrences
acdh:Place class - 3 occurrences
acdh:DisseminationService class - 16 occurrences
acdh:DisseminationServiceParameter class - 6 occurrences
acdh:Project class - 1 occurrence
acdh:Image class - 1 occurrence

acdh:hasAccessRestriction with domain acdh:BinaryContent - all occurrences listed below are to be deleted and the new doorkeeper will apply a default value of acdh:hasAccessRestriction only to acdh:BinaryContent

acdh:Person class - 357 occurrences
acdh:Place class - 194 occurrences
acdh:Organisation class - 42 occurrences
acdh:Publication class - 63 occurrences
acdh:Project class - 7 occurrences
acdh:DisseminationService class - 16 occurrences
acdh:DisseminationServiceParameter cla occurrencesss - 6

acdh:hasFormat with domain acdh:BinaryContent

acdh:Collection class - 255 occurrences

acdh:hasCategory with domain acdh:BinaryContent

acdh:Collection class - 1 occurrence

acdh:isTitleImageOf with domain acdh:Image

acdh:Resource class - 622 occurrences

acdh:isPartOf with domain acdh:CollectionOrPlaceOrPublicationOrReMe - I think we should extend the domain (or make acdh:Image and acdh:DisseminationServiceParameter inherit from one of classes already included in the domain)

acdh:Image class - 7 occurrences
acdh:DisseminationServiceParameter class - 6 occurrences

acdh:hasUrl with domain acdh:AgentOrContainerOrPublicationOrReMe

acdh:Image class - 2 occurrences

acdh:hasNonLinkedIdentifier with domain acdh:ContainerOrPublicationOrReMe

acdh:Image class - 1 occurrence

!!!

acdh:hasBinarySize with domain acdh:RepoObject - all occurrences listed below are to be deleted and the new doorkeeper will compute acdh:hasBinarySize only for acdh:RepoObject

acdh:Organisation class - 17 occurrences
acdh:Publication class - 10 occurrences
acdh:Person class - 19 occurrences
acdh:Place class - 3 occurrences
acdh:DisseminationService class - 16 occurrences
acdh:DisseminationServiceParameter class - 6 occurrences
acdh:Project class - 1 occurrence

acdh:hasHosting with domain acdh:RepoObject

acdh:Publication class - 59 occurrences
acdh:Project class - 1 occurrence

acdh:hasOwner with domain acdh:RepoObject

acdh:Project class - 1 occurrence

acdh:hasCreatedEndDate with domain acdh:RepoObject

acdh:Publication class - 1 occurrence

acdh:hasCreatedStartDate with domain acdh:RepoObject

acdh:Publication class - 1 occurrence

acdh:hasAlternativeTitle with domain acdh:ContainerOrReMeOrOrganisationOrPlaceOrPublication

acdh:Person class - 24 occurrences

acdh:hasPublisher with domain acdh:Publication

acdh:Resource class - 1 occurrence

acdh:isMetadataFor with domain acdh:Metadata

acdh:Resource class - 4 occurrences

acdh:hasDescription with domain acdh:Main - I would vote either for extending the domain or including acdh:DisseminationService in the acdh:Main

acdh:DisseminationService class - 16 occurrences

Ok. OWL should be done now.
Next thing would be to go through the checks again and fix those.
After that is done ontology v2 should be ready for release... unless I missed something?

Ok. OWL should be done now.
Next thing would be to go through the checks again and fix those.
After that is done ontology v2 should be ready for release... unless I missed something?

@bellerophons-pegasus (@vronk) we need one more property - acdh:hasMetadataPid. Which is already in use by the way because it was required for fulfilling CLARIN certification requirements.
The story is as follows. CLARIN requires CMDI records to have their very own PIDs but as CMDI in ARCHE is yet another metadata serialization and not a separate repository resource, we can't store such PIDs in an ordinary way (using acdh:hasPid). The solution we (me and Matej) introduced in December was to use another property acdh:hasMetadataPid which will store such CMDI PIDs and which will be automatically generated by the doorkeeper for resources in the clarin-vlo OAI-PMH set. Just this property should be also included in the ontology. I didn't add it by myself because there are pretty few decisions to be made (like ordering and, most importantly, a domain) which I'm not sure about. What is for sure is that it should be a DatatypeProperty.
I'll vote for including the property in ontology v2 so v2 covers all properties in the acdh namespace we are actually using.

And an updated report on discrepancies between the ontology and the actual data on apollo:

properties in the ACDH namespace out of ontology

https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataPid 169
https://vocabs.acdh.oeaw.ac.at/schema#hasPublicationDate 1
https://vocabs.acdh.oeaw.ac.at/schema#hasLocationUrl 9
https://vocabs.acdh.oeaw.ac.at/schema#isReferencedBy 12

Missing properties statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Collection

https://vocabs.acdh.oeaw.ac.at/schema#hasContact 1089 (34.8%)
https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 1093 (34.9%)
https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor 1093 (34.9%)
https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor 1093 (34.9%)
https://vocabs.acdh.oeaw.ac.at/schema#hasOwner 1093 (34.9%)
https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder 1093 (34.9%)
https://vocabs.acdh.oeaw.ac.at/schema#hasLicenseSummary 392 (12.5%)

Missing properties statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Metadata

https://vocabs.acdh.oeaw.ac.at/schema#hasLicense 33 (100.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasCategory 33 (100.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 33 (100.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor 33 (100.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor 33 (100.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasOwner 33 (100.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder 33 (100.0%)

Missing properties statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Project

https://vocabs.acdh.oeaw.ac.at/schema#hasContact 3 (33.3%)
https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 4 (44.4%)
https://vocabs.acdh.oeaw.ac.at/schema#hasRelatedDiscipline 4 (44.4%)
https://vocabs.acdh.oeaw.ac.at/schema#hasSubject 4 (44.4%)
https://vocabs.acdh.oeaw.ac.at/schema#hasRelatedCollection 2 (22.2%)

Missing properties statistics for class https://vocabs.acdh.oeaw.ac.at/schema#Resource

https://vocabs.acdh.oeaw.ac.at/schema#hasLicense 14940 (28.6%)
https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator 18225 (34.9%)
https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor 18175 (34.8%)
https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor 18232 (35.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasOwner 18232 (35.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder 18232 (35.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasCategory 3021 (5.8%)

Missing properties statistics for class https://vocabs.acdh.oeaw.ac.at/schema#TopCollection

https://vocabs.acdh.oeaw.ac.at/schema#hasHosting 1 (100.0%)
https://vocabs.acdh.oeaw.ac.at/schema#hasLicenseSummary 1 (100.0%)

Property https://vocabs.acdh.oeaw.ac.at/schema#hasLifeCycleStatus with domain https://vocabs.acdh.oeaw.ac.at/schema#Container is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 1739

Property https://vocabs.acdh.oeaw.ac.at/schema#hasCompleteness with domain https://vocabs.acdh.oeaw.ac.at/schema#Collection is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 1730

Property https://vocabs.acdh.oeaw.ac.at/schema#hasBinaryUpdatedDate with domain https://vocabs.acdh.oeaw.ac.at/schema#BinaryContent is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Collection 2721
https://vocabs.acdh.oeaw.ac.at/schema#Person 346
https://vocabs.acdh.oeaw.ac.at/schema#Place 192
https://vocabs.acdh.oeaw.ac.at/schema#Image 10
https://vocabs.acdh.oeaw.ac.at/schema#Organisation 30
https://vocabs.acdh.oeaw.ac.at/schema#Publication 62
https://vocabs.acdh.oeaw.ac.at/schema#Project 6
https://vocabs.acdh.oeaw.ac.at/schema#DisseminationServiceParameter 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataPid with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 169

Property https://vocabs.acdh.oeaw.ac.at/schema#hasFormat with domain https://vocabs.acdh.oeaw.ac.at/schema#BinaryContent is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Collection 255
https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasIdentifier with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#aclRead with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasUpdatedDate with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#createdBy with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#isPartOf with domain https://vocabs.acdh.oeaw.ac.at/schema#PlaceOrPublicationOrRepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 8
https://vocabs.acdh.oeaw.ac.at/schema#DisseminationServiceParameter 6

Property https://vocabs.acdh.oeaw.ac.at/schema#hasDescription with domain https://vocabs.acdh.oeaw.ac.at/schema#Main is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 3

Property https://vocabs.acdh.oeaw.ac.at/schema#hasHash with domain https://vocabs.acdh.oeaw.ac.at/schema#BinaryContent is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10
https://vocabs.acdh.oeaw.ac.at/schema#Collection 2

Property https://vocabs.acdh.oeaw.ac.at/schema#hasOwner with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 8
https://vocabs.acdh.oeaw.ac.at/schema#Project 1

Property https://vocabs.acdh.oeaw.ac.at/schema#isTitleImageOf with domain https://vocabs.acdh.oeaw.ac.at/schema#Resource is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasRawBinarySize with domain https://vocabs.acdh.oeaw.ac.at/schema#BinaryContent is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10
https://vocabs.acdh.oeaw.ac.at/schema#Collection 2

Property https://vocabs.acdh.oeaw.ac.at/schema#hasCreatedStartDate with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 2
https://vocabs.acdh.oeaw.ac.at/schema#Publication 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasLicense with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 7

Property https://vocabs.acdh.oeaw.ac.at/schema#hasUrl with domain https://vocabs.acdh.oeaw.ac.at/schema#AgentOrContainerOrPublicationOrReMe is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 2

Property https://vocabs.acdh.oeaw.ac.at/schema#hasMetadataCreator with domain https://vocabs.acdh.oeaw.ac.at/schema#Main is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 6

Property https://vocabs.acdh.oeaw.ac.at/schema#hasCategory with domain https://vocabs.acdh.oeaw.ac.at/schema#BinaryContent is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 6
https://vocabs.acdh.oeaw.ac.at/schema#Collection 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasLocationPath with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasAccessRestriction with domain https://vocabs.acdh.oeaw.ac.at/schema#BinaryContent is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasUpdatedRole with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasLicensor with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 6

Property https://vocabs.acdh.oeaw.ac.at/schema#hasBinaryUpdatedRole with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasHosting with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10
https://vocabs.acdh.oeaw.ac.at/schema#Publication 59
https://vocabs.acdh.oeaw.ac.at/schema#Project 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasAvailableDate with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasCreatedEndDate with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 2
https://vocabs.acdh.oeaw.ac.at/schema#Publication 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasNonLinkedIdentifier with domain https://vocabs.acdh.oeaw.ac.at/schema#ContainerOrPublicationOrReMe is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasTitle with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasDepositor with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 6
https://vocabs.acdh.oeaw.ac.at/schema#Project 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasBinarySize with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasCreator with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10

Property https://vocabs.acdh.oeaw.ac.at/schema#hasRightsHolder with domain https://vocabs.acdh.oeaw.ac.at/schema#RepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 8

Property https://vocabs.acdh.oeaw.ac.at/schema#hasFilename with domain https://vocabs.acdh.oeaw.ac.at/schema#BinaryContent is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 10
https://vocabs.acdh.oeaw.ac.at/schema#Collection 232

Property https://vocabs.acdh.oeaw.ac.at/schema#isReferencedBy with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 7
https://vocabs.acdh.oeaw.ac.at/schema#Collection 5

Property https://vocabs.acdh.oeaw.ac.at/schema#hasCollectedStartDate with domain https://vocabs.acdh.oeaw.ac.at/schema#Container is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 13

Property https://vocabs.acdh.oeaw.ac.at/schema#hasCollectedEndDate with domain https://vocabs.acdh.oeaw.ac.at/schema#Container is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 13

Property https://vocabs.acdh.oeaw.ac.at/schema#hasExtent with domain https://vocabs.acdh.oeaw.ac.at/schema#PublicationOrRepoObject is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 6

Property https://vocabs.acdh.oeaw.ac.at/schema#hasPublicationDate with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasPublisher with domain https://vocabs.acdh.oeaw.ac.at/schema#Publication is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 1

Property https://vocabs.acdh.oeaw.ac.at/schema#hasLocationUrl with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Collection 5
https://vocabs.acdh.oeaw.ac.at/schema#Resource 4

Property https://vocabs.acdh.oeaw.ac.at/schema#isMetadataFor with domain https://vocabs.acdh.oeaw.ac.at/schema#Metadata is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Resource 4

Property https://vocabs.acdh.oeaw.ac.at/schema#aclWrite with domain ? is used in incompatible classes:

https://vocabs.acdh.oeaw.ac.at/schema#Image 2

too many values (4) for property https://vocabs.acdh.oeaw.ac.at/schema#hasExtent and lang en: 5
too many values (2) for property https://vocabs.acdh.oeaw.ac.at/schema#hasFormat and lang: 2

Thanks! I'll create the property today.
Regarding the discrepancies: they also highlight that some adjustments to the doorkeeper/ingesting process have to be made (e.g. automatically set acdh:hasHosting for TopCollection etc.). I will create and assign issues on Redmine regarding the discrepancies, because they have to be solved in different ways.
About acdh:hasBinaryUpdatedDate: it is a technical property you introduced and we later decided to set its domain to Binary content only. Are you ok with that or should we also include all other entities?
Similarly, acdh:hasFilename is for binaries only, but it might also make sense to include collections into the domain as they would then represent the folder names?
Then I see that acdh:isPartOf is also used in the dissemination services to link parameters with its respective service. I would suggest to use acdh:relation instead.
Is acdh:hasHash calculated for binaries only or also for whole collections? If the latter holds true I would expand the domain to ContainerOrBinary (I think I will get rid of ReMe, because currently it is exactly equal to Binary)

e.g. automatically set acdh:hasHosting for TopCollection etc.

This is already done, just it will be applied only to data ingested in the future (the doorkeeper routines take place only on data ingestion).

About acdh:hasBinaryUpdatedDate: it is a technical property you introduced and we later decided to set its domain to Binary content only. Are you ok with that or should we also include all other entities?

Currently it is only assigned to resources with a binary payload (no matter if they have acdh:Binary class or not). The tricky question here is what should happen if a resource had binary payload which has been removed at some point - should it stay or should it be removed (like acdh:hasHash, acdh:hasRawBinarySize and acdh:hasFilename which are being removed in such a case)? At the moment removing the binary payload from a resource updates the acdh:hasBinaryUpdatedDate.
Anyway I guess most of discrepancies listed above are historical heritage from times when the arche-core behaviour was different and should be just cleaned up. I'll include it in the v2.0.0 migration script.

Similarly, acdh:hasFilename is for binaries only, but it might also make sense to include collections into the domain as they would then represent the folder names?

This is clearly a legacy and should be cleaned up. For collections we have acdh:hasLocationPath (which is provided by the ingestion scripts while the acdh:hasFilename is managed server-side by the arche-core).

Then I see that acdh:isPartOf is also used in the dissemination services to link parameters with its respective service. I would suggest to use acdh:relation instead.

No problem. I'm adjusting the arche-lib-disserv and diss-services.ttl accordingly.

Is acdh:hasHash calculated for binaries only or also for whole collections? If the latter holds true I would expand the domain to ContainerOrBinary (I think I will get rid of ReMe, because currently it is exactly equal to Binary)

Only for resources with binary content. I will take a closer look at two peculiarities found by the check script.

Also, could you provide me with a list of whatever should become an acdh:TopCollection? We should set it to get missing properties properly tested for it.

Ok acdh:hasFilename has been also added client side for directories (read acdh:Collections) by arche-lib-ingest. Fixed in arche-lib-ingest 1.7.0

@bellerophons-pegasus I included code resolving the technical property issues in the v2.0.0 data migration scripts and rerun checks. To avoid spamming I just replaced the previous results with the up to date ones.
From my side the ontology v2 is ready to release. We are only checking on approval from @nczirjak-acdh now.

Just for that it would be good to set achd:TopCollection on all relevant repo resources first. Should this be done according to the "acdh:Collection without acdh:isPartOf" rule?

Yes, every acdh:Collection that does not have acdh:isPartOf should become acdh:TopCollection; on Minvera this should result in 25 on Apollo in 17 (+1 that was already ingested as such). The old type 'acdh:Collection' should then be removed.

property in commit comment should be 'hasContact'

@zozlak I had a look into v2.0.0.sql and I think computing acdh:hasLicenseSummary and acdh:hasAccessRestrictionSummary is missing for the class TopCollection

@zozlak I had a look into v2.0.0.sql and I think computing acdh:hasLicenseSummary and acdh:hasAccessRestrictionSummary is missing for the class TopCollection

Adjusted. Implemented also in the doorkeeper.

Just realised, that isPartOf is mandatory (min cardinality 1) for Collection now; Since TopCollection is a subelement, I am not sure if that will work properly.

@bellerophons-pegasus does it address any particular ingestion issues with have with the current ontology v2?
If not, please postpone such changes to v2.1. If we constantly change something in v2.0, we will never deploy it.

Actually it is an important change. We introduced TopCollection to replace all Collections that have no 'isPartOf'. So cardinality for isPartOf for Collection has to change from 0-n to 1-n and the cardinality for TopCollection has to be 0-n (maybe even 0, but that would then really be a change for a later version). So please include this.

Just realised, that isPartOf is mandatory (min cardinality 1) for Collection now; Since TopCollection is a subelement, I am not sure if that will work properly.

I'm pretty sure the right way of modelling it is to inherit acdh:Collection from acdh:TopCollection (making acdh:Collection a specialization of acdh:TopCollection which can have also acdh:isPartOf). This way we don't need to "reset" cardinality rules for acdh:TopCollection (which is completely against OWL logic; not that we didn't break its logic so far ;) ) because it will be just out of acdh:isPartOf domain.
And if there are more discrepancies between acdh:Collection from acdh:TopCollection (meaning there are "property drops" in both inheritance directions) I would argue they should just not inherit from each other in any direction.

Ok. Then let's do that for V2.1
Doing it the other way round (Coll inherits from TopColl) would lead to more such 'relaxations'. So we'll do that in another future step.
Would you be so kind to revert for me, please?

Then either a common parent class sharing only what they have in common and both TopCollection and Collection derived from it or modelling them separately. Anyway, v2.1 it will be.
Reverted.

🥳


SourceTree (<IP_ADDRESS>) install is not working

λ scoop install sourcetree
Installing 'sourcetree' (<IP_ADDRESS>).
Loading SourceTreeSetup-<IP_ADDRESS>.exe from cache
Checking hash of SourceTreeSetup-<IP_ADDRESS>.exe... ok.
Extracting... done.
Running pre-install script...
ERROR: The system cannot find the file specified.
C:\Users\user.name\scoop\apps\sourcetree\<IP_ADDRESS>\SourceTree-<IP_ADDRESS>-full.nupkg
System ERROR:
The system cannot find the file specified.
Linking ~\scoop\apps\sourcetree\current => ~\scoop\apps\sourcetree\<IP_ADDRESS>
Creating shim for 'sourcetree'.
Can't shim 'lib/net45/sourcetree.exe': File doesn't exist.
λ pwd
C:\Users\user.name\scoop\apps\sourcetree\<IP_ADDRESS>
λ ls -l
total 18509
-rw-r--r-- 1 user.name 1049089       81 Aug 12 00:41 RELEASES
-rw-r--r-- 1 user.name 1049089 17157949 Aug 12 00:39 SourceTree-2.1.11-full.nupkg
-rwxr-xr-x 1 user.name 1049089  1783624 Aug 12 00:41 Update.exe*
-rw-r--r-- 1 user.name 1049089     5397 Apr 12 16:15 background.gif

Fixed with https://github.com/lukesampson/scoop-extras/commit/5298d6e1bb0721c4de01b652ec42bf509e6b8525


Performance and parallelization

I think a significant improvement would be parallelization. I am running peak detection on ~400 files right now and it is already running for 2 or 3 days.

Hello. Do you have a nvidia gpu with installed drivers?


Update project-27-bayes-warmup.md

update youtube video link

Can I confirm whether this constitutes a full submission (i.e. github repo + youtube video)? thanks!

Hi @eltonpan , sorry for the delay. Yes, this is fine! Do you mind also adding a LinkedIn and X post? Otherwise should be good to merge.

Sure, I will get a member of the team to do that. Looking forward to the merge. Thanks!

Awesome, thanks!


add veterans topic to index

diff_report: https://gist.githubusercontent.com/chejennifer/46aba5cb393e634774afff3e8829349c/raw/c6c89983c3a346df32ea587953c52294f01c3068/diff_report.html
Note: not sure if we want ALL the veterans topics to be showing up under veteran unemployment ..?

On local explore, could you try a few queries and see how it works? Like
"what are the top wars that the US veterans have fought in?" "how much do veterans earn in the US?" "Veterans in which US counties earn the most?" "what is the gender breakdown of US veterans?"

Tried some queries and somethings I noticed:

for the first 3 queries, the result always had the correct topic as the first result, but still showed the rest of the topics on the page .. not sure if that's something that would be expected?
e.g.,
screen-recording - 2023-10-04T225603.438.webm
for the gender breakdown query, it's not returning the veterans by gender as the top result and I'm slightly puzzled ..

the debug result: https://screenshot.googleplex.com/Byvmi3PVX2x7dMY
the result page:
screen-recording - 2023-10-04T230042.335.webm

On local explore, could you try a few queries and see how it works? Like
"what are the top wars that the US veterans have fought in?" "how much do veterans earn in the US?" "Veterans in which US counties earn the most?" "what is the gender breakdown of US veterans?"

Tried the example queries and a few things:

for the first 3 queries, the result always had the correct topic as the first result, but still showed the rest of the topics on the page .. is that expected?
e.g.,
screen-recording - 2023-10-04T225603.438.webm

I think that's expected.  We'll show charts for multiple topics.

for the gender breakdown query, it's not returning the veterans by gender as the top result and I'm slightly puzzled ..

the debug result: https://screenshot.googleplex.com/Byvmi3PVX2x7dMY
the result page:
screen-recording - 2023-10-04T230042.335.webm

That is indeed puzzling!  Maybe we can debug better after you submit this?

ok, I will submit, thanks for the reviews! & correct, no results when running ./run_test.sh -g


Getting rid off configuration in xml

@andreasohlund @danielmarbach I'd like to get rid of those xml settings for webapp

Why Do we need a shared .csproj?(can we just add the file to a folder and link them?)

+1 to removing the config in xml

Done @andreasohlund merge if ok with it


Change message when service is not up and running with new config

@bratseth changed the message as you suggested, please take a look


More a request than an issue. Mouse mapping depend upon mouse/trackpad

Hello there,
Some wonderful work going on here. I'm considering releasing a distro using this as the main menu system, however there are some issues I have. The main one at present is, what would the best way to go about changing the shortcuts depending on whether a laptop is using a trackpad or a mouse?
Middle click for a menu is great when a mouse is plugged in, but another shortcut would need to be defined if using a trackpad due to many of them not supporting a middle click.
Any idea how to go about this?
Cheers
Dan

I believe there is also an configuration option in some/most Linux trackpad drivers to have middle click emulated when both trackpad buttons are pressed simultaneously. And if you find a driver that covers 95% of your users, then the last 5% can just be instructed to change the hotkey to something they like.

As Gnome-Pie is now in low-maintanance-mode, I won't have the time to work on this. If you're using GNOME Shell and if you are still interested in this project, you could try out Fly-Pie which is a successor project of Gnome-Pie. Fly-Pie is actually made to work well with touch-pads!


Feature: Add 'echo' command

Describe the solution you'd like
Add info about the echo command

I'm working on this.

I've opened a PR for this at #61. Please have a look. Thanks :smile:

Thanks @shubhangi013! Just merged it


Update add-question-metadata-portal.md (Typo "Azure Open AI"→"Azure O…

…penAI")
https://learn.microsoft.com/en-us/azure/ai-services/qnamaker/quickstarts/add-question-metadata-portal
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/ai-services/qnamaker/Quickstarts/add-question-metadata-portal.md
#PingMSFTDocs

@jboback
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Roll Flutter Engine from 23f730efbff7 to fa83e4c41bb1 (3 revisions)

https://github.com/flutter/engine/compare/23f730efbff7...fa83e4c41bb1
2023-05-07<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from FFOWihz4lzOeDHmNj... to k4NzlntuagXZIlCJg... (flutter/engine#41799)
2023-05-06<EMAIL_ADDRESS>Roll Dart SDK from d04e8b571819 to ab64c4a56e2c (1 revision) (flutter/engine#41798)
2023-05-06<EMAIL_ADDRESS>Add a Display API to dart:ui that reports the physical size, DPR, and refresh rate of the main display (flutter/engine#41685)
Also rolling transitive DEPS:
fuchsia/sdk/core/mac-amd64 from FFOWihz4lzOe to k4NzlntuagXZ
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jimgraham@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


ci(coverage): add coverage reports

fixes #10
fixes #76

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


CrossPlatform: inc/type_traits shadowed by system header (APPLE)

Hi @obastemur, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

@dotnet-bot test Copyright Check please

Thank you @obastemur for this fix. Could you please rebase it to latest linux HEAD?

Thank you @obastemur for this fix. Could you please rebase it to latest linux HEAD?

Done

Thank you @obastemur for this fix. Could you please rebase it to latest linux HEAD?
Done

Sorry, the update seems leaked a .gyp file?

Sorry, the update seems leaked a .gyp file?

Sorry. updated / fixed.

Sorry, the update seems leaked a .gyp file?
Sorry. updated / fixed.

I'm sorry, but it looks https://github.com/obastemur/ChakraCore/commits/linux_shadow_stl is not based on latest Microsoft/linux HEAD. Your commit parent is "Checkpoint commit: lib/common/core". Please rebase it to latest so parent be "build lib/common/DataStructures".

@obastemur Please ignore previous rebase request. I've hand merged it and pushed. Again, thanks for your PR!

@jianchun thanks!


Significantly less available disk space in macos-14-arm64

Description
The 20240827.4 release of the macos-14-arm64 image seems to have significantly less available disk space than the previous release (20240818.4). I wanted to check if this was intended or expected. This is unfortunately causing our builds to fail.
20240827.4 initial space:
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1s1   295Gi   9.6Gi    18Gi    35%    404k  190M    0%   /
devfs            195Ki   195Ki     0Bi   100%     674     0  100%   /dev
/dev/disk3s6     295Gi    20Ki    18Gi     1%       0  190M    0%   /System/Volumes/VM
/dev/disk3s2     295Gi   4.9Gi    18Gi    22%     153  190M    0%   /System/Volumes/Preboot
/dev/disk3s4     295Gi   288Ki    18Gi     1%      23  190M    0%   /System/Volumes/Update
/dev/disk1s2     500Mi    20Ki   495Mi     1%       0  5.1M    0%   /System/Volumes/xarts
/dev/disk1s1     500Mi    96Ki   495Mi     1%      20  5.1M    0%   /System/Volumes/iSCPreboot
/dev/disk1s3     500Mi   196Ki   495Mi     1%      17  5.1M    0%   /System/Volumes/Hardware
/dev/disk3s5     295Gi   261Gi    18Gi    94%    2.2M  190M    1%   /System/Volumes/Data
map auto_home      0Bi     0Bi     0Bi   100%       0     0     -   /System/Volumes/Data/home

compared to 20240818.4 initial space:
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1s1   295Gi   9.6Gi    57Gi    15%    404k  593M    0%   /
devfs            195Ki   195Ki     0Bi   100%     674     0  100%   /dev
/dev/disk3s6     295Gi    20Ki    57Gi     1%       0  593M    0%   /System/Volumes/VM
/dev/disk3s2     295Gi   4.9Gi    57Gi     9%     153  593M    0%   /System/Volumes/Preboot
/dev/disk3s4     295Gi   272Ki    57Gi     1%      14  593M    0%   /System/Volumes/Update
/dev/disk1s2     500Mi    20Ki   495Mi     1%       0  5.1M    0%   /System/Volumes/xarts
/dev/disk1s1     500Mi    96Ki   495Mi     1%      20  5.1M    0%   /System/Volumes/iSCPreboot
/dev/disk1s3     500Mi   196Ki   495Mi     1%      17  5.1M    0%   /System/Volumes/Hardware
/dev/disk3s5     295Gi   222Gi    57Gi    80%    2.1M  593M    0%   /System/Volumes/Data
map auto_home      0Bi     0Bi     0Bi   100%       0     0     -   /System/Volumes/Data/home

Platforms affected

[ ] Azure DevOps
[X] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] Ubuntu 24.04
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[X] macOS 14 Arm64
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
20240827.4
https://github.com/rust-lang-ci/rust/actions/runs/10612800738/job/29415273318
Is it regression?
Yes, 20240818.4 works. https://github.com/rust-lang-ci/rust/actions/runs/10622377375/job/29446525166
Expected behavior
Would like to have more than 18GiB free when starting.
Actual behavior
Only 18GiB free when starting.
Repro steps

Run a job on macos-14-arm64 that uses the new image.

Hi @ehuss
We are looking into it. Will keep you posted.

Hey @ehuss!
Please, see the description of GitHub hosted runners bellow:

https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

Thank you for bringing this fact to our attention. Most likely, it is related to the fact that a new Xcode with all SDKs and simulators was added to the assembly, but this still fits into the stated service agreement and is not a regression. Please, see the description of GitHub hosted runners bellow:

https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

Just in case, we will of course check what exactly led to such a sharp decrease in space and will try to do something about it, but unfortunately we cannot make any promises. MacOS images are the most voluminous and it is quite difficult to remove something from there without negatively affecting the experience of other users. If your builds require additional space, CPU or RAM, then I recommend paying attention to Larger Runners:

https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners

Is there any equivalent cleanup command as per #10386 but for macOS runners instead?

I appreciate you looking into this, but regarding the recommendation to use larger runners, I am curious: which one is the one with more than 14GiB storage (as promised by service contract), exactly?

Runner Size
Architecture
Processor (CPU)
Memory (RAM)
Storage (SSD)
Workflow label

Large
Intel
12
30 GB
14 GB
macos-latest-large, macos-12-large, macos-13-large [latest], macos-14-large[Beta]

XLarge
arm64 (M1)
6 (+ 8 GPU hardware acceleration)
14 GB
14 GB
macos-latest-xlarge, macos-13-xlarge [latest], macos-14-xlarge[Beta]

Hey @nth10sd!
We'll definitely propose something like that to you later. It's a good temporary solution I think.

Hey @workingjubilee!
Nice input. I checked up with the corresponding team and it seams that you are right - there is no option to extend disk space for macOS as it might be done for the Ubuntu/Windows images.
Given the above and all the information in general, the best solution would be to try to increase the free space on our side - we will try to work on this. As an interim solution, we will develop a couple of small scripts that can be implemented in your CI in order to free up space on the runner by removing components that are not needed at the moment.
cc: @ehuss

APFS seems to support reflinks/file clones. Has deduplication been applied to the runner images? If not then that might save some space.

We are suffering from the same issue too

+1 for tracking. Also running into this.

Suffering of this as well +1

+1 also on our side

You can 👍 the issue instead of adding new comments.

👍

We encountered this as a sudden failure of Homebrew to install the mactex-no-gui package, with only the cryptic message: installer: The install failed..
Searching the issues in this repo didn't turn up anything -- hopefully, mentioning Homebrew in this comment will help someone searching in the future.  I was eventually able to discover where the Homebrew installer logs are recorded and saw messages that the package needed 8.89 GB but only 7.99 GB was available.  The install works on macos-12 and macos-13 runners, which still have enough space.  But this alerted to me how much space the mactex-no-gui bundle needed.  We are able to workaround the decrease in space by installing the Homebrew texlive target instead, which is smaller.

I ran into this issue on our macos runner. After doing a bit of sleuthing with df and du to work out what was consuming so much disk space I discovered all of these in the Applications folder:
44G	/Applications
 11G	/Applications/Xcode_14.3.1.app
 4.9G	/Applications/Xcode_15.4.app
 4.9G	/Applications/Xcode_15.3.app
 4.8G	/Applications/Xcode_15.2.app
 4.5G	/Applications/Xcode_15.1.app
 4.5G	/Applications/Xcode_15.0.1.app
 4.3G	/Applications/Xcode_16_beta_6.app
 4.3G	/Applications/Xcode_16.1_beta.app

We do use Xcode as part of our build, but we only need one of those versions of Xcode (not all of them). So the solution in our case was to delete a bunch of the old ones:
      # We only use Xcode 15.4
      - name: Remove unused applications
        run: |
          df -hI /dev/disk3s1s1
          sudo rm -rf /Applications/Xcode_14.3.1.app
          sudo rm -rf /Applications/Xcode_15.0.1.app
          sudo rm -rf /Applications/Xcode_15.1.app
          sudo rm -rf /Applications/Xcode_15.2.app
          sudo rm -rf /Applications/Xcode_15.3.app
          df -hI /dev/disk3s1s1

... which frees up about 30GB of space.

Running into non-stop issues tonight on macos-14 runners, I suspect related to this. It is during creation + publishing of pkg and dmg files for an electron app using electron-builder.
    '><EMAIL_ADDRESS>clean:electron\n' +
    '> rimraf release\n' +
    '\n' +
    '  • electron-builder  version=24.13.3 os=23.6.0\n' +
    '  • loaded configuration  file=package.json ("build" field)\n' +
    '  • skipped dependencies rebuild  reason=npmRebuild is set to false\n' +
    '  • packaging       platform=darwin arch=arm64 electron=31.4.0 appOutDir=release/mac-arm64\n' +
    '  • downloading     url=https://github.com/electron/electron/releases/download/v31.4.0/electron-v31.4.0-darwin-arm64.zip size=96 MB parts=6\n' +
    '  • downloaded      url=https://github.com/electron/electron/releases/download/v31.4.0/electron-v31.4.0-darwin-arm64.zip duration=2.38s\n' +
    '  • signing         file=release/mac-arm64/Highlight.app platform=darwin type=distribution identity=F75C1F04C795458F64DF817F199AF7712B510BD6 provisioningProfile=Highlight.provisionprofile\n' +
    '  • notarization successful\n' +
    '  • building        target=macOS zip arch=arm64 file=release/Highlight-0.0.118-alpha-arm64-mac.zip\n' +
    '  • building        target=DMG arch=arm64 file=release/Highlight-0.0.118-alpha-arm64.dmg\n' +
    '  • building        target=pkg arch=arm64 file=release/Highlight-0.0.118-alpha-arm64.pkg\n' +
    '  • Detected arm64 process, HFS+ is unavailable. Creating dmg with APFS - supports Mac OSX 10.12+\n' +
    '  • building block map  blockMapFile=release/Highlight-0.0.118-alpha-arm64.dmg.blockmap\n' +
    '  • publishing      publisher=[object Object]\n' +
    'Preparing for release: /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/Highlight-0.0.118-alpha-arm64.dmg.blockmap\n' +
    'Preparing for release: /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/Highlight-0.0.118-alpha-arm64.dmg\n' +
    '  • building block map  blockMapFile=release/Highlight-0.0.118-alpha-arm64-mac.zip.blockmap\n' +
    'Preparing for release: /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/Highlight-0.0.118-alpha-arm64-mac.zip.blockmap\n' +
    'Preparing for release: /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/Highlight-0.0.118-alpha-arm64-mac.zip\n' +
    '  ⨯ Exit code: 1. Command failed: productbuild --synthesize --component /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/mac-arm64/Highlight.app /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/distribution.xml\n' +
    `productbuild: error: Can't write temporary package to "/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/TemporaryItems/NSIRD_productbuild_KbOv6A/tv.medal.highlight.pkg" (Cannot write package to "/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/TemporaryItems/NSIRD_productbuild_KbOv6A/tv.medal.highlight.pkg".).\n` +
    '\n' +
    '\n' +
    'productbuild: Adding component at /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/mac-arm64/Highlight.app\n' +
    'productbuild: Inferred install-location of /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/mac-arm64\n' +
    '\n' +
    `productbuild: error: Can't write temporary package to "/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/TemporaryItems/NSIRD_productbuild_KbOv6A/tv.medal.highlight.pkg" (Cannot write package to "/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/TemporaryItems/NSIRD_productbuild_KbOv6A/tv.medal.highlight.pkg".).\n` +
    '\n' +
    '  failedTask=build stackTrace=Error: Exit code: 1. Command failed: productbuild --synthesize --component /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/mac-arm64/Highlight.app /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/distribution.xml\n' +
    `productbuild: error: Can't write temporary package to "/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/TemporaryItems/NSIRD_productbuild_KbOv6A/tv.medal.highlight.pkg" (Cannot write package to "/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/TemporaryItems/NSIRD_productbuild_KbOv6A/tv.medal.highlight.pkg".).\n` +
    '                                                                                productbuild: Adding component at /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/mac-arm64/Highlight.app\n' +
    'productbuild: Inferred install-location of /private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/release/mac-arm64\n' +
    '                                                                                '... 2317 more characters,
  stderr: '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "crypto" has been externalized for browser compatibility, imported by "/private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/src/main/utils/crypto/JsonCrypto.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "fs" has been externalized for browser compatibility, imported by "/private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/src/shared/utils/StringUtils.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "util" has been externalized for browser compatibility, imported by "/private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/node_modules/handlebars-utils/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "stream" has been externalized for browser compatibility, imported by "/private/var/folders/m4/5dz5h26x329cqq4fx333f8gm0000gn/T/highlight-electron-temp/standalone/node_modules/handlebars-async-helpers/helpers/each.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    'node_modules/mammoth/node_modules/bluebird/js/release/util.js (201:9): Use of eval in "node_modules/mammoth/node_modules/bluebird/js/release/util.js" is strongly discouraged as it poses security risks and may cause issues with minification.\n'

Here is a step that will delete all beta versions of Xcode unless you explicitly selected one:
- name: Delete unused Beta Xcode installations
   run: |
     echo "Available Xcode installations:"
     xcodes installed
     selected_path="$(xcode-select -p)"; selected_path="${selected_path%/Contents/Developer}"
     find /Applications \
       -depth 1 \
       -name "Xcode*beta*.app" \
       -not -path "${selected_path}" \
       -exec rm -rf {} +

In addition to the above suggestions to delete unused versions of Xcode, we were able to add a significant amount of space by deleting unused simulators and clearing the simulator cache:
echo "Deleting all iOS simulators"
xcrun simctl delete all

# Do the following only if you need a simulator for things like unit tests
echo "Creating an iOS simulator to run unit tests"
xcrun simctl create "Unit-Test-Device" "iPhone 15 Pro Max" "iOS17.5"

# This folder starts at 42 GB and sometimes increases to as high as 61 GB.
# After deleting it and running a build, the final size is only 12 GB, so this is
# a good target for disk space savings.
echo "Deleting iOS Simulator caches"
sudo rm -rf ~/Library/Developer/CoreSimulator/Caches/*

I have tried below script on my unit test job, and after cleaning up the space, it still fails, and when I rerun the job, all Xcodes version are still there. Cleaning up does not solve the problem.
- name: Calculate initial disk space
 run: df -h

- name: Size of apps in Applications folder Before deletion
 run: |
   sudo du -sh /Applications/*

# We only use Xcode 15.4
- name: Remove unused applications
 run: |
   df -hI /dev/disk3s1s1
   sudo rm -rf /Applications/Xcode_14.3.1.app
   sudo rm -rf /Applications/Xcode_15.0.1.app
   sudo rm -rf /Applications/Xcode_15.1.app
   sudo rm -rf /Applications/Xcode_15.2.app
   sudo rm -rf /Applications/Xcode_15.3.app
   df -hI /dev/disk3s1s1

- name: Size of apps in Applications folder After deletion
 run: |
   sudo du -sh /Applications/*

- name: Clean Xcode derived data and caches
 run: |
   sudo rm -rf ~/Library/Developer/Xcode/DerivedData

- name: Delete unnecessary simulator files
 run: |
   sudo rm -rf ~/Library/Developer/CoreSimulator/Devices/*
   sudo rm -rf ~/Library/Developer/CoreSimulator/Caches/*

- name: Clean up iOS DeviceSupport files
 run: |
   sudo rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

- name: Check final disk space
 run: df -h

After running df -h
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1s1   295Gi   9.6Gi    17Gi    37%    404k  176M    0%   /
devfs            195Ki   195Ki     0Bi   100%     674     0  100%   /dev
/dev/disk3s6     295Gi    20Ki    17Gi     1%       0  176M    0%   /System/Volumes/VM
/dev/disk3s2     295Gi   4.9Gi    17Gi    23%     153  176M    0%   /System/Volumes/Preboot
/dev/disk3s4     295Gi   288Ki    17Gi     1%      23  176M    0%   /System/Volumes/Update
/dev/disk1s2     500Mi    20Ki   495Mi     1%       0  5.1M    0%   /System/Volumes/xarts
/dev/disk1s1     500Mi    96Ki   495Mi     1%      20  5.1M    0%   /System/Volumes/iSCPreboot
/dev/disk1s3     500Mi   196Ki   495Mi     1%      17  5.1M    0%   /System/Volumes/Hardware
/dev/disk3s5     295Gi   262Gi    17Gi    94%    2.1M  176M    1%   /System/Volumes/Data
map auto_home      0Bi     0Bi     0Bi   100%       0     0     -   /System/Volumes/Data/home

You can see that some of those partitions are huge and use only a small fraction of the available space. In the past when we were using self-hosted runners from AWS one of the first steps we did was rearranging space.
Something like here: https://derflounder.wordpress.com/2020/12/19/resizing-an-aws-macos-ec2-instances-boot-drive-to-use-all-available-disk-space/

For other folks finding this...
Definitely bit our project too, and seems like a pretty sharp regression.
We found removing Xcode versions was very slow though and for limited space. The tip to remove the iOS simulators (and maybe only add the one you need) look much more promising. Happens that we're just testing on macOS, not iOS, so even better for us. In case folks want to see a full PR that adds this:
https://github.com/carbon-language/carbon-lang/pull/4287

Opis
Wydaje się, że w wydaniu obrazu macos-14-arm64 w wersji 20240827.4 dostępnych jest znacznie mniej miejsca na dysku niż w poprzedniej wersji (20240818.4). Chciałem sprawdzić, czy to było zamierzone, czy oczekiwane. To niestety powoduje, że nasze kompilacje zawodzą.
20240827.4 przestrzeń początkowa:
Rozmiar systemu plików Używana pojemność avail iused ifree % iused Montowane na
/dev/disk3s1s1 295Gi 9,6Gi 18Gi 35% 404k 190M 0% /
devfs 195Ki 195Ki 0Bi 100% 674 0 100%/dev
/dev/disk3s6 295Gi 20Ki 18Gi 1% 0 190M 0% /System/Tomy/VM
/dev/disk3s2 295Gi 4,9Gi 18Gi 22% 153 190M 0% /System/Tomy/Preboot
/dev/disk3s4 295Gi 288Ki 18Gi 1% 23 190M 0% /System/Tomy/Aktualizacja
/dev/disk1s2 500Mi 20Ki 495Mi 1% 0 5,1M 0% /System/Tomy/wyniki
/dev/disk1s1 500Mi 96Ki 495Mi 1% 20 5,1M 0% /System/Tomy/iSCPreboot
/dev/disk1s3 500Mi 196Ki 495Mi 1% 17 5,1M 0% /System/Tomy/sprzęt
/dev/disk3s5 295Gi 261Gi 18Gi 94% 2,2M 190M 1%/System/Tomy/Dane
mapa auto_home 0Bi 0Bi 0Bi 100% 0 0 -/System/Tomy/Dane/home

w porównaniu do powierzchni początkowej 20240818.4:
Rozmiar systemu plików Używany Pojemność avail iused ifree % iused Montowany na
/dev/disk3s1s1 295Gi 9,6Gi 57Gi 15% 404k 593M 0% /
devfs 195Ki 195Ki 0Bi 100% 674 0 100%/dev
/dev/disk3s6 295Gi 20Ki 57Gi 1% 0 593M 0% /System/Tomy/VM
/dev/disk3s2 295Gi 4,9Gi 57Gi 9% 153 593M 0% /System/Tomy/Preboot
/dev/disk3s4 295Gi 272Ki 57Gi 1% 14 593M 0% /System/Tomy/Aktualizacja
/dev/disk1s2 500Mi 20Ki 495Mi 1% 0 5,1M 0% /System/Tomy/wyniki
/dev/disk1s1 500Mi 96Ki 495Mi 1% 20 5,1M 0% /System/Tomy/iSCPreboot
/dev/disk1s3 500Mi 196Ki 495Mi 1% 17 5,1M 0% /System/Tomy/sprzęt
/dev/disk3s5 295Gi 222Gi 57Gi 80% 2,1M 593M 0%/System/Tomy/Dane
mapa auto_home 0Bi 0Bi 0Bi 100% 0 0 -/System/Tomy/Dane/home

Platformy dotknięte

[ ]  Azure DevOps
[x]  Akcje GitHub - Standard Runners
[ ]  Akcje GitHub - Więksi biegacze

Obrazy biegacza dotknięte

[ ]  Ubuntu 20.04
[ ]  Ubuntu 22.04
[ ]  Ubuntu 24.04
[ ]  MacOS 12
[ ]  MacOS 13
[ ]  MacOS 13 Arm64
[ ]  MacOS 14
[x]  MacOS 14 Arm64
[ ]  Windows Server 2019
[ ]  Windows Server 2022

Wersja obrazu i link do kompilacji
20240827,4
https://github.com/rust-lang-ci/rust/actions/runs/10612800738/job/29415273318
Czy to regresja?
Tak, 20240818.4 działa. https://github.com/rust-lang-ci/rust/actions/runs/10622377375/job/29446525166
Oczekiwane zachowanie
Chciałby mieć więcej niż 18 GiB za darmo podczas uruchamiania.
Rzeczywiste zachowanie
Tylko 18 GiB za darmo podczas uruchamiania.
Repro steps

Run a job on macos-14-arm64 that uses the ne

w image.

macOS-14 images without visionOS on board rolled out. It made free plenty of precious GB. We will continue to work on image optimisation and reorganisation of used space. At this point the free space issue should be resolved for the vast majority of users. I will not close this issue as a temporary solution was applied while a permanent one is still in development.

I can confirm, maybe we could avoid to free up space by removing xcode in our Action?
Initial space mac os 14

I can confirm, maybe we could avoid to free up space by removing xcode in our Action?

At your discretion. I think you can disable it for now to save execution time if the specified space is enough for you. I will notify you and other participants separately about all further changes as they happen.

👋
For those tracking these changes or encountering issues for the first time, here’s some context and clarification.
As you may know, we recently faced significant challenges where many users began running out of disk space during tests and builds on macOS-based runners. 😞  This issue was triggered by the inclusion of visionOS simulators in the latest Xcode builds. The root cause, however, lies in our policy of providing nearly all supported minor versions of Xcode on each macOS image, leading to steadily increasing disk usage as Apple’s ecosystem grows.
Here’s how we’ve approached resolving the issue so far:

Immediate action: We temporarily stopped pre-installing visionOS platform tools in Xcode on macOS-14 images.
Strategic adjustment: We introduced a policy to limit the number of major Xcode versions installed per macOS image, alongside reinstating visionOS tools for supported Xcode versions. This aimed to free up significant disk space. https://github.com/actions/runner-images/pull/10876

However, we’ve discovered that some projects rely on multiple major versions of Xcode simultaneously, making these strict measures overly restrictive. This prompted us to refine our strategy, prioritising functionality alongside disk space optimisation.
Current Strategy 📏
Our updated approach balances reducing installed Xcode versions with maintaining runner usability:

macOS-14 images:

Will include all minor releases of Xcode 15 with the full platform tools suite (as before).
Will now also include two minor releases of Xcode 16 (excluding visionOS tools). These will follow a “last two” principle, with the oldest replaced by the newest as updates are released. Beta versions will not be included. https://github.com/actions/runner-images/pull/10962

macOS-15 images:

Will include all minor releases of Xcode 16 with the full platform tools suite (as before).
Will also include the latest available release of Xcode 15 with the full platform tools suite. https://github.com/actions/runner-images/pull/11023

Disk Space and Future Adjustments:

Currently, macOS-14 images have approximately 60 GB of free space. However, this is not a guaranteed figure and may decrease over time.
When free space approaches 30 GB, we will reassess our policies and toolsets to ensure compliance with our promised minimum of 14 GB of free space.
macOS-15 images are not currently impacted by this issue. However, with future Xcode updates, policies may need to be revisited. 🤷♂

Recommendations 🦮

If your workflows depend on visionOS, we recommend switching to macOS-15 images.
If your tasks require significant disk space, consider preparing the runner by removing unnecessary large components before starting your workflows.


[BEAM-301] Add a Beam SQL DSL

add checkstyle to dsls module, and update as indicated;
correct the package name from org.beam.dsls.sql to org.apache.beam.dsls.sql;

Retest this please

SQL build pass, seems error in module Apache Beam :: SDKs :: Python
@jbonofre @davorbonaci , could you have a peek at this change?

Retest this please


npm version identifier "latest" not supported

Hi,
I got this error message because the version "latest" is used in a package.json file. We use this for private npm package from Azure DevOps artifacts npm repository.
/opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-npm_and_yarn-0.117.7/lib/dependabot/npm_and_yarn/requirement.rb:26:in `parse': Illformed requirement ["latest"] (Gem::Requirement::BadRequirementError)
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/2.6.0/rubygems/requirement.rb:135:in `block in initialize'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/2.6.0/rubygems/requirement.rb:135:in `map!'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/2.6.0/rubygems/requirement.rb:135:in `initialize'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-npm_and_yarn-0.117.7/lib/dependabot/npm_and_yarn/requirement.rb:54:in `initialize'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-npm_and_yarn-0.117.7/lib/dependabot/npm_and_yarn/requirement.rb:45:in `new'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-npm_and_yarn-0.117.7/lib/dependabot/npm_and_yarn/requirement.rb:45:in `block in requirements_array'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-npm_and_yarn-0.117.7/lib/dependabot/npm_and_yarn/requirement.rb:43:in `map'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-npm_and_yarn-0.117.7/lib/dependabot/npm_and_yarn/requirement.rb:43:in `requirements_array'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-common-0.117.7/lib/dependabot/update_checkers/base.rb:267:in `block in version_from_requirements'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-common-0.117.7/lib/dependabot/update_checkers/base.rb:267:in `each'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-common-0.117.7/lib/dependabot/update_checkers/base.rb:267:in `flat_map'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-common-0.117.7/lib/dependabot/update_checkers/base.rb:267:in `version_from_requirements'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-common-0.117.7/lib/dependabot/update_checkers/base.rb:255:in `can_compare_requirements?'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-common-0.117.7/lib/dependabot/update_checkers/base.rb:246:in `requirements_up_to_date?'
	from /opt/hostedtoolcache/Ruby/2.6.6/x64/lib/ruby/gems/2.6.0/gems/dependabot-common-0.117.7/lib/dependabot/update_checkers/base.rb:29:in `up_to_date?'
	from ./update.rb:75:in `block in <main>'
	from ./update.rb:66:in `each'
	from ./update.rb:66:in `<main>'

https://docs.npmjs.com/files/package.json#dependencies
check this sample from npm-package.json
{ "dependencies" :
  { "foo" : "1.0.0 - 2.9999.9999"
  , "bar" : ">=1.0.2 <2.1.2"
  , "baz" : ">1.0.2 <=2.3.4"
  , "boo" : "2.0.1"
  , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
  , "asd" : "http://asdf.com/asdf.tar.gz"
  , "til" : "~1.2"
  , "elf" : "~1.2.3"
  , "two" : "2.x"
  , "thr" : "3.3.x"
  , "lat" : "latest"
  , "dyl" : "file:../dyl"
  }
}

@Bertk this should be fixed now 🎉  https://github.com/dependabot/dependabot-core/pull/3781

I have a similar error but the package versioning is not using the "latest" tag.
here is the error message:
/home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/npm_and_yarn/lib/dependabot/npm_and_yarn/requirement.rb:26:in `parse': Illformed requirement ["UI5-1.102"] (Gem::Requirement::BadRequirementError)
	from /usr/local/lib/ruby/3.1.0/rubygems/requirement.rb:138:in `block in initialize'
	from /usr/local/lib/ruby/3.1.0/rubygems/requirement.rb:138:in `map!'
	from /usr/local/lib/ruby/3.1.0/rubygems/requirement.rb:138:in `initialize'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/npm_and_yarn/lib/dependabot/npm_and_yarn/requirement.rb:54:in `initialize'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/npm_and_yarn/lib/dependabot/npm_and_yarn/requirement.rb:45:in `new'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/npm_and_yarn/lib/dependabot/npm_and_yarn/requirement.rb:45:in `block in requirements_array'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/npm_and_yarn/lib/dependabot/npm_and_yarn/requirement.rb:43:in `map'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/npm_and_yarn/lib/dependabot/npm_and_yarn/requirement.rb:43:in `requirements_array'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/common/lib/dependabot/update_checkers/base.rb:298:in `block in version_from_requirements'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/common/lib/dependabot/update_checkers/base.rb:298:in `each'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/common/lib/dependabot/update_checkers/base.rb:298:in `flat_map'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/common/lib/dependabot/update_checkers/base.rb:298:in `version_from_requirements'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/common/lib/dependabot/update_checkers/base.rb:286:in `can_compare_requirements?'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/common/lib/dependabot/update_checkers/base.rb:273:in `requirements_up_to_date?'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/common/lib/dependabot/update_checkers/base.rb:35:in `up_to_date?'
	from /home/dependabot/dependabot-updater/vendor/ruby/3.1.0/bundler/gems/dependabot-core-e02718538024/npm_and_yarn/lib/dependabot/npm_and_yarn/update_checker.rb:27:in `up_to_date?'
	from bin/update-script.rb:600:in `block in <main>'
	from bin/update-script.rb:563:in `each'
	from bin/update-script.rb:563:in `<main>'
##[error]The process '/usr/bin/docker' failed with exit code 1

Here is the the dependency:
"devDependencies": {
    "@sap/ux-specification": "UI5-1.102",
  },

I tried changing the version of "@sap/ux-specification" to "^1.102.0". the result is still the same.


feat: upgrade kafka sarama client

https://github.com/alibaba/ilogtail/issues/600

upgrade upgrade kafka sarama client to 1.38.1 and rewrite service_kafka input plugin
Optimize flusher kafka v2 to improve performance in static topic scenarios
support kafka 2.8.0+

@linrunqi08 尽快测试下InputKafka对企业版的影响，测试通过后即可合入。


Add option to disable automatic updates

This branch allows us to use an {{each}} inside ember-impagination. In the README I outline the flags that need to be set, and include some suggested methods.
Previously, we considered implementing a "setToEnd" function, which would be yielded on records. I do not think this is the API we want to reveal to users. Instead we should make them aware of ember-in-viewport, and the [mut helper]
(https://github.com/emberjs/ember.js/blob/v2.2.0/packages/ember-htmlbars/lib/keywords/mut.js#L47).

This branch also includes a fix to revert ember-impagination's virtual-each dependency on version 0.0.14 which is what we need to make the Demo Application work. I will move this to a pull-request on master instead!

How's this going?

Closing in Favor of #130


Ephemeral streams

A Polkadot Host node should open several substreams. In particular, it should periodically open ephemeral substreams in order to:

ping the remote peer and check whether the connection is still alive. Failure for the remote peer to reply leads to a disconnection. This uses the libp2p ping protocol specified in [lab19].
ask information from the remote.
send Kademlia random walk queries. Each Kademlia query is done in a new separate substreams. This

Aha! Link: https://soramitsucoltd.aha.io/requirements/PRE-51-5

All of them already implemented


"JAVA DEPENDENCIES" View should always show

Current Behavior
Currently, the view only shows up when the Java LS finishes loading the project.
Expected Behavior

The view needs to be statically showing in the file explorer view. Its visibility should be controlled by users.
When the view is loading and has nothing to show, show icon or text to indicate the loading status just like other views.

Tried different combination, logged an issue for this:
https://github.com/redhat-developer/vscode-java/issues/888


Phison 2251-07

Hi,
I know this has been posted multiple times, but I would like to test this vulnerability, whether with this script or not. I've got a Patriot Supersonic Xpress 16 GB, and, of course, I was gifted with the 2251-07 version. Is there ANY possibility to get this working on the 07?

i follow, same as you need that info :)

Yep :/ Doesn't seem like it tho. I am familiar with C++ etc, but only application coding. I don't know much about binaries applying to other chip types, like the 8051 one used here...

can we have a private talk? my mail is<EMAIL_ADDRESS>.
Send me a mail or share your here :D

Same here it sucks, I wish there was an update. I could help as well, I know a bit of c++

selling 2251-03/2303 chips flash disk,contact me if you want buy
I have lots of 2251-03/2303 flsh disk,and it works with badusb,if anyone want to buy,please contact me, my email is<EMAIL_ADDRESS>

GitHub is not a selling platform. Advertise your offer/scam somewhere other
like eBay.
Am 09.02.2016 03:05 schrieb "haaha123123123"<EMAIL_ADDRESS>
selling 2251-03/2303 chips flash disk,contact me if you want buy
I have lots of 2251-03/2303 flsh disk,and it works with badusb,if anyone
want to buy,please contact me, my email is<EMAIL_ADDRESS>—
Reply to this email directly or view it on GitHub
https://github.com/adamcaudill/Psychson/issues/111#issuecomment-181669203
.


{Core} Improve autocomplete performance by preventing loading all modules

Description

Close #24762, related issue #9157
If the command is not complete, for example: az account sho, press TAB, cli loads all modules, which takes nearly 1s. It gets worse if user installs many extensions. This make autocomplete slow.
This PR prevents module loading in autocomplete mode.
Testing Guide
az acco and az account sh should be faster.
Measure-Command { $env:COMP_LINE=1; az account sh}
TotalMilliseconds : 1062.82

Measure-Command { Remove-Item Env:\COMP_LINE; az account sh}
TotalMilliseconds : 1934.4686

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Core


Double loading issue in Firefox

New case as the specific scenario in issue 10 may have been separate, but I apologize if this is a duplicate case. After removing the script type(as described in issue 14), I do observe the duplicate script issue. The script seems to be loaded twice as a resource, which doesn't necessarily offend me, but is also executing twice and producing some erratic behavior.
The locally run test suite on the master branch is linked below:
http://screencast.com/t/md25yTKX

I've just tested the demo in version 1.0.2 and it always load each file twice.
My test was on IE8, FF3.6, Chrome 14.0.835.202.
In the Network area of each browser, appears the file loaded twice and the second file is not cached. When the first file completes loading, it starts again and always get a 200OK status.
Hope the explanation helps for the bug tracking.

Sounds like you need cache headers.


setting codeBundleId after initializing bugsnag on iOS does not get reported on errors

Description
Setting the codeBundleId after JS initialization does not get reported for javascript errors on iOS.
Issue
Related issue
https://github.com/bugsnag/bugsnag-react-native/issues/91
After we initialize bugsnag with the Client(config) instance, we will set the codeBundleId sometime in the near future via
bugsnag.config.codeBundleId.
When errors are reported on this codepush bundled version of the app, Android contains the correct codeBundleId, but iOS is missing this info on all errors...
Note: This at one point was working for us.
Environment
Library versions:
├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>└─<EMAIL_ADDRESS>

cocoapods version (if any) (pod -v): 1.5.3

iOS/Android version(s): all iOS versions

simulator/emulator or physical device?: physical

debug mode or production?: production

[x] (iOS only) [BugsnagReactNative start] is present in the
application:didFinishLaunchingWithOptions: method in your AppDelegate
class?

[x] (Android only) BugsnagReactNative.start(this) is present in the
onCreate method of your MainApplication class?

This is our file that handles all things bugsnag... the error happens when other code calls
CodePush.getUpdateMetadata()

and then calls into this file's setCodePushRelease() function to set the codeBundleId
Example code snippet
import { Client, Configuration } from "bugsnag-react-native";
import { createSelector } from "reselect";
import { getUserEmail, getUserFullName, getUserId } from "../../selectors/user";

import { cloneAndRemoveEmpty } from "../method-helpers";

let bugsnag = null;

function identifyUser() {
  identifyUserWithDetails(reduxStore.getState());
}

export function initBugsnag() {
  if (bugsnag) {
    console.log("bugsnag is already initialized. will return");
    return;
  }

  const configuration = new Configuration();
  configuration.autoCaptureSessions = true;
  configuration.consoleBreadcrumbsEnabled = true;

  configuration.registerBeforeSendCallback((report, error) => {
    if (__DEV__) {
      console.log(
        "Bugsnag caught an error, but we are a debug build, so we will not send the error to bugsnag",
        error
      );
      return false;
    }

    const sanitizedStore = sanitizeStore();

    report.metadata = {
      ...report.metadata, // merge existing metadata that could have been added by other callbacks
      sanitizedStore
    };
    return true;
  });
  bugsnag = new Client(configuration);

  console.log(
    "[Bugsnag] - initBugsnag(). Will subscribe to the root.store"
  );
  reduxStore.subscribe(identifyUser);
  identifyUser();
}

export function setCodePushRelease(codeBundleId) {
  if (bugsnag) {
    console.log("setting the bugsnag codepush config == ", codeBundleId);
    bugsnag.config.codeBundleId = codeBundleId;
  }
}

export function notifyHandledError(error) {
  if (!bugsnag) {
    console.error(
      "[Bugsnag] - trying to notify an error before bugsnag is initialized",
      error
    );
    return;
  }
  if (typeof error === "string") {
    bugsnag.notify(new Error(error));
  } else {
    bugsnag.notify(error);
  }
}

/**
 * Removes properties from the redux store that are too big, or bugsnag reports won't care about
 */
function sanitizeStore() {
  const sanitizedStore = cloneAndRemoveEmpty(reduxStore.getState());
  delete sanitizedStore.locations;
  return sanitizedStore;
}

let loggedIn = false;
const identifyUserWithDetails = createSelector(
  [getUserEmail, getUserFullName, getUserId],
  (email, name, id) => {
    if (email && name && id && bugsnag) {
      console.log("Bugsnag - identifying the user", email, name, id);
      bugsnag.setUser(`${id}`, name, email);
      loggedIn = true;
    } else if (loggedIn && bugsnag) {
      try {
        bugsnag.clearUser();
      } catch (err) {
        console.error("Error trying to log out of Bugsnag");
      }
      loggedIn = false;
    }
  }
);

closing this as it the errors seem to be showing up correctly on the dashboard all the sudden... Must have been an intermittent issue with the dashboard

Is this the correct way to do this?  Seems a bit iffy to at a later stage mutate a configuration object that was already used to instantiate the client.


As a user I can create a task without a specific start time and deadline

So that I can create a task with little details

Duplicate of #6


User/silindbl/include volume id mount

Adds a volume/pv id to the mount calls, so we can reject mounts for PVs that already exists.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-3 of 6 (50.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 76.881%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/blob/nodeserver.go
0
1
0.0%

pkg/edgecache/manager.go
3
5
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.008%

Covered Lines:
2248

Relevant Lines:
2924

💛  - Coveralls


Add backend validation while sending ready send invoce email to client

Describe the task
When invoice email is being sent to the client,  requesting payment for the project work, there is no backend validation.
We require backend validation before sending invoice email to the client.

Breakdown

[ ] On submitting the form make a ajax call in JS instead of normal PHP submit. This will prevent the page to get reload Reference Link
[ ] Check how you can pass URL from PHP to JS as ajax call will make a request to this URL. For this, you may need to check the data attribute
[ ] When the form data is submitted from Ajax, you will either get success or error.
[ ] For errors, check how you can get errors in ajax call
[ ] Once you get an error, show the errors in the modal. Till now your modal should also remain opened
[ ] If you don't get the error then close the modal and show a success message for maybe 5 seconds. (Need to check how to close modal using js, You will need to check bootstrap elements for this step)
[ ] In the backend part where you are receiving the ajax request, instead of returning a view, return a normal text message which will tell you if your data is processed successfully or not.

Laravel Validation - Link


Gate Authorization Not Work With Before System

Laravel Version: #.#.# 7.x
PHP Version: #.#.# PHP 7.4.6 (cli) (built: May 12 2020 11:38:52)
Database Driver & Version: Ver 8.0.20 for Win64 on x86_64 (MySQL Community Server - GPL)

Description:
The framework not load correctly authorization with before function in authserviceProvider boot funct. User gate system work only in blade (@can()) and in controller and component with (Gate::inspect('manage.case')). If we use (auth()->user()->can()) return false.
Steps To Reproduce:

make a roles.php in config as follow:

/*
  |--------------------------------------------------------------------------
  | Application Roles
  |--------------------------------------------------------------------------
  |
  | This value is the Roles of your application. This value is used when the
  | framework needs to place the application's Roles.
  |
  */

return [

    /**
     * |-----------------------
     * | Admin Roles */
    'admin' => [

        'manage.case',
        'delete.case',
        'create.ticket.owner',
        'use.reply.template',
        'use.markdown.reply',
        'change.reply.status',

    ],

    /**
     * |-----------------------
     * | Staff Roles */
    'moderator' => [

        'manage.case',
//        'create.ticket.owner',
        'use.reply.template',
        'change.reply.status',
    ],

    /**
     * |-----------------------
     * | Staff Roles */
    'staff' => [

    ],

    /**
     * |-----------------------
     * | User Roles */
    'user' => [

        'update.profile',

    ],
];

Then, create user with 1 column ROLE & default moderator or any. Once done, make the policy in AuthServiceProvider:

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Gate;

class AuthServiceProvider extends ServiceProvider
{
    /**
     * The policy mappings for the application.
     *
     * @var array
     */
    protected $policies = [
        // 'App\Model' => 'App\Policies\ModelPolicy',
    ];

    /**
     * Register any authentication / authorization services.
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();

        Gate::before(function ($user) {
            foreach (config("roles.{$user->role}") as $ability) {
                Gate::define($ability, function ($user) use ($ability) {
                    return in_array($ability, config("roles.{$user->role}"));
                });
            }
        });
    }
}

Fine, now test the Blade gates and authorization:

@can('create.ticket.owner')
your code
@endcan

Now blade work , check routes:

    Route::post('case/{id}/reply', 'ReplyCase')->middleware('can:create.ticket.owner');

Fine, all work, try to dump data from controller:
class ReplyCase extends Controller
{
    public function __invoke(Request $request)
    {
        dd(Gate::inspect('manage.case')->allowed()); // Work, return true
        dd(auth()->user()->can('manage.case')); // Not Work, return false

We already tell u the bug: https://github.com/laravel/framework/discussions/33065
Please check this asap

Please, help us. We can not use this gate also in event and model as follow:
    /**
     * Handle the event.
     *
     * @param Created $event
     * @return void
     */
    public function handle(Created $event)
    {
        $users = \App\User::where('role', '!=', 'customer')->get();

        foreach ($users as $user) {
            if ($user->can('manage.case')) Notification::send($users, new TicketCreated($event->ticket));
        }
    }

The ability return always FALSE

If help, we have tried to not use before function, and work:
roles.php
return [
    'manage.user.category' => [
        'admin',
    ],
    'manage.category' => [
        'admin',
    ],
    'reopen.case' => [
        'admin',
        'moderator',
    ],
    'manage.case' => [
        'admin',
        'moderator',
    ],
    'restore.case' => [
        'admin',
        'moderator',

    ],
    'erase.case' => [
        'admin',
    ],
    'delete.case' => [
        'admin',
        'moderator',
    ],
    'create.ticket.owner' => [
        'admin',
        'moderator',
        'staff'
    ],
    'create.reply.template' => [
        'admin',
        'moderator',
    ],
    'use.reply.template' => [
        'admin',
        'moderator',
    ],
    'use.markdown.reply' => [
        'admin',
        'moderator',
    ],
    'change.reply.status' => [
        'admin',
        'moderator',
    ],
];

AuthServiceProvider :
    /**
     * Register any authentication / authorization services.
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();

        foreach (config("roles") as $ability => $content) {
            Gate::define($ability, function ($user) use ($ability) {
                return in_array($user->role, config("roles")[$ability]);
            });
        }

        dd(Gate::abilities());
    }

But we want use before function. For now before function not work with user()->can()

Please don't re-open issues moved to discussions. Try a support channel instead:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC
Thanks.

Wat? Channel not help us and this is a problem in deep