search

regro / cf-scripts

Flagship repo for cf-regro-autotick-bot
Other
48 stars 72 forks source link

A path to handling ironically "strict" YAML #653

Open bollwyvl opened 4 years ago

bollwyvl commented 4 years ago

Over on https://github.com/conda-forge/yamllint-feedstock/pull/18 I pulled out a feature of that feedstock where we used yamllint to lint its own recipe. To get there, we used this construction:

package:
  name: '{% set name = "yamllint" %}{{ name }}'
  version: '{% set version = "1.15.0" %}{{ version }}'

... but the bot couldn't find the version bump, even when upstream packages were dropping, so we were merrily building that version over and over again.

I'd like to be able to add that typographic feature: while not all conda recipes can be clean-as-the-driven-snow YAML, a lot could be, and could benefit from the tooling being able to be linted. A longer con would be adding an opt-in yamllint: true to the bot, I suppose...

bollwyvl commented 4 years ago

(I have not xonsh'd in anger, and would appreciate a pointer to where to look in this repo to start)

CJ-Wright commented 4 years ago

I think you need to add your string template to the regex for finding the version and

CJ-Wright commented 4 years ago

Most likely the thing that is tripping the bot up is the quotations. If you have a regex to fix that would you mind adding it to the checksum logic? That way we could address https://github.com/regro/cf-scripts/issues/529

bollwyvl commented 4 years ago

Great, thanks! I'll look into it!

On Tue, Oct 15, 2019, 10:02 Christopher J. Wright notifications@github.com wrote:

Most likely the thing that is tripping the bot up is the quotations. If you have a regex to fix that would you mind adding it to the checksum logic? That way we could address #184 https://github.com/regro/cf-scripts/issues/184

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/regro/cf-scripts/issues/653?email_source=notifications&email_token=AAALCRDNKCQD66MPP6YJCLLQOXEPRA5CNFSM4JA4UEG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBI34OY#issuecomment-542228027, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALCRA446YHIWOJTOWSGPDQOXEPRANCNFSM4JA4UEGQ .

bollwyvl commented 4 years ago

It's looking like I can't exactly have the syntax I used work for both conda-build and the bot, but my original goal of pure-YAML (is there such a thing) DRY recipes can be made to work, with the broadly supported:

package:
  name: |-
    {% set name = "yamllint" %}{{ name }}
  version: |-
    {% set version = "1.18.0" %}{{ version }}

As to the quoted shas (which are probably a good idea)... still tinkering. Might need extra patterns...

bollwyvl commented 4 years ago

Alas, the bot swallows {{version}} above...

wolfv commented 4 years ago

I agree that having the variables being expressed as yaml itself would be a nice benefit.

A syntax like this:

variables:
  version: 3.21.2
  name: my_package

would, in a way, make more sense since then recipes could simply be parsed as yaml (and edited).

One other problem is that comments might get lost (even though they have meaning in conda-build...

bollwyvl commented 4 years ago

I haven't had a chance to circle back on this, unfortunately...

Well, back in the mists of time, there was strong disagreement about even including the Jinja features. The significant comments predate me by some years, though. I think that ship has sailed, though, and I wouldn't want to have a third option to contend with. Other options (azure yaml) with their multi-stage variable availability are also... Hard, but it's nice that it can be statically analyzed.

I do like https://github.com/taskcluster/json-e however, but I'm not sure it has a schema.

On Mon, Oct 28, 2019, 14:41 Wolf Vollprecht notifications@github.com wrote:

I agree that having the variables being expressed as yaml itself would be a nice benefit.

A syntax like this:

variables: version: 3.21.2 name: my_package

would, in a way, make more sense since then recipes could simply be parsed as yaml (and edited).

One other problem is that comments might get lost (even though they have meaning in conda-build...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/regro/cf-scripts/issues/653?email_source=notifications&email_token=AAALCRD5FBSVF2O7N6HOQDDQQ4W6TA5CNFSM4JA4UEG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECN634I#issuecomment-547089905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALCRC4EKQNDTUCC2XGPILQQ4W6TANCNFSM4JA4UEGQ .

wolfv commented 4 years ago

Hmm I wonder if you could do 

# {% set myvar = "whatevever" %}

so that it would be a yaml comment, but still set a jinja var?

bollwyvl commented 4 years ago

Gets eaten by conda-build render!

On Tue, Oct 29, 2019 at 12:16 AM Wolf Vollprecht notifications@github.com wrote:

Hmm I wonder if you could do

{% set myvar = "whatevever" %}

so that it would be a yaml comment, but still set a jinja var?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/regro/cf-scripts/issues/653?email_source=notifications&email_token=AAALCRFLAVS5ZY4ZKXEFFKLQQ62LDA5CNFSM4JA4UEG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECPFWXY#issuecomment-547248991, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALCRE3FHC4RWPX6C6GFEDQQ62LDANCNFSM4JA4UEGQ .