4 ms·

You lost me at YAML..

foepys 7y ago
When you are coming from Azure DevOps (previously Visual Studio Team Services) this is godsend. VSTS was only configurable via a GUI that produced an unreadable configuration file with hundreds of lines with stupidly long variable names. Then taunted this UX disaster by reminding you to comment the changes you made before saving. So each CI config had like 50 changes at the beginning of its history where you tested the configuration by making minimal changes. Eventually they started using an in-repo config file like GitLab but only supported about 20% of the GUI features. It's still abysmal. I wouldn't mind when Azure DevOps (Server) were to be replaced by GitHub (Enterprise).
stevekemp 7y ago
Same as what you have to use in gitlab, for what that's worth. But it is interesting that their existing "main.workflow" file is in a different syntax. Ahh, now I see, support for the main.workflow syntax will be removed, and you must migrate: https://help.github.com/en/articles/migrating-github-actions-from-hcl-syntax-to-yaml-syntax https://help.github.com/en/articles/migrating-github-actions...
- fingerprinter 7y ago
  That’s disappointing. The original Actions was amazing and much of that was the thoughtful main.workflow file. This feels like a regression. I’m not a yaml hater like many but main.workflow was clean, almost pleasant to use. It felt like it actually came from understanding developers.
  - tilolebo 7y ago
    I'm also disappointed, I liked using HCL for GitHub actions. Did they get negative feedback from beta users? Or is it related to the recent release of HCL2?
