Assume some of these interfaces would also show up under the "Service" area which currently has
1. "Databases" 2. "Web Services: 3. "Servers" 4. "Maven Repositories" 5. "Cloud" 6. "Hudson Builders" 7. "Docker" 8. "Task Repositories: 9. "JS Test Driver" 10. "Selenium Server" Or is the idea here (in addition to a "DevSecOps" cluster in build context) to have a "DevSecOps" grouping with all of these assorted services being able to be added here? Do any of these services in question fall under one of these existing ones (i.e. maybe under Cloud which when right clicking allows adding an "Amazon Beanstalk" or "Oracle Cloud" option). With the "Enterprise" being very "bloated" would it be worth moving those out into a smaller grouping (i.e. into DevSecOps")? Eric Bresie ebre...@gmail.com On Thu, Jan 5, 2023 at 1:01 PM László Kishalmi <laszlo.kisha...@gmail.com> wrote: > > Well, > > @Eric Bresie <ebre...@gmail.com> > I usually do not enable the Enterprise cluster on my work NetBeans, and > Java SE + Groovy is only enabled as we have Jenkins in Job DSL. Anyway, I > think the Enterprise cluster is bloated already. > > Yes, there are some things available as LSP, but if I'd just use that I > could use VS Code as well. > > @Eric Barboni <sk...@apache.org> > Yes, if there were support for Ansible or Puppet, those would belong there. > > Yes, the new modules can be put into existing clusters, the question would > be which one and why. > > @Michael Bien <mbie...@gmail.com> > > Well, that wouldn't be the "generic project" idea, rather than some shared > project infrastructure code between Terraform and Helm, though that > "generic project" could come out of that. > > Also till a point ide cluster is fine, and from a point it might be weird. > I feel that with docker now. The editor support is fine, Dockerfiles are > common enough. The other docker integrations however could go somewhere > else. (Those features not that useful, and probably need some love) > > > Let's step back and ask, what requirements need to be fulfilled to have a > new cluster. > Also what things are against creating a new cluster. > > On Thu, Jan 5, 2023 at 4:30 AM Eric Bresie <ebre...@gmail.com> wrote: > >> Would any of that fall under the enterprise cluster which has some >> “cloud” functionality (Amazon. or is that too overloaded) or ide which has >> some container (docker)? >> >> So is a LSP server an option for some of this? There seem to be a few >> servers available for Terraform >> https://microsoft.github.io/language-server-protocol/implementors/servers/ >> >> Get Outlook for iOS<https://aka.ms/o0ukef> >> ________________________________ >> From: Eric Barboni <sk...@apache.org> >> Sent: Thursday, January 5, 2023 3:52:25 AM >> To: dev@netbeans.apache.org <dev@netbeans.apache.org> >> Subject: RE: [DISCUSSION] DevOps Cluster? >> >> It could be nice. >> >> I'm not very aware of the scope but ansible or puppet could belongs to >> this cluster ? (no intend to do plugin 😝) >> >> Best Regards >> Eric >> >> -----Message d'origine----- >> De : Michael Bien <mbie...@gmail.com> >> Envoyé : jeudi 5 janvier 2023 09:01 >> À : dev@netbeans.apache.org; Laszlo Kishalmi <lkisha...@apache.org> >> Objet : Re: [DISCUSSION] DevOps Cluster? >> >> sounds awesome, >> >> comments inline. >> >> On 04.01.23 16:48, Laszlo Kishalmi wrote: >> > Dear all, >> > >> > As many of you know, I'm a DevOps Engineer by trade (whatever that >> > means). I use NetBeans daily, however beside supporting Text editing, >> > terminal and favorites to organize my work. Text editing is mostly >> > Terraform and sometimes YAML. >> > >> > One day, I spent good time, when I edited code in a long comment >> > block, trying to troubleshoot why my changes were not applied. That >> > would be obvious if I had basic syntax highlight for Terraform. >> > >> > I wanted to create a syntax highlight module for Terraform. I checked >> > the available HCL grammars written in Java, I was not convinced >> > enough. That lead to ANTLR support in NB16. >> > >> > So, I have an ambitious plan creating a set of plugins which actually >> > would help my work: >> > >> > - Support for Helm Charts: That would mean Helm Charts would open as >> > NetBeans Projects, main goal would be providing code completion in the >> > Yaml templates. >> > >> > - Editor Support for Terraform files: syntax highlight, code >> > templates >> > >> > - Terraform Project Support: Terraform files to be parsed, and >> > provide code completion on the parsed data. >> > >> > - Go Lang Support: Well, this is not to express my love for GoLang >> > (as there are none of that), but Terraform resource/datasource >> > metadata can be extracted from the original source code. I just need a >> > parser. >> > >> > What I have so far: >> > >> > - Initial code for Go. (ANTLR based Lexer/Parser, basic Syntax >> > Highlight) >> > >> > - Initial code for Terraform (ANTLR based Lexer/Parser, basic Syntax >> > Highlight, Code Templates) >> > >> > - Some code for Helm project support, that does not provide anything >> > useful in its current state. >> > >> > - A General DevOps project type, I plan to use for Helm and Terraform >> >> long ago I wrote a "generic project" type which simply put a folder into >> the project tree (and automatically removed anything in .gitignore). >> This sounds like something similar. >> >> >> > >> > These kind of modules do not fit into our existing clusters, so I'd >> > propose to create a devops cluster. >> >> i mean it could be also put into the ide cluster next to docker etc. No? >> >> >> > >> > I'm not sure what should be the development model for this, as there >> > would be half baked modules for a while, so going right into master >> > may not be feasible as some implementations would be arching over a >> > few NB releases. Though I wish to file multiple PR-s gradually, not >> > just one big bang. >> > >> > I'm thinking about the following options: >> > >> > - Create a devops cluster in a devops branch in the main repo, create >> > PR-s agains that branch, merge to master when it's solid. >> > >> > - Create a devops cluster in master branch, create PR-s as usual, do >> > not include/mark devops cluster as experimental in the binaries. >> > >> > >> > Opinions? >> >> I personally like the second option a bit more since it would allow to >> incrementally deliver experimental modules. >> >> best regards, >> >> michael >> >
