looker-open-source / look-at-me-sideways Goto Github PK
View Code? Open in Web Editor NEWA style guide and linter for Looker's LookML data modeling language
License: MIT License
A style guide and linter for Looker's LookML data modeling language
License: MIT License
Hi Team,
Thanks for creating LAMS, it's a wonderful tool that we are planning to use. I had 2 suggestions:
--output-to-cli
but that does not seem to output all the error, instead it caps out at around 300 errors and displays xx
more errors at the end. Our use case is that we want to display all the errors at pipeline failures.manifest.lkml
file that is not in the looker project repository? The use case is that we want to have a central manifest.lkml
for all our Looker projects that define all our custom linting rules.Thanks
Hi @fabio-looker ,
Is there a way while implementing LAMS, we can exclude a particular folder from Looker project that won’t be checked for LAMS rules.
If a PK dimension, in addition to following the naming convention, were to use the following sql comment:
dimension: pk1_user_id {
hidden: yes
sql: ${TABLE}.id /*pk1*/ ;;
}
Then dev users looking to troubleshoot a query could quick evaluate the cardinality of its joins by looking at the SQL alone.
Not sure on this one, it may be a bit of a stretch in terms of which audience will see which information, but I found myself trying to debug a difference in a query while developing and not having this in the SQL query meant I would have to go look up each join in the explore to double-check their logic.
Github Actions is failing with the following error message:
npm ERR! cipm can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
This is perhaps a new behavior in npm/github actions, but is certainly triggered by my rather creati ve setup npm-shrinkwrap setup...
We have a view from a derived table
view: currency_selector {
derived_table: {
sql:
SELECT 'USD' AS currency
UNION ALL
SELECT 'EUR' AS currency
UNION ALL
SELECT 'GBP' AS currency
UNION ALL
SELECT 'AUD' AS currency
UNION ALL
SELECT 'CAD' AS currency;;
}
dimension: currency {
type: string
hidden: yes
sql: ${TABLE}.currency ;;
}
parameter: currency_selector {
suggest_dimension: currency
}
}
which we are using to dynamically populate currency types and symbols in another view(s)
view: payment_ledger {
...
dimension: general_currency {
type: number
sql: CASE WHEN {% parameter currency_selector.currency_selector %} = 'EUR' THEN ${amount_eur}
WHEN {% parameter currency_selector.currency_selector %} = 'USD' THEN ${amount_usd}
WHEN {% parameter currency_selector.currency_selector %} = 'GBP' THEN ${amount_gbp}
ELSE ${amount_usd}
END;;
html: {{ currency_symbol._value }}{{ rendered_value }} ;;
value_format_name: decimal_2
}
dimension: currency_symbol{
type: string
hidden: yes
sql: CASE
WHEN {% parameter currency_selector.currency_selector %} = 'EUR' THEN '€'
WHEN {% parameter currency_selector.currency_selector %} = 'GBP' THEN '£'
WHEN {% parameter currency_selector.currency_selector %} = 'USD' THEN '$'
END;;
}
measure: total_other_actual {
sql: ${general_currency} ;;
type: sum
value_format_name: big_money
filters: [currency: "-USD, -EUR, -GBP", ledger_entry_type_description: "Actual"]
html: {{ currency_symbol._value }}{{ rendered_value }} ;;
}
would this quality as a tightly coupled view
per F1? is there a better way to do this? thanks for the clarification on the last issue btw.
We just open sources our CircleCI build, while I'm not an engineer it might be worth someone who is adding it into the mix here.
https://github.com/renewdotcom/renew-looker-template/tree/master/.circleci
Looker 6.16 now allows a folder structure to be present. LAMS currently does not see files that are in subfolders.
https://docs.npmjs.com/files/shrinkwrap.json.html
The recommended use-case for npm-shrinkwrap.json is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs
I tried the global rule exception syntax in manifest file, But I still get errors related to those rules. Am I missing anything?
Tried below syntaxes:
1)
# LAMS
# rule_exemptions: {
# K4: "Rule not Required"
# }
# LAMS
# rule_exemptions: {
# F2: "Rule not Required"
# }
# LAMS
# rule_exemptions: {
# k4,F2,F3,T1,T2: "Rule not Required"
# }
Please help me implement these exemptions.
I am getting the below error
error: {
toString: [Function: toString],
message: 'Expected "#", "expr", "html", "sql", "}", [ \t\n\r], or [\-+_a-zA-Z0-9.] but "," found.',
expected: [Array],
found: '[',
location: [Object],
name: 'SyntaxError',
context: ''
},
_file_path: 'manifest.lkml',
_file_rel: '',
_file_name: '',
_file_type: 'manifest'
},
Hello, I came across some unexpected behavior while running LAMS on my code.
I traced it back to what I think are some issues in the code, but I'm not familiar with js (or with LookML for that matter), so I'm not 100% sure.
See the the test.lkml
below;
view: my_view {
sql_table_name: my_db.table ;;
dimension: something {
primary_key: no
hidden: yes
type: number
sql: ${TABLE}.id ;;
}
}
Following the definitions of K1 and K2 as per docs/rules.html
K1... No Primary Key Dimensions found in my_view
, which is the expected result.primary_key: yes
and renaming the dimension to pk1_something
raises no error, which is the expected result.primary_key: yes
still leads to a K1 error, while I would expect it to be a K2.pk1_something
raises no error, while I would expect a K1Looking at the code, it looks like the primary_key
field is never actually looked at.
In rules/k1-2-3-4.js
, primary keys are implicitly defined as fields matching the pkNamingConvention
filter, even when $dim.primary_key
is false.
(The regex used in pkNamingConvention
is itself not consistent with the documentation, see issue #63.)
(If you are open to external PRs, I may have some time for this one)
Hi
I have a question about the style rule F3. Is there any explanation of why this rule is valid? I have checked it in the latest version of Looker and it doesn't look like that looker is using COUNT(*) syntax anymore.
Is it possible that this rule is obsolete? or it is connected to specific database?
Thank you
Adrian
Looker 6.8 added a new field reference syntax like ${field::type}
Several rules, for example F1 and E1, depend on pulling references out of SQL strings, and will need to be reviewed.
Hello,
I created a Dockerfile with the following:
FROM alpine
RUN apk update
RUN apk add --update nodejs nodejs-npm git openssh-client vim-nox
WORKDIR /root/
RUN git clone [email protected]:my_repo/my_looker.git
RUN ls -l /root/my_looker
WORKDIR /root/
RUN git clone https://github.com/looker-open-source/look-at-me-sideways.git
RUN ls -l /root/look-at-me-sideways
RUN ls -l /root
WORKDIR /root/look-at-me-sideways
RUN npm install
WORKDIR /root/my_looker
RUN node /root/look-at-me-sideways
Then i run the docker and:
~ # pwd
/root
~ # ls -l
total 8
drwxr-xr-x 1 root root 4096 Sep 6 16:01 look-at-me-sideways
drwxr-xr-x 4 root root 4096 Sep 6 16:00 my_looker
~ #
All looks ok, but then:
~ # cd my_looker/
~/my_looker # node ../look-at-me-sideways/
~/my_looker #
But it's not doing anything...
Help is greatly appreciated!
We use LAMS with at some repositories where we use pull requests (PR). Each time we close a PR we get merge conflicts with the existing ones caused by the file issues.md
.
The problem is that each branch is writting the line with the date and that causes the conflicts. The line is:
<p style="text-align:right;color:#cccs">
Generated Mon, 22 Jun 2020 15:39:09 GMT
</p>
It is possible to configure it so that LAMS does not write the date on the issues.md
? I think that the best solution will be to have a parameter to disable the date.
LAMS is reporting a false positive on the F1 rule for a derived table using parameters.
Detailed error: linkback references another view, if linkback_type, via {% if linkback_type._parameter_value == "Client" %}
The full dimension code is:
dimension: linkback {
sql: TRUE ;;
html:
{% if linkback_type._parameter_value == "Client" %}
<p>Thank you for logging in!</p>
<p><a href="https://<redacted>/client/{{ client_id._parameter_value | replace:'$','-' }}">Return to dashboard</a></p>
{% endif %}
;;
}
@fabio-looker - apologies for a somewhat direct message here, but I've spent some time digging here and can't seem to find what's going / don't have the relevant expertise. Our last successful lint was 8 days ago (1/20), our next run wasn't until 1/26, but that run and all subsequent have failed with an error that looks like the one below.
I didn't see any new recent lams commits, but based on the error I suspected some issue with the the Object's value's not being available, which I thought might be parser related. I see a commit 7 days ago in lookml-parser. It looks harmless. I re-installed lams locally and confirmed the same error was occurring with a fresh install. I downloaded [email protected] and replaced the contents of the lams lookml-parser directory locally (which had 6.4.1) with the 6.4.0 contents. Unfortunately, this didn't solve the problem. I tried 6.3.0 as well, and rather than an error in F1, it passed through to K1-2-3-4 until erroring with a similar issue.
I'm not quite sure where to go from here, but things seem a bit broken. We rely on some custom lint rules so I hope you can point me in the right direction!
I currently have 2 custom rules in my manifest file. One works which is the production connection check:
# rule: prod_connection {
# description: "Models must not use sandbox to deploy"
# match: "$.model.*"
# expr_rule: ( $boolean($match "sandbox^" ::match:connection) ) ;;
# }
But the second one doesn't work. It is supposed to check if the type is available, but I tried writing it as the example here:
# rule: types_required {
# match: "$.model.*.view.*['dimension','measure'].*"
# description: "Fields must specify a type"
# expr_rule: ( !== ::match:type undefined ) ;;
# }
But this doesn't work. To make sure that the lookml code isn't the issue, I tried changing the rule slightly since I'm sure I have dimensions and measures that are not type "string":
# rule: fields_must_have_type {
# description: "All dimensions and measures must have a type defined"
# match: "$.model.*.view.*['dimension','measure'].*"
# expr_rule: ( !== ::match:type "string" ) ;;
# }
Do you have any insights on why this rule is not working?
Thank you
Extended views are currently treated as separate views even when they are inheriting the underlying lookml code from the base view... i.e. if the base view has a description defined, the extended view doesn't require it and the explore will surface the description but lams will still throw an error.
Intended error message: Unsupported model name: <model-name>. Model names must be alphanumeric or underscores only
Repro with an unsupported model name
We have multiple joins which use the PK field of a given view and the Foreign Key to generate the correct join but LAMS keep saying in those scenarios that no PKs dimensions used for a given view in a given join, an example is the following explore
include: "/views/items.view"
include: "/views/organizations.view"
include: "/views/addresses.view"
explore: invoices {
view_name: items
join: organizations {
type: inner
relationship: one_to_one
sql_on: ${organizations.pk1_organization_id} = ${items.organization_id};;
}
join: addresses {
view_label: "Organization Address"
type: inner
relationship: one_to_one
sql_on: ${organizations.address_id} = ${addresses.pk1_address_id};;
}
}
For those two joins, it says that for example in the addresses join we didn't use a PK for the organizations
view but we don't want to use the PK in this case since we want to join using the address_id
on the organization and not his Primary Key.
I think that this could be fixed if LAMS would support/introduce Foreign Key as it does with PrimaryKey (name convention?) and here https://github.com/looker-open-source/look-at-me-sideways/blob/master/rules/e2.js#L80 where it checks if the name matches the PK regex it could also check if not matches the PK regex check if it matches the Foreign Key regex.
Maybe we're missing something in our LookML files but as far as I could understand LAMS always expect an one_to_one join to be between two PKs instead of one PK and an FK.
Do i still need to specify a filter in the case of something like
measure: count {
type: count
drill_fields: [detail*]
}
# ----- Sets of fields for drilling ------
set: detail {
fields: [
pk1_app_foo_relation_id,
bar_company_code_name,
foo_detail_name,
pt_current_term_name,
company_name,
bar_name,
name,
foo.count
]
}
}
I am writing a few custom rules that fit our requirements and one of them needs to refer to two paths. I want to check if the type is yesno and if it is, then check if the dimension name ends with a _flag.
I tried changing the path inside the expression but that doesn't work either. Any tips on how to write this?
LAMS fails on branches with forward slashes in the name.
LAMS is reporting false positive(s) for PKs missing in a SQL join statement where most PKs are used in equality constraints with matching PKs and one PK is constrained against a string surrounded in single quotes.
Sample failing input:
explore: test_explore {
join: join_view {
relationship: one_to_one
type: inner
sql_on:
\${test_explore.pk1_id} = \${join_view.pk2_id} AND \${join_view.pk2_category} = 'TEST' ;;
}
}
Sample LAMS response:
<tr>
<td>⛔</td>
<td>model:test_model/explore:test_explore/join:join_view </td>
<td>test_explore's PK pk1_id is not used in an equality constraint in join_view join</td>
</tr>
<tr>
<td>⛔</td>
<td>model:test_model/explore:test_explore/join:join_view </td>
<td>join_view's PK pk2_id is not used in an equality constraint in join_view join</td>
</tr>
<tr>
<td>⛔</td>
<td>model:test_model/explore:test_explore/join:join_view </td>
<td>join_view's PK pk2_category is not used in an equality constraint in join_view join</td>
</tr>
Sample failing input 2:
explore: test_explore {
join: join_view {
relationship: one_to_many
type: inner
sql_on:
\${test_explore.pk1_id} = \${join_view.pk2_id} AND \${join_view.pk2_category} = 'TEST' ;;
}
}
Sample LAMS response 2:
<tr>
<td>⛔</td>
<td>model:test_model/explore:test_explore/join:join_view </td>
<td>test_explore's PK pk1_id is not used in an equality constraint in join_view join</td>
</tr>
Is it possible to set granular exemptions for custom rules? I tried something like this, but it didn't seem to work:
# LAMS
# rule_exemptions: {
# my_custom_rule: "2018-11-12 - I can't use datagroups for this super special reason and Bob said it's ok"
# }
index.js to export a function that CLI calls, then tests can more easily test the index function
Sharing my Gitlab CI setup (which was a quick project);
Created a simple Dockerfile to wrap look-at-me-sideways
FROM alpine:edge
WORKDIR /opt/lams
RUN apk --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/testing/ upgrade && \
apk --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/testing/ add \
nodejs nodejs-npm
RUN npm i -g @looker/look-at-me-sideways --unsafe-perm
CMD ["/bin/sh"]
This image is stored in the registry; (registry.example.com/look-at-me-sideways-bot)
Created a gitlab-ci.yml
file in the LookML repo
stages:
- 👀 Look at me sideways
Lint:
stage: 👀 Look at me sideways
image:
name: registry.example.com/look-at-me-sideways-bot
entrypoint: [""]
script:
- lams --reporting=no --output-to-cli
artifacts:
expire_in: 2 weeks
when: always
paths:
- issues.md
when: on_success
allow_failure: true
On every commit, lams will run an saves the issues.md
in the Gitlab CI artifacts.
Thanks for releasing v2! I am trying to introduce LAMS in CI.
First, I tried to exempt all the current errors, but I just couldn't exempt the T2
rule.
According to the source code, I need to exempt all T2~T10. When I exempted all of them, I was able to exempt the error as expected. Is this the intended behavior?
look-at-me-sideways/rules/t2-10.js
Lines 11 to 31 in 9450155
manifest.lkml:
# LAMS
# rule_exemptions: {
# T2: "We may have to deal with this later."
# T3: "We may have to deal with this later."
# T4: "We may have to deal with this later."
# T5: "We may have to deal with this later."
# T6: "We may have to deal with this later."
# T7: "We may have to deal with this later."
# T8: "We may have to deal with this later."
# T9: "We may have to deal with this later."
# T10: "We may have to deal with this later."
# }
If I exempt them in manifest.lkml
, I don't notice that the number of errors increases afterward. Therefore, I tried the per-error exemption, but it did not work.
I think the reason is that !exempt('')
always returns true
. Is it possible to have a per-error exemption for T2
rule?
look-at-me-sideways/rules/t2-10.js
Lines 129 to 138 in 9450155
For the last few days I have been applying some custom rules to my LookML code and I've come across an issue.
When trying to use the match $.model..view.[dimension,measure].*, it returns an error saying "Error in custom rule definition", which doesn't happen when taking the last section out, or referencing to just either a dimension or a measure. I could split the rules into the same one separated by dimension and measure, but that also didn't return any errors or warnings (the view had mistakes so I could test it). But it also didn't return the initial "Error in custom rule definition" error.
Is there another way to write the path to all dimensions and measures? Or a way to get around this?
In model-level rules, the path is currently constructed as ...files/${modl_name}.model.lkml
. Need to switch to using full file path for subdirectory support
Was working with @jamesastone at JOIN and saw that save
was not working for him. Need to investigate
Hello,
As of 11/16/2020 GitHub disabled the use of set-env commands (link). This causes LAMS set up through GitHub actions to have issues running properly.
Documentation for LAMS GitHub Actions here
This can be resolved here by updating:
run: lams --reporting=... || echo "::set-env name=ERROR::true"
to
run: lams --reporting=save-no || echo "ERROR=true" >> $GITHUB_ENV
Documentation from GitHub for setting environment variables: here
Comments in MySQL have to have a space between the --
and the remainder of the line, so T8 (which requires ---
to separate the PKs from the rest of the columns) may need to allow some alternatives
The regex matches 1pk_id
or pk1_id
, but not pk_id
whereas the style guide says "n ... may be omitted if it is 1, and key_name is any descriptive name."
look-at-me-sideways/rules/k1-2-3-4.js
Line 25 in f09db4e
I suggest using ^([0-9]+pk|pk[0-9]+|pk)_([a-z0-9A-Z_]+)$
hi @fabio-looker -
we're getting this parsing error
Parsing error: Object.fromEntries is not a function
and i can't tell where it's coming from.
im not seeing any errors on the CLI output itself..
Run lams --reporting=save-yes --source **/{views/core/catalog_items/dim_catalog_items.view.lkml,manifest.lkml} || echo "ERROR=true" >> $GITHUB_ENV
Parsing project...
> Issues occurred during parsing (containing files will not be considered. See messages for details.)
> Parsing done!
Checking rules...
> E1
> E2
> F1
> F2
> F3
> F[4](https://github.com/DrizlyInc/data-looker/runs/5142238622?check_suite_focus=true#step:7:4)
> K1-2-3-4
> T1
> T2-[10](https://github.com/DrizlyInc/data-looker/runs/5142238622?check_suite_focus=true#step:7:10)
> Rules done!
Writing issues.md...
> issues.md done
any thoughts on what could be going wrong here?
Possible enhancement...
As I recently discovered, for strictly typed dialects like BigQuery, updating the type of a column/field can be very difficult since you don't know where that field is referenced in join constraints.
So for example, the following could throw an error:
explore: a {
join: b {sql_on: ${b.pk1_b_id} = ${a.b_id} ;;}
}
view: a { dimension: b_id {type:string}}
view: b { dimension: pk1_b_id {type:number}}
As stated, this would the first linter-enabled rule that is not strictly locally scoped. (Contrast with PK rules which are mediated by a naming convention, so they are implementable as two separate rules, one which checks local conformance to the naming convention, and another which checks local conformance given the name).
Alternately, we could encourage defensive application of the new LookML type coercion operator (::type), if that operator does not apply unnecessary conversions when the field is already of the desired type, like so:
explore: a {
join: b {sql_on: ${b.pk1_b_id::number} = ${a.b_id::number} ;;}
}
view: a { dimension: b_id {type:string}}
view: b { dimension: pk1_b_id {type:number}}
I'm not sure which I would recommend, but wanted to create a place to discuss
You're using naming convention to check both K1 and K2 at the same time, while K1 should be checked basing on if there's a dimension that has a primary key attribute set to yes
Hi, is the library failing for anyone else?
This is my first time using it and I'm already running into problems when I'm trying to run it.
Commands i run:
sudo npm install -g @looker/look-at-me-sideways
lams
error message on lams command:
/usr/local/lib/node_modules/@looker/look-at-me-sideways/cli.js:22
.map(([k, v])=>[k.replace(/[-_][a-zA-Z-0-9]/g, (s)=>s.slice(1).toUpperCase()), v])
^
SyntaxError: Unexpected token [
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
at Object.Module._extensions..js (module.js:417:10)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Function.Module.runMain (module.js:442:10)
at startup (node.js:136:18)
at node.js:966:3
Seems that the latest deployment itself has a failing CI build, could that be reason why? 77b2ba0
We have added LAMS to our project and have found that some reported issues were due to views that don't even exist in our codebase, digging into it I discovered that those views come from the lookml-parser dependency that includes them to be linted with the project (i.e. https://github.com/fabio-looker/node-lookml-parser/blob/9cf49326ece2bd9834535bf77cec1087554ccbfe/test-projects/002-ndt/ndt.view.lkml)
Also when created a new project and LAMS is added it fails to run because of those same views that the parser is including, it raises the following error ⬇️
TypeError: Cannot read property 'match' of undefined
at pkNamingConvention (/home/marcelolx/looker/node_modules/@looker/look-at-me-sideways/rules/k1-2-3-4.js:28:23)
at Array.filter (<anonymous>)
at module.exports (/home/marcelolx/looker/node_modules/@looker/look-at-me-sideways/rules/k1-2-3-4.js:38:61)
at module.exports (/home/marcelolx/looker/node_modules/@looker/look-at-me-sideways/index.js:111:17)
at async /home/marcelolx/looker/node_modules/@looker/look-at-me-sideways/cli.js:26:2
error Command failed with exit code 1.
And when checking why it fails I can see that it fails on a dimension from the view that only exists in lookml-parser
{
'$strings': [
'@$type',
':',
' ',
'@$name',
' ',
'{',
[ 'hidden', 'hidden', ':', ' ', '@' ],
'}'
],
'$type': 'dimension',
'$name': 'user_id',
hidden: true,
'$view': 'user_90_day_facts'
}
I have created a project if that helps https://github.com/marcelolx/looker
Add Object_values
, Object_keysand
Object_entries` to Liyad to make use cases like #30 more straightforward
If an exemption exists at the entire project level, we could check for that at the beginning of our rules files and return early, thus eliminating some looping and improving performance for those cases
TypeError: Cannot read properties of undefined (reading 'url')
at /c/dev/work/node/node-v16.13.2-linux-x64/lib/node_modules/@looker/look-at-me-sideways/rules/f1.js:44:59
at Array.map (<anonymous>)
at module.exports (/c/dev/work/node/node-v16.13.2-linux-x64/lib/node_modules/@looker/look-at-me-sideways/rules/f1.js:44:46)
at module.exports (/c/dev/work/node/node-v16.13.2-linux-x64/lib/node_modules/@looker/look-at-me-sideways/index.js:131:26)
at async /c/dev/work/node/node-v16.13.2-linux-x64/lib/node_modules/@looker/look-at-me-sideways/cli.js:28:2
Running into an issue when lams tries to parse a dimensions link property. Specifically
dimension: key {
label: "Key"
#group_label: "Jira"
type: string
sql: ${TABLE}.key ;;
link: {
url: "http://@{COMPANY_DOMAIN_JIRA}.atlassian.net/browse/{{ value }}"
label: "View in Jira"
}
}
If I comment this out lams runs fine.
Thanks @fabio-looker for LAMS, my team at mercari.com has found it really useful to help us write maintainable SQL and LookML.
Ran into an interesting case that my team couldn't figure out until we debugged LAMS. :-)
We expected this to pass the linter:
WITH
step_1 AS (
SELECT
account_id AS pk1_account_id
---
, COUNT(*)
FROM users
GROUP BY 1
)
, step_2 AS (
SELECT
pk2_tenant_id
, pk2_user_id
---
, MAX(start) as last_login
FROM sessions
GROUP BY 1,2
)
SELECT "foo" as bar
but got an error saying that the second CTE had mismatching primary key field counts:
Primary Key columns in " SELECT pk2_ten" in foo declare 2 column(s), but there are 1
It turned out this works if we use trailing commas, so that's a fine workaround:
WITH
step_1 AS (
SELECT
account_id AS pk1_account_id,
---
COUNT(*)
FROM users
GROUP BY 1
)
, step_2 AS (
SELECT
pk2_tenant_id,
pk2_user_id,
---
MAX(start) as last_login
FROM sessions
GROUP BY 1,2
)
SELECT "foo" as bar
But the root cause seems to be that the rule parser is only replacing ---
once, so it misses the second one. I put together a quick diff w/ a test and will submit a pull request.
Hi @fabio-looker ,
Currently I have put an exception for rule [F4.]Non-hidden fields should have descriptions. in the manifest file.
I would like to implement a rule to make it mandatory to include description for all explores in every model.
Can I declare this custom rule in manifest file? If yes, would you please help me with the syntax?
If no, then can it be done using javascript ? Also, please help me with that syntax too.
Thanks,
Priyanka
I'm looking to implement LAMS for a large logistics firm with an enterprise Github account hosted on-prem. Currently the account/repo environment variables passed to the LAMS docker container during build assume the user's github account is hosted by github (https://github.com/<ACCOUNT_NAME>/<REPO_NAME>/). How can I help make it possible to integrate LAMS with github accounts not hosted by github (https://github.<ENTERPRISE_NAME>.com/<ACCOUNT_NAME>/<REPO_NAME>/)? Is it just the look_at_me_sideways_config.xml file that needs to change? Is it reasonable that enterprise github accounts would follow the same url format https://github.<ENTERPRISE_NAME>.com/ ?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.