_frkl 7y ago
What would you like instead? Personally, for those type of things I never thought yaml was limiting in any way, but would be keen to hear what better options you think are out there. I like the simplicity and readability of yaml, as long as there's not too much logic to be expressed.
- alkonaut 7y ago
  I think the future is that all configuration is code. Code in a proper functional/imperative language (preferably the one you wrote the app code in), rather than a special declarative language. The attraction of toml is minimalistic and simple definitions initially - but there is always too much logic for these languages. If not immediately, then eventually. "Real" programming languages have good compilers, good error messages, debuggers, IDE's with syntax highlighters and so on. json/yaml/toml/xml/whatever always feels like you are poking something and then trying it, checking for errors from typos and starting over. This feels quite backwards if you are used to developing with a good strict compiler and debugger. There are projects like pulumi that provide API's for multiple languages and hook into almost any service (e.g. Azure, AWS) https://www.pulumi.com/ https://www.pulumi.com/
  - _frkl 7y ago
    Yeah, I know pulumi, and I'm working on something similar myself. Personally, in my experience, I don't think there's always too much logic, far from it. A lot of times you really only have a list of tasks that are executed one by one, and the nature of that doesn't really change. I think it's overkill to introduce a new wrapping layer in those cases (and that is what Pulumi really is, it mostly just wraps Terraform if I understand right). But yes, sometimes it's better to have 'real' code at your disposal. It's just a matter to know when's when. Like always :-) Also, debugging those yaml problems or real code doesn't really seem to make a difference for me. It's both equally annoying, and since there is a 'declarative' layer involved most of the time anyway, just a bit deeper down, debugging the 'real' issues (not typos and such -- btw. check out yamllint if you don't know it) is not any easier with wrappers like Pulumi. But maybe we have just worked on different type of complexities in our pasts. That usually explains different preferences for tooling. Just saying that this is not a thing we should/can generalize.
jclem 7y ago
Hi I'm an engineer on Actions, and a few months ago I probably would have said the same thing, but I've come around to it (and then some). We spent a ton of time working through the syntax changes in HCL, YAML, and other languages. What we found was that while HCL and other languages are amazing for expressing pure configuration, software development lifecycle and continuous integration workflows are a blend of configuration and pseudo-scripting, and we were only able to come up with a clean syntax for this in YAML. For example, although HCL supports heredocs, we felt that they suffered from readability problems versus multi-line strings in YAML when you're just trying to read through a workflow file and see what it does. There are many, many other reasons we felt that YAML was actually the right choice, and I'm optimistic others will come around to it in the same way I have.
- rtsao 7y ago
  Did you evaluate TOML and if so, what were the drawbacks you identified for the workflow use case?
  - jclem 7y ago
    From what I remember, we did look at it some, but I can't remember many specifics, unfortunately. Looking at it now, I think that it wouldn't give us some of the flexibility that we want—for example, TOML arrays can only contain values of a single type, and for the sake of brevity, there were places in our configuration where we wanted to allow you to, for example, pass either a shorthand string or an object.

When you are coming from Azure DevOps (previously Visual Studio Team Services) this is godsend. VSTS was only configurable via a GUI that produced an unreadable configuration file with hundreds of lines with stupidly long variable names. Then taunted this UX disaster by reminding you to comment the changes you made before saving. So each CI config had like 50 changes at the beginning of its history where you tested the configuration by making minimal changes. Eventually they started using an in-repo config file like GitLab but only supported about 20% of the GUI features. It's still abysmal. I wouldn't mind when Azure DevOps (Server) were to be replaced by GitHub (Enterprise).

stevekemp 7y ago

Same as what you have to use in gitlab, for what that's worth. But it is interesting that their existing "main.workflow" file is in a different syntax. Ahh, now I see, support for the main.workflow syntax will be removed, and you must migrate: https://help.github.com/en/articles/migrating-github-actions-from-hcl-syntax-to-yaml-syntax https://help.github.com/en/articles/migrating-github-actions...

fingerprinter 7y ago
That’s disappointing. The original Actions was amazing and much of that was the thoughtful main.workflow file. This feels like a regression. I’m not a yaml hater like many but main.workflow was clean, almost pleasant to use. It felt like it actually came from understanding developers.
- tilolebo 7y ago
  I'm also disappointed, I liked using HCL for GitHub actions. Did they get negative feedback from beta users? Or is it related to the recent release of HCL2?

_frkl 7y ago

What would you like instead? Personally, for those type of things I never thought yaml was limiting in any way, but would be keen to hear what better options you think are out there. I like the simplicity and readability of yaml, as long as there's not too much logic to be expressed.

alkonaut 7y ago
I think the future is that all configuration is code. Code in a proper functional/imperative language (preferably the one you wrote the app code in), rather than a special declarative language. The attraction of toml is minimalistic and simple definitions initially - but there is always too much logic for these languages. If not immediately, then eventually. "Real" programming languages have good compilers, good error messages, debuggers, IDE's with syntax highlighters and so on. json/yaml/toml/xml/whatever always feels like you are poking something and then trying it, checking for errors from typos and starting over. This feels quite backwards if you are used to developing with a good strict compiler and debugger. There are projects like pulumi that provide API's for multiple languages and hook into almost any service (e.g. Azure, AWS) https://www.pulumi.com/ https://www.pulumi.com/
- _frkl 7y ago
  Yeah, I know pulumi, and I'm working on something similar myself. Personally, in my experience, I don't think there's always too much logic, far from it. A lot of times you really only have a list of tasks that are executed one by one, and the nature of that doesn't really change. I think it's overkill to introduce a new wrapping layer in those cases (and that is what Pulumi really is, it mostly just wraps Terraform if I understand right). But yes, sometimes it's better to have 'real' code at your disposal. It's just a matter to know when's when. Like always :-) Also, debugging those yaml problems or real code doesn't really seem to make a difference for me. It's both equally annoying, and since there is a 'declarative' layer involved most of the time anyway, just a bit deeper down, debugging the 'real' issues (not typos and such -- btw. check out yamllint if you don't know it) is not any easier with wrappers like Pulumi. But maybe we have just worked on different type of complexities in our pasts. That usually explains different preferences for tooling. Just saying that this is not a thing we should/can generalize.

jclem 7y ago

Hi I'm an engineer on Actions, and a few months ago I probably would have said the same thing, but I've come around to it (and then some). We spent a ton of time working through the syntax changes in HCL, YAML, and other languages. What we found was that while HCL and other languages are amazing for expressing pure configuration, software development lifecycle and continuous integration workflows are a blend of configuration and pseudo-scripting, and we were only able to come up with a clean syntax for this in YAML. For example, although HCL supports heredocs, we felt that they suffered from readability problems versus multi-line strings in YAML when you're just trying to read through a workflow file and see what it does. There are many, many other reasons we felt that YAML was actually the right choice, and I'm optimistic others will come around to it in the same way I have.

rtsao 7y ago
Did you evaluate TOML and if so, what were the drawbacks you identified for the workflow use case?
- jclem 7y ago
  From what I remember, we did look at it some, but I can't remember many specifics, unfortunately. Looking at it now, I think that it wouldn't give us some of the flexibility that we want—for example, TOML arrays can only contain values of a single type, and for the sake of brevity, there were places in our configuration where we wanted to allow you to, for example, pass either a shorthand string or an object.