├── .github ├── FUNDING.yml └── workflows │ └── main.yml ├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md └── docs ├── Architecture_Guidelines.md ├── Architecture_Security_Compliance.md ├── CNAME ├── CODE_OF_CONDUCT.md ├── How_To_Accept_Payments.html ├── How_To_Contribute.md ├── PRIVACY_POLICY.md ├── _config.yml ├── images ├── README.md ├── fullstack.png ├── gitops.png ├── opencollective.png ├── stackops.png └── stackstandard.png └── index.md /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # These are supported funding model platforms 2 | 3 | github: johnleider, forktheweb 4 | patreon: # Replace with a single Patreon username 5 | open_collective: global-developer-network 6 | ko_fi: # Replace with a single Ko-fi username 7 | tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel 8 | community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry 9 | liberapay: # Replace with a single Liberapay username 10 | issuehunt: # Replace with a single IssueHunt username 11 | otechie: # Replace with a single Otechie username 12 | custom: ['https://github.com/vuetifyjs/vuetify'] 13 | -------------------------------------------------------------------------------- /.github/workflows/main.yml: -------------------------------------------------------------------------------- 1 | # This is a basic workflow to help you get started with Actions 2 | 3 | name: CI 4 | 5 | # Controls when the action will run. 6 | on: 7 | # Triggers the workflow on push or pull request events but only for the main branch 8 | push: 9 | branches: [ main ] 10 | pull_request: 11 | branches: [ main ] 12 | 13 | # Allows you to run this workflow manually from the Actions tab 14 | workflow_dispatch: 15 | 16 | # A workflow run is made up of one or more jobs that can run sequentially or in parallel 17 | jobs: 18 | # This workflow contains a single job called "build" 19 | build: 20 | # The type of runner that the job will run on 21 | runs-on: ubuntu-latest 22 | 23 | # Steps represent a sequence of tasks that will be executed as part of the job 24 | steps: 25 | # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it 26 | - uses: actions/checkout@v2 27 | 28 | - name: Discord Commits 29 | uses: Sniddl/discord-commits@v1.2 30 | 31 | - name: Markdown to PDF 32 | uses: valtyr/pandoc-action@v0.1-alpha 33 | 34 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | All participants of Global Developer Network are expected to abide by our Code of Conduct, both online and during in-person events that are hosted and/or associated with Global Developer Network. 3 | 4 | # The Pledge 5 | In the interest of fostering an open and welcoming environment, we pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. 6 | 7 | # The Standards 8 | Examples of behaviour that contributes to creating a positive environment include: 9 | 10 | - Using welcoming and inclusive language 11 | - Being respectful of differing viewpoints and experiences 12 | - Gracefully accepting constructive criticism 13 | - Referring to people by their preferred pronouns and using gender-neutral pronouns when uncertain 14 | 15 | 16 | ## Examples of unacceptable behaviour by participants include: 17 | 18 | - Trolling, insulting/derogatory comments, public or private harassment 19 | - Publishing others' private information, such as a physical or electronic address, without explicit permission 20 | - Not being respectful to reasonable communication boundaries, such as 'leave me alone,' 'go away,' or 'I’m not discussing this with you.' 21 | - The usage of sexualised language or imagery and unwelcome sexual attention or advances 22 | - Swearing, usage of strong or disturbing language 23 | - Demonstrating the graphics or any other content you know may be considered disturbing 24 | - Starting and/or participating in arguments related to politics 25 | - Assuming or promoting any kind of inequality including but not limited to: age, body size, disability, ethnicity, gender identity and expression, nationality and race, personal appearance, religion, or sexual identity and orientation 26 | - Attacking personal tastes 27 | - Other conduct which you know could reasonably be considered inappropriate in a professional setting. 28 | 29 | # Enforcement 30 | Violations of the Code of Conduct may be reported by sending an email to comms@large.marketing. All reports will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Further details of specific enforcement policies may be posted separately. 31 | 32 | We hold the right and responsibility to remove comments or other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any members for other behaviours that they deem inappropriate, threatening, offensive, or harmful. 33 | 34 | ## Attribution 35 | This Code of Conduct is adapted from dev.to. 36 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. 10 | 11 | "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. 12 | 13 | "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. 14 | 15 | "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. 16 | 17 | "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. 18 | 19 | "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. 20 | 21 | "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). 22 | 23 | "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 24 | 25 | "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." 26 | 27 | "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 28 | 29 | 2. Grant of Copyright License. 30 | 31 | Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 32 | 33 | 3. Grant of Patent License. 34 | 35 | Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 36 | 37 | 4. Redistribution. 38 | 39 | You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 40 | 41 | You must give any other recipients of the Work or Derivative Works a copy of this License; and 42 | You must cause any modified files to carry prominent notices stating that You changed the files; and 43 | You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and 44 | If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. 45 | You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 46 | 47 | 5. Submission of Contributions. 48 | 49 | Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 50 | 51 | 6. Trademarks. 52 | 53 | This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 54 | 55 | 7. Disclaimer of Warranty. 56 | 57 | Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 58 | 59 | 8. Limitation of Liability. 60 | 61 | In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 62 | 63 | 9. Accepting Warranty or Additional Liability. 64 | 65 | While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. 66 | 67 | END OF TERMS AND CONDITIONS 68 | 69 | --- 70 | Copyright 2021. Global Developer Network (GDN). 71 | 110 Corcoran street, Durham, NC 27701. USA. 72 | 73 | Licensed under the Apache License, Version 2.0 (the "License"); 74 | you may not use this file except in compliance with the License. 75 | You may obtain a copy of the License at 76 | 77 | http://www.apache.org/licenses/LICENSE-2.0 78 | 79 | Unless required by applicable law or agreed to in writing, software 80 | distributed under the License is distributed on an "AS IS" BASIS, 81 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 82 | See the License for the specific language governing permissions and 83 | limitations under the License. 84 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![License](https://img.shields.io/badge/license-apache%202.0-yellow)](https://choosealicense.com/licenses/apache-2.0/) 2 | [![Open Source Stacks](https://img.shields.io/badge/Open%20Source%20Stacks-blue)](http://lmg.systems/ssi-roadmap) 3 | [![Groovy](https://img.shields.io/badge/language-Groovy-green)](https://github.com/apache/groovy) 4 | [![Node.js](https://img.shields.io/badge/language-NodeJS-green)](https://npmjs.com) 5 | [![12 Factor App](https://img.shields.io/badge/app-12--factor-yellow)](https://12factor.net/) 6 | 7 | Open Source Collective 8 | 9 | 10 | # Why GDN? 11 | - We have been officially recognized by Open Collective as a non-profit 501(c)(6) 12 | - Our [ROADMAP!](http://lmg.systems/ssi-roadmap) contains a bus full of Open Source Developers! 13 | - We're tinkering away in order to build something [grand](https://codepen.io/largesoft/live/OJRpeBV). 14 | - Rest assured if you enjoy working across the stack, you are in the right place. 15 | 16 | > Please note! Much of the functionality described in this document is in extrordinarily active development (on Gitlab). 17 | 18 | ## Alpha preview 19 | Please sign up for our early adopters & investors alpha release preview using [this form](https://lmg.systems/zeronine) for contributor-level access to it. 20 | 21 | #### If you inhtend on using any code you find published to Github, expect that it will NOT be functional at minimum until the alpha version is released. 22 | It is slated for FY21Q03 which is essentially between now and the end of March. 23 | 24 | # GDN Contributor Information 25 | Welcome to the [Global Developer Network](https://lmg.systems/gdn-osc) 501(c)(6) [Official Open Source Collective](https://lmg.systems/gdn-osc). 26 | Built by code contributions from open source developers world-wide. 27 | 28 | We intend to accept contributions once our non-profit paperwork is officially approved, and 100% will go towards funding this development effort. 29 | We already have some [corporate sponsorship](https://fullstack.llc), but are always looking for more backers. 30 | 31 | # What are we doing? 32 | We are re-inventing the development process for Full Stack applications with an emphasis on business requirements, domain driven operations, security-first specifications with conformance to industry-standard best practices, and test coverage. 33 | 34 | Just ask us! 35 | 36 | # Discord Community 37 | Please join us on [GDN Discord chat](https://discord.gg/r5vXHwgb). 38 | 39 | ## GDN Repo for Contributors 40 | A repository designed for contributors to the [OpenSourceStacks.com](https://fullstack.llc) project, an initiative for providing a management interface for describing, building, and deploying different full stack strategies using open source software. It will provide freelance gigs for open sourcers while connecting them directly to clients, and will use a structured but enjoyable method for the onboarding process, virtual workforce solutions, and business process oversight to augment the experience via the [Full Stack Engine](https://fullstack.llc). 41 | 42 | ## What is this? 43 | A repository for contributor guidelines and other contributor related information. This repository will also contain a branch for the fully transparent open source [StackStandard.com](https://stackstandard.com) registry, which provides a taxonomy of behaviors from which [developers of packages and themes](https://www.notion.so/investhere/2-StackStandard-com-2563664485504dd9860d53a270df8631#78a9826a8a3740f6a7474f2d052a2ff3) may adopt conformance, and adopt usage of security control specifications for which we provide testing. Should you choose to be an early adopter, you will get a fancy badge for your website that says you adhere to these specific standards. We have a great process for validating the tests and presenting the status of your organization, and we will be marketing early adopters in our future campaigns. 44 | 45 | ## Contributor Benefits 46 | * Early access to our GA Amazon AWS Cloud on EKS. 47 | * The ability to debug your stack on our cloud at no cost. 48 | * The ability to test other combinations of stack technology on our service for free. 49 | 50 | Want to contribute dollars or code? 51 | - Please fill out [this form](http://bit.ly/0point9alpha) 52 | 53 | ## Early adoption of the language 54 | #### (Phase 1) 55 | 56 | GDN provides an open collective network of like-minded developers who are all seeking to participate in creating definitions for the Fullstack Domain Specific Language (FDSL) project. The language is actually a superset of GraphQL and can be used that way. It will also come in a short form notation style language that looks very similar to a DSL (Domain Specific Language) and is highly specific to the Full Stack Strategy domain. (i.e.- describing your stack technology and making sure it is fully functional, tested, and compliant with security controls.) 57 | 58 | ## How does it work? 59 | The FDSL provides an abstraction layer for applying `stack actions` at `build time`, and it does this through packages on NPM that are run as docker containers using our CLI. The CLI user does *not* need to worry about Docker or containers, as they are built intrinsically into CLI code. These `stack actions` running as `containers` perform as compilable tasks on your stack, including API calls, Transformations from RAC (results as code), introspection of packages (RASCI/ Results As Secure Code Introspection), attachment of telemetry for stack tracing (Event Listeners), and Fluentd Logging collectors (for attaching streaming logs to Kubernetes) on the stack. We are using [Terraform](https://www.terraform.io/) for some actions, and if you use our cloud, [Vault](https://www.vaultproject.io/) for secrets management controls (otherwise K8s Secrets). 60 | 61 | ### Testing 62 | These same abstractions allow for the inspection (Selenium UAT), unit and internal integration testing of [Docker](https://hub.docker.com/) images, package management, CDN, and other 3rd party software or API dependencies required to be compliant with specific standards in order to be deployed from a CICD pipeline or through `kubectl`. All a package maintainer needs in order to adopt this standard is our CLI tool, which is pluggable and modular, in order to create the `.stack` definition format and publish it to NPM via Git along with a [HELM3](https://helm.sh/docs/topics/charts/) chart of your stack. This is done automatically for multiple packages using the `monorepo` pattern [described here](https://github.com/GlobalDeveloperNetwork/contributors#loading-your-repo). 63 | 64 | > Since a Helm3 chart obviously needs to be created for each backend, we will [provide consulting](https://discord.gg/r5vXHwgb) for various backends until we have a CLI plugin for creating them. We are supporting the following configurations from our first Generally Available (GA) status: 65 | 66 | Google, Microsoft, and Amazon clouds for GraphQL APIs: 67 | 68 | * Postgres with a Hasura Layer, providing the GraphQL API 69 | * Postgres with an Express or Fastify GraphQL API 70 | * Postgres with a NestJS layer and GraphQL API 71 | * MongoDB with an Express or Fastify GraphQL API 72 | * Firestore with a GraphQL API (firestore-apollo) 73 | * Cosmos DB with a GraphQL API (using Hasura and the Postgres driver) 74 | * DocumentDB or DynamoDB with a GraphQL API (using AWS AppSync and Lambda, or DynamoDB configurations) 75 | * Socketclusters.io for streaming listener events. 76 | * Meili search nodes are also supported for those looking to implement realtime search in their cluster. 77 | 78 | ### Out of the box 79 | We provide the following functions out of the box: 80 | - GitOps strategy - i.e.- we abstract away k8s and make it simple to use for developers who don't have a PhD. in clusterology. 81 | - We provide a comprehensive, recursive installation method as post-install hooks so theme and other developers with many packages can publish easily to our system using one repo and by not having to modify all of their packages in egregious ways. 82 | - All code is built using our CLI (`npx gsys` for no global-conflicts one-time-dependency installs) 83 | - All code is tested using local integration tests and the ability to use Gitlab AutoDevOps or Github actions, while still providing test coverage to StackStandard.com. 84 | - All builds are triggered by a condition, action, and event chain that is langage agnostic, pub/sub socket stream-ready, and provides Vault support for runtime secrets. 85 | - Because we provide hosted Vault integration, you can distribute your app using Content Trust on the images and our CLI will store them on a secure Quay repo we maintain. 86 | - If you need digital asset protection, you can choose to encrypt your assets during S3 cold storage. 87 | - Our StackStandard documentation will explain all of our MVP security configurations, [offerings](https://app.getguru.com/card/c86b5pji/What-security-offers-are-going-to-definitely-be-provided-by-the-StackStandardcom-MVP), and more. 88 | 89 | ## What do you mean by a "Stack Definition"? 90 | A stack definition is a `.stack` file that is generated by a developer when creating their [Kubernetes-based](https://kubernetes.io/docs/home/) [Helm chart](https://helm.sh/docs/topics/charts/). Helm is an open source provider of a charting specification that simplifies deployment of K8s YAML by providing a `values.yaml` and `values.schema.json` file. These values are simply filled out by a user and when deployed they are assembled along with the charts. Our stack definition is created for build time operations, not deployment/ runtime. That being said, we still are supporting running build time integration tests via popular CICD. This is achieved by providing simple webhooks through endpoints that can trigger CICD jobs on our servers. Each version pushed to us is immutable and tree-checksums are validated along with DCT, and potentially Notary trust delegations (in the future). So it is trivial to support the use case of external CICD triggers so long as we can validate the chain of trust requesting it. 91 | 92 | ## Build time Ops 93 | Our focus is on the declaration of immutable artifacts that are secured, and provide digital signatures for validation and verification using GPG. We provide our offering separate from Helm via a CLI (Command Line Interface) that will ask you a series of initialization questions, and through your answers deploy a `.stack` definition locally for local testing. 94 | 95 | ## Testing the API 96 | We provide an indivdual language module for each transformation or integration test, this allows for each module to be public and open source in any language (that supports Git workflows), while still providing the flexibility to run locally. It also ensures that modules are versioned and immutable. As you develop your `.stack` file, you can utilize interactive examples that we provide and browse our documentation at [stackStandard.com](https://stackstandard.com) (will be launched by Feb 15th 2021). 97 | 98 | ## Publishing to your Helm chart 99 | Our CLI will update your existing SSI with conformance standards when tests succeed through our API. You can optionally have our CLI add in your stack definition to the Helm chart itself as YAML declarations, but this is not required. This can be highly useful for distributed applications that want to resell and conform to the FSDL. It is also very useful for UI theme, and other types of distributions where the stack needs to be modified idempotently. 100 | 101 | ## Idempotence and Language Support 102 | Right now we are focusing early adoption of just one language: ES6+ for Node.js stacks. In the near future we will be establishing this FSDL in a way that is language agnostic and supports multiple SDKs. We've planned for it, we just can't execute with at least 100 early adopters for each language. 103 | 104 | ## FSDL Privacy 105 | For some use cases where the stack has been modified to work with on-premise or private 3rd party software systems, it may be best to keep the stack definition private. We adhere to a standard that provides both options. See [StackStandard](https://stackstandard.com) for more details. (Launching January 15th 2021) 106 | 107 | # What does DSL describe? 108 | The DSL is actually a querying meta-language that looks much like javascript and/or string literals, just with additional capabilites. It is designed to make it as simple as possible to "ask" for a behavior based on a specific set of conditions and return a "result-as-code" (RAC) response. The responses are stored as Docker containers that are digitally signed, and distributed using NPM as a generic loader that can be easily re-used as individual NPM modules. This allows you to run everythign locally, and at CICD time, with the added benefit of 3rd party auditing (our service) whenever CICD builds are triggered. 109 | 110 | # Loading your repo 111 | 112 | ## Example Monorepo for Authors of multiple packages that want to use the Gitops.Systems (Gsys) and Fullstack DSL (FDSL) for CICD workflows (i.e.- Gitlab AutoDevOps or Github Actions): 113 | ```bash 114 | $ / package.json 115 | { 116 | "install:verify": "cd projects/verification && npx yarn-recursive", // runs tooling package build for encryption and docker manipulation 117 | "install:cli-all": "cd projects/cli-all && npx yarn-recursive", // runs yarn to build via npx the CLI and all supported plugins 118 | "install:PKG": "cd projects/PKG && npx yarn-recursive && \ 119 | ln -s ./PKG ___INSTALL_YOUR_PACKAGES_HERE && \ 120 | npx @fdsl/verify", // verify all of your own supported packages 121 | "postinstall": "npx yarn gsys && ln -s ./.bin/gsys gsys; gsys verify --recursive" // run verification from the gsys CLI 122 | } 123 | ``` 124 | ## Building a Monorepo: 125 | ```bash 126 | npx yarn-run-all 127 | ``` 128 | 129 | ## Example package contained in the directory of your choice: 130 | ```bash 131 | 132 | $ cat package.json | npx gsys publish behavior 133 | { 134 | "name": "@GlobalDeveloperNetwork/module", 135 | "description": "test-behavior", 136 | "version": "1.0.1", 137 | "author": "Full Stack Engine, LLC", 138 | "bin": { 139 | "gsys": "./bin/run load --with-tests=false ${CONDITION}" 140 | }, 141 | "devDependencies": { 142 | "@gsys/loader": "^1.5.9", 143 | "gsys": "^1.1.0"", 144 | "dockerode": "^3.2.1" 145 | } 146 | } 147 | ``` 148 | 149 | All results are digitally signed and encrypted by DCT using a private and public key pair that can verify author authenticity. 150 | The docker images can be [created by Node](https://www.npmjs.com/package/dockerode), since this is the first language we are focusing on support for. 151 | 152 | --- 153 | 154 | # Legal CYA 155 | 156 | Some portions of this repo are from the [CrateKube project](https://github.com/cratekube/cratekube), i.e.- the architectural standards, which is now deprecated by Cisco. 157 | - The code is deprecated and non-licensed, so we are resurrecting some portions of the project for our CLI. 158 | - This has been checked by our legal team and we are compliant with all applicable laws. 159 | 160 | ___ 161 | 162 | > Questions or concerns about content provided by our service? We are DMCA compliant, so if you do have questions that need to be addressed, please contact our [legal](mailto:legal@large.marketing) staff directly. 163 | 164 | 165 | # Current Sponsors 166 | 167 | 168 | 169 | 172 | 175 | 178 | 181 | 182 |
170 | Stack Standard 171 | 173 | Stack Ops 174 | 176 | Git Ops 177 | 179 | Full Stack 180 |
183 | 184 | 185 | 186 | 187 | 188 | # License Notice 189 | 190 | ___ 191 | Copyright 2021. Global Developer Network (GDN). 192 | 110 Corcoran street, Durham, NC 27701. USA. 193 | 194 | Licensed under the Apache License, Version 2.0 (the "License"); 195 | you may not use this file except in compliance with the License. 196 | You may obtain a copy of the License at 197 | 198 | http://www.apache.org/licenses/LICENSE-2.0 199 | 200 | Unless required by applicable law or agreed to in writing, software 201 | distributed under the License is distributed on an "AS IS" BASIS, 202 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 203 | See the License for the specific language governing permissions and 204 | limitations under the License. 205 | 206 | 214 | -------------------------------------------------------------------------------- /docs/Architecture_Guidelines.md: -------------------------------------------------------------------------------- 1 | # GDN Architecture Guidelines 2 | 3 | ## Introduction 4 | This document is designed to provide a set of guidelines for contributors to architect new GlobalDeveloperNetwork features. New 5 | contributors and developers who are unfamiliar with our architecture format should refer here before submitting pull requests. 6 | We're pretty straight-forward with how we document our microservice architecture, but we also like to keep things consistent so 7 | please read on if you are interested in becoming a contributor. 8 | 9 | ## Who is this for? 10 | All developers and contributors who are going to architect new features on the GDN open source projects, and who seek to document 11 | those features. 12 | 13 | ## Document Format 14 | Each architecture document should contain: 15 | 16 | - An Overview 17 | - List of components and their short descriptions (1-2 paragraphs) 18 | - Minimum Viable Product functionality expectations 19 | 20 | ### Diagrams 21 | 22 | The following diagrams must be included in your architecture document: 23 | 24 | | Type | Description | 25 | |---|---| 26 | | _Component Diagram_ | What are the system functions and how do they interact | 27 | | _Physical Diagram_ | Where will the component be deployed | 28 | | _Security Diagram_ | authc, authz, trust relationships, auditing as defined in [Security Architecture Standards](./security-architecture) | 29 | 30 | ### How do I make the diagrams? 31 | 32 | 33 | ##### Example: 34 | ![Component](https://www.plantuml.com/plantuml/svg/ZP4z3y8W48PtVyMbpaHc1rCTs5pis30WlHZI3mn7QupnlmisKLeJzPRZuytplWSvUULytpOBUDLPwLgT4BAzqSuIki5eX5qMhcw9x5bbcsZOKG8iEHU2yrHu_mdVPZFqbAlaY1LYAZeWsTvf99cSfsvlky9R5nV5bJosSpieE_GNwsf6eqvEyyVTzz53HCOsd--n1krGUQHLXGt6Rhh1raZ_uUQn0YzEWXHQe4P8ZbqLFl01) 35 | 36 |
Show UML Code 37 |

38 | 39 | ``` 40 | @startuml 41 | package "Microservice B" { 42 | [microservice-b] #00FF00 43 | } 44 | package "Microservice A" { 45 | [microservice-a] #00FFFF 46 | [Resources] 47 | } 48 | package "Storage System" { 49 | [network-storage] 50 | } 51 | 52 | 53 | [microservice-a] --> [microservice-b] : creates/deletes/invokes 54 | [microservice-a] --> [network-storage] : Stores State 55 | 56 | @enduml 57 | ``` 58 |

59 |
60 | 61 | ##### Instructions: 62 | 63 | 1. Visit [PlantText](https://www.planttext.com/) 64 | 2. Write UML code 65 | 3. Embed SVG as `![Component](--SVG URL --)` 66 | 67 | ## Example Architecture Page 68 | Here's a link to the [General Architecture](./general-architecture), to be used as an example of what we are after. 69 | 70 | ## Architecture approval process 71 | 72 | Currently this process is loose at best, but essentially: 73 | 1. Submit a pull request with your architecture proposal to [any repo in our network](https://github.com/GlobalDeveloperNetwork) 74 | 2. Add two maintainers as reviewers 75 | 3. Both maintainer and member discussions occur 76 | 4. Profit? 77 | -------------------------------------------------------------------------------- /docs/Architecture_Security_Compliance.md: -------------------------------------------------------------------------------- 1 | # GDN Security Architecture Standards 2 | This document serves as the source-of-truth for GDN Security Architecture standards. The table of security standards is defined as follows: 3 | | Property | Description | 4 | |---|---| 5 | | Identifier | A integer representing the standard. Must be unique among all GDN Security standards | 6 | | Short Name | A snake_case short name of the standard. Must be unique among all GDN Security standards and no longer than 10-characters. May be used instead of the numerical identifier in diagrams. | 7 | | Category | One of "authc", "authz", "trust", or "audit". Defined as: | 8 | | Strength | The relative strength of the standard for informing design decision preferences. One of "avoid", "weak", "sufficient", "strong". Defined as: | 9 | | Expiration | The date when the standard must be reviewed and renewed or superseded by a new standard. | 10 | | Superseded By | The numerical identifier of the standard that has or will replace the standard. | 11 | | Description | A complete and accurate description of the standard technical, process, and people elements. A technical criteria section may also be present with a of criteria with requirement level as defined in defined in RFC 2119 1 | 12 | 13 | # Referencing The Standards 14 | Security standards should be referenced in diagrams or documents using the regex pattern of `\[((?[a-zA-Z_]+):(?\d+))|(?[a-z_])\]` such as `[GlobalDeveloperNetwork_sso]` or `[authc:100]`. The short name is preferred whenever it provides better readability. 15 | 16 | # List of Security Standards 17 | 18 | | Identifier | Short Name | Category | Strength | Expiration | Description | 19 | |---|---|---|---|---|---| 20 | | 100 | GDN_saml | authc | sufficient | 12/01/2020 | End-user (human) authentication via SAML v2 single-sign on exchange via the GDN keycloak deployment brokering GlobalDeveloperNetwork SSO. GlobalDeveloperNetwork policy for 2FA, password complexity, rotation, etc. are applied at the GlobalDeveloperNetwork SSO IdP.

Technical criteria defining this standard:

| 21 | | 101 | GDN_oidc | authc | sufficient | 12/01/2020 | End-user (human) authentication via OIDC single-sign on exchange via the GDN keycloak deployment brokering GlobalDeveloperNetwork SSO. GlobalDeveloperNetwork policy for 2FA, password complexity, rotation, etc. are applied at the GlobalDeveloperNetwork SSO IdP.

Technical criteria defining this standard:

| 22 | | 102 | jwt_authc | authc | sufficient | 12/01/2020 | Bearer (human or machine) authentication using the JWT specification via the GDN keycloak deployment brokering GlobalDeveloperNetwork SSO. GlobalDeveloperNetwork policy for 2FA, password complexity, rotation, etc. are applied at the GlobalDeveloperNetwork SSO IdP.

Technical criteria defining this standard:

| 23 | | 103 | jwt_authz | authz | sufficient | 12/01/2020 | Bearer (human or machine) authorizations using the JWT specification via the GDN keycloak deployment brokering GlobalDeveloperNetwork SSO. GlobalDeveloperNetwork policy for 2FA, password complexity, rotation, etc. are applied at the GlobalDeveloperNetwork SSO IdP.

Technical criteria defining this standard:

| 24 | | 104 | api_authc | authc | sufficient | 12/01/2020 | Authentication of machine clients to services with a long-lived api key. Inherits all requirements from `jwt_authc` with the exception of changing token type from access to offline. | 25 | | 105 | https_le | trust | weak | 12/01/2020 | HTTPS using TLS certificates issued for specific DNS names. This is an implicit type of trust based on the client-side configuration of a target URL. It is implicit because the client will trust whatever host it is pointed at as long as the hosts presents a valid certificate signed by the the trusted root CAs of the client. This assumes that DNS is not compromised, and that the CA issuing the certificate for the target host is also not compromised, and the host itself is not compromised. There is no direct trust between the client and server, and trust is only established one direction (client trusts server).

Technical criteria defining this standard:

| 26 | | 106 | GDN_logs | auditing | sufficient | 12/01/2020 | Basic storage and handling of log information for GDN platform services (not tenant workloads)

Technical criteria defining this standard:

| 27 | | 109 | ssh_pki | authc | sufficient | 12/01/2020 | The SSH protocol (also referred to as Secure Shell) is a method for secure remote login from one computer to another. It provides several alternative options for strong authentication, and it protects the communications security and integrity with strong encryption. It is a secure alternative to the non-protected login protocols (such as telnet, rlogin) and insecure file transfer methods (such as FTP).

Technical criteria defining this standard:

| 28 | | 110 | ssh_keyfile | authz | weak | 12/01/2020 | The authorized keys file determines your user, which in turn provides access and authorization to only certain files on the remote host. This is a course grained standard because authentication and authorization are closely correlated.

Technical criteria defining this standard:

| 29 | | 111 | ssh_vault | authz | strong | 12/01/2020 | The Vault SSH secrets engine provides secure authentication and authorization for access to machines via the SSH protocol. The Vault SSH secrets engine helps manage access to machine infrastructure, providing several ways to issue SSH credentials. | 30 | | 112 | vault_pki | trust | sufficient | 12/01/2020 | The PKI secrets engine generates dynamic X.509 certificates. With this secrets engine, services can get certificates without going through the usual manual process of generating a private key and CSR, submitting to a CA, and waiting for a verification and signing process to complete. Vault's built-in authentication and authorization mechanisms provide the verification functionality.

Technical criteria defining this standard:

| 31 | | 113 | tls_pki | authc | sufficient | 12/01/2020 | A digital certificate that certifies the ownership of a public key by the named subject of the certificate and indicates certain expected usages of that key.

Technical criteria defining this standard:

| 32 | | 114 | tls_cert_file | authz | weak | 12/01/2020 | Validation that a party possessing a digital certifiate is authorized to communcate with host.

Technical criteria defining this standard:

| 33 | | 115 | tls_vault | authz | sufficient | 12/01/2020 | Validation that a party possessing a digital certifiate is authorized to communcate with host. | 34 | | 116 | pw_authc | authc | very weak | 12/01/2020 | General username and password authentication, e.g., http basic auth, jdbc, and ssh without certs.

Technical criteria defining this standard:

| 35 | | 117 | storage_aes256 | confidential | sufficient | 12/01/2020 | Encryption for all persistent data.

Technical criteria defining this standard:

| 36 | | 118 | token_authc | authc | weak | 12/01/2020 | General auth token

Technical criteria defining this standard:

| 37 | | 119 | token_authz | authz | weak | 12/01/2020 | General auth token

Technical criteria defining this standard:

| 38 | 39 | # References 40 | 41 | 1. https://www.ietf.org/rfc/rfc2119.txt ↩ 42 | 2. https://letsencrypt.org/ ↩ 43 | -------------------------------------------------------------------------------- /docs/CNAME: -------------------------------------------------------------------------------- 1 | contributors.stackstandard.com -------------------------------------------------------------------------------- /docs/CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | All participants of Global Developer Network are expected to abide by our Code of Conduct, both online and during in-person events that are hosted and/or associated with Global Developer Network. 3 | 4 | # The Pledge 5 | In the interest of fostering an open and welcoming environment, we pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. 6 | 7 | # The Standards 8 | Examples of behaviour that contributes to creating a positive environment include: 9 | 10 | - Using welcoming and inclusive language 11 | - Being respectful of differing viewpoints and experiences 12 | - Gracefully accepting constructive criticism 13 | - Referring to people by their preferred pronouns and using gender-neutral pronouns when uncertain 14 | 15 | 16 | ## Examples of unacceptable behaviour by participants include: 17 | 18 | - Trolling, insulting/derogatory comments, public or private harassment 19 | - Publishing others' private information, such as a physical or electronic address, without explicit permission 20 | - Not being respectful to reasonable communication boundaries, such as 'leave me alone,' 'go away,' or 'I’m not discussing this with you.' 21 | - The usage of sexualised language or imagery and unwelcome sexual attention or advances 22 | - Swearing, usage of strong or disturbing language 23 | - Demonstrating the graphics or any other content you know may be considered disturbing 24 | - Starting and/or participating in arguments related to politics 25 | - Assuming or promoting any kind of inequality including but not limited to: age, body size, disability, ethnicity, gender identity and expression, nationality and race, personal appearance, religion, or sexual identity and orientation 26 | - Attacking personal tastes 27 | - Other conduct which you know could reasonably be considered inappropriate in a professional setting. 28 | 29 | # Enforcement 30 | Violations of the Code of Conduct may be reported by sending an email to comms@large.marketing. All reports will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Further details of specific enforcement policies may be posted separately. 31 | 32 | We hold the right and responsibility to remove comments or other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any members for other behaviours that they deem inappropriate, threatening, offensive, or harmful. 33 | 34 | ## Attribution 35 | This Code of Conduct is adapted from dev.to. 36 | -------------------------------------------------------------------------------- /docs/How_To_Accept_Payments.html: -------------------------------------------------------------------------------- 1 | Global Developer Network Payout Program 2 |

Accepting payments

3 |

From GDN to freelancers, payment flows unidirectionally in the form of "Payouts": 4 |

10 | 11 | 
 This page is for contractors, vendors, and investors who wish to enroll in the Global Payout program.
12 | 13 |

This program is designed so we may automate rolling payouts involving hundreds if not thousands of freelancers and employees in the very near future.

14 | 15 |

How it works

16 | 17 |

Simply click the button to enroll:

18 | 19 | Get paid weekly 20 | 21 | -------------------------------------------------------------------------------- /docs/How_To_Contribute.md: -------------------------------------------------------------------------------- 1 | # GDN Contribution guidelines overview 2 | 3 | We aim to make becoming a GlobalDeveloperNetwork contributor a simple and easy process. The following guidelines help to get you up and running with GlobalDeveloperNetwork contributions as quickly as possible. 4 | 5 | ## Contribution process 6 | 7 | At a high level, the contribution process takes the following steps: 8 | 9 | 1. Choose an issue to work on. 10 | 2. Fork the repository containing the project you'd like to contribute to. 11 | 3. Develop the feature or fix the bug you've chosen to work on. Be sure to include tests. 12 | 4. Update the documentation, including the repository's README.md, as necessary. 13 | 5. Ensure that tests are passing and the project builds. 14 | 6. Open a pull request with your changes against master. Review our (pull request) PR creation guidelines below for more information. 15 | 7. Wait for reviewers. You will likely need to make some changes after the code review. 16 | 8. Once the reviews pass, we will merge your pull request. 17 | 18 | ## Local Development 19 | 20 | Each repository includes a README that will provide instructions on how to build and run the code locally. 21 | 22 | ## Feature Requests and Bugs 23 | 24 | Search our existing issues for feature requests and bugs. If one doesn't already exist for your feature or bug, create a new one. Issue templates are available to help guide you through this process. 25 | 26 | ## Contact 27 | 28 | Reach out to us through comms@large.marketing to ask for help or provide feedback. 29 | 30 | 31 | # Pull request (PR) guidelines 32 | 33 | The following pull request guidelines service to walk users through the process of creating and submitting a 34 | PR against a GlobalDeveloperNetwork repository. On the GlobalDeveloperNetwork team, we use the [forking strategy](https://gist.github.com/Chaser324/ce0505fbed06b947d962) 35 | to manage changes. As a result, PRs are required to contribute code to our repositories. 36 | 37 | ## Creating a PR 38 | To create a PR, use the following steps: 39 | - Fork the repository you would like to contribute to 40 | - Create a branch in your fork for your contribution 41 | - Apply changes to your branch including test updates and documentation changes 42 | - Create a PR from your branch to the target upstream branch using the GitHub UI 43 | 44 | After the PR has been submitted, GlobalDeveloperNetwork maintainers will review the contribution according to our review process detailed below 45 | and discuss the code with the contributor. After the review has completed, a GlobalDeveloperNetwork maintainer will merge the code into the project. 46 | 47 | ### Agree to the Developer Certificate of Origin 48 | To avoid copyright issues with this open source project, all contributors *must* agree to the Developer Certificate of Origin (DCO) 49 | vesion 1.1 for all contributions. To confirm that you agree to the DCO, all commits must contain a Signed-off-by line with an 50 | email matching the email from the commit. For reference, the text below is version 1.1 of the 51 | [Developer Certificate of Origin](https://developercertificate.org/) 52 | ``` 53 | Developer Certificate of Origin 54 | Version 1.1 55 | 56 | Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 57 | 1 Letterman Drive 58 | Suite D4700 59 | San Francisco, CA, 94129 60 | 61 | Everyone is permitted to copy and distribute verbatim copies of this 62 | license document, but changing it is not allowed. 63 | 64 | 65 | Developer's Certificate of Origin 1.1 66 | 67 | By making a contribution to this project, I certify that: 68 | 69 | (a) The contribution was created in whole or in part by me and I 70 | have the right to submit it under the open source license 71 | indicated in the file; or 72 | 73 | (b) The contribution is based upon previous work that, to the best 74 | of my knowledge, is covered under an appropriate open source 75 | license and I have the right under that license to submit that 76 | work with modifications, whether created in whole or in part 77 | by me, under the same open source license (unless I am 78 | permitted to submit under a different license), as indicated 79 | in the file; or 80 | 81 | (c) The contribution was provided directly to me by some other 82 | person who certified (a), (b) or (c) and I have not modified 83 | it. 84 | 85 | (d) I understand and agree that this project and the contribution 86 | are public and that a record of the contribution (including all 87 | personal information I submit with it, including my sign-off) is 88 | maintained indefinitely and may be redistributed consistent with 89 | this project or the open source license(s) involved. 90 | ``` 91 | 92 | ### Git setup 93 | If not configured globally, please configure your commits to provide a username and email: 94 | ``` 95 | git config user.name ' ' 96 | git config user.email '' 97 | ``` 98 | 99 | To signoff contributions add the `-s/--signoff` option when committing to your branch: 100 | ``` 101 | git commit -s 102 | ## or 103 | git commit --signoff 104 | ``` 105 | 106 | If you are using IntelliJ to commit your changes, be sure to check the Sign-off Commit box in the Commit Changes dialog. 107 | 108 | ### PR best practices 109 | For GlobalDeveloperNetwork projects, we use the following best practices for submitting PRs: 110 | - avoid including unrelated commits 111 | - avoid large changes unless absolutely required 112 | - rebase your branch before submitting 113 | - squash your commits down to a single commit as part of the rebase ([rebase squashing guide](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec)) 114 | - include test cases for any source code changes 115 | - we uses the [ava testing framework](https://github.com/avajs/ava) for node.js development 116 | - we use the [Spock](http://spockframework.org/spock/docs/1.3/index.html) testing framework for our Groovy microservices 117 | - we recommend using Test Driven Development (TDD), writing your tests first and coding the solution to the tests 118 | - include documentation for changes that affect application contracts 119 | 120 | Additionally, when submitting PRs please provide a title that accurately describes the change. If the PR fixes an issue be sure 121 | to reference the issue number in the PR description. Keywords and syntax formatting for issue linking can be found 122 | in the GitHub [documentation](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword). 123 | 124 | ### Specifying issue references 125 | All commits and PRs should link to the original issue being resolved. In order to achieve that, follow the following syntax during commits and PRs: 126 | - Each commit should begin with: `GlobalDeveloperNetwork/#`. 127 | - The same reference, i.e., `GlobalDeveloperNetwork/#` should be added as a comment while creating a PR. 128 | 129 | 130 | ### Code Review 131 | Code review is an important part of our quality control process. As a result, all PRs must go through a review by GlobalDeveloperNetwork 132 | maintainers. After a PR is submitted, one or more reviewers will be assigned to inspect the contribution. Each of the assigned 133 | reviewers will either approve the submission or request changes. Once all requested changes have been addressed, the PR will 134 | be merged by one of the assigned reviewers. 135 | 136 | Our repositories [GitLab](https://docs.gitlab.com/ee/ci/) for private projects and [CircleCI](https://circleci.com/docs/) for public ones, please review the documentation 137 | to understand how the CCI system applicable to you works. Status checks on each repository ensure that changes cannot be merged until both the code review and automated build have 138 | completed successfully. 139 | 140 | To avoid a large backlog of stale PRs we have automation to close requests that have no activity after 2 weeks. 141 | Please make sure to review feedback and engage with our reviewers to get your contribution merged. 142 | 143 | ### Definition of Done 144 | The GlobalDeveloperNetwork development team uses the following checklist to know when a contribution should be considered 'Done'. Each contribution *must*: 145 | - Include a clear description and/or illustration explaining the relevancy of the contribution 146 | - Contain working and clean code that is commented where needed 147 | - Contain passing automated tests that cover the added functionality 148 | - Be reviewed by at least two GlobalDeveloperNetwork maintainers 149 | -------------------------------------------------------------------------------- /docs/PRIVACY_POLICY.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: markdown_page 3 | title: GDN Privacy Policy 4 | description: "On this page you can find information on the GDN Privacy Policy. Learn more!" 5 | canonical_path: "/privacy/" 6 | --- 7 | 8 | _Last updated: 21 January 2021_ 9 | 10 | ## Introduction 11 | 12 | At GDN, we take the privacy and security of your information seriously. This privacy policy (“Privacy Policy”) will explain how we collect, use and share your personal information, and how you may exercise your rights. This Privacy Policy applies to the GDN websites (“Websites”), help.fullstack.llc (“SaaS”), and Self-managed (“Self-managed”) products and services; collectively “Services.” 13 | 14 | “Personal information” as used in this Privacy Policy is information that identifies or can reasonably be linked directly or indirectly to an identifiable person 15 | 16 | ### What personal information does GDN collect about me? 17 | 18 | #### Information You Provide Directly 19 | 20 | We collect the personal information you provide to us, for example: 21 | 22 | _Account Information:_ When you register for an account with GDN, we collect information that identifies you such as your name, username, email address and password. 23 | 24 | _Profile Information:_ We collect information that you voluntarily provide in your user profile; this may include your public avatar (which may be a photo), additional email addresses, company/organization name, job title, country, social media handles, and biography. Please note this information may be visible to other users of the Services and to the public depending on the privacy setting you apply. 25 | 26 | _Payment Information:_ If you purchase a paid subscription from GDN, we will collect payment information from you that may include your name, billing address and credit card or bank information. 27 | 28 | _Contact Information:_ If you request GDN to contact you, or sign up for marketing materials or events, GDN may collect information such as name, address, email address, telephone number, company name, and size of company. 29 | 30 | _Content you provide through the use of the Services:_ When you use the SaaS service, we collect and store content that you post, send, receive and share. Examples of content we collect and store include but are not limited to: the summary and description added to an issue, your repositories, commits, project contributions and comments. Content also includes any code, files and links you upload to the SaaS service. 31 | 32 | If you are using our Self-managed product, we do not host, store, transmit, receive or collect information about you (including your content), except in limited cases, where permitted by your administrator. See the section on “Information about your use of the Services” for more details. 33 | 34 | We may also collect other content that you submit to our Services. For example: feedback, comments and blog posts, or when you participate in any interactive features, surveys, contests, promotions, sweepstakes, activities or events. 35 | 36 | _Customer Support and Professional Services:_ If you contact GDN customer support or receive professional services, we will collect information about you related to your account and to the requests you are making or the services being provided. 37 | 38 | #### Information About Your Use of the Services We Collect Automatically 39 | 40 | _Device Information and Identifiers:_ When you access and use our Services, we automatically collect information about your device, which may include: device type, your device operating system; browser type and version; language preference; IP address, cookie identifiers, hardware identifiers, and mobile IDs. 41 | 42 | _License Information:_ For our Self-managed products we may automatically collect information about the number of active users, historical user count, licensee name, email address, IP address and similar information. 43 | 44 | _Services Usage Data:_ GDN may also collect information about how you use our SaaS and Self-hosted products such as, activity data, feature usage, and product version data. This information may be aggregated or identifiable. For more information about the data collected, and how to set your preferences, please visit [Services Usage Data](https://help.fullstack.llc/services-usage-data/) 45 | 46 | _Website Usage Data:_ When you visit our Websites, we automatically log information about how you interact with the sites, such as the referring site, data and time of visit, and the pages you have viewed or links clicked on. 47 | 48 | _Cookies and Similar Tracking Technologies:_ GDN uses cookies and similar technologies to provide functionality, such as storing your settings, and to recognize you as you use our Services. In addition, we use cookies to gather information to provide interest-based advertising which is tailored to you based on your online activity. Please review our [Cookie Policy](https://help.fullstack.llc/cookies/) to learn about our practices and the controls we provide you. 49 | 50 | _Email marketing:_ When we send you emails, they may include technology such as a web beacon, that tells us your device type, email client, and whether you have received and opened an email, or clicked on any links contained in the email. 51 | 52 | _Buttons, tools, and content from other companies:_ The Services may include links or buttons to third party services such as Facebook and Twitter. We may collect information about your use of these features. In addition, when you see or interact with these buttons, tools, or content, some information from your browser may automatically be sent to the other company. Please read that company’s privacy policy for more information. 53 | 54 | #### Information from Third parties and Partners 55 | 56 | We may also receive information about you from third parties such as vendors, resellers, partners, or affiliates. For example, we receive information from our resellers about you and your orders, or we may supplement the data we collect with demographic information licensed from third parties in order to personalize the Services and our offers to you. 57 | 58 | _Third Party sign-in services:_ GDN allows you to sign up for/in to our Services using third party accounts, such as Facebook or Google. When you give permission for this to happen, GDN will receive information about you from your third-party account, such as name, email address, location and demographic information. 59 | 60 | When you are asked to provide personal data, you may decline. And you may use web browser or operating system controls to prevent certain types of automatic data collection. But if you choose not to provide or allow information that is necessary for certain products or features, those products or features may not be available or function correctly. 61 | 62 | ### How is your personal information used? 63 | 64 | GDN uses your personal information for the following purposes: 65 | - To create your account, identify and authenticate your access to the Services and provide you with the Services you have requested; 66 | - To process your payment for the Services you have purchased; 67 | - To understand how our Services are used and to improve our Services; 68 | - To provide personalized experiences; 69 | - To conduct user research and development; 70 | - To send you important information about the Services; 71 | - To send you information you have requested; 72 | - To send you advertising, marketing content, offers, promotions, newsletters, surveys or other information; 73 | - To respond to your requests for customer support; 74 | - To improve the security of and troubleshoot our Services, as necessary to perform the contract governing your use of our applications or to communicate with you; 75 | - To detect, prevent, or otherwise address fraud and abuse to protect you, GDN, and third parties; 76 | - To enforce the legal terms that govern our Services; 77 | - To comply with our legal obligations; 78 | - To protect the rights, safety and property of GDN, you, or any third party; and 79 | - For other purposes, for which we obtain your consent. 80 | 81 | #### Legal Basis for Processing of your information 82 | 83 | If you are located in the European Economic Area (EEA), United Kingdom, or Switzerland, we collect and process your personal information on the following legal bases set out by applicable law: 84 | 85 | _Performance of a contract:_ We use your personal information to provide the Services you have subscribed to, and to complete and administer the contract you have entered into with GDN. 86 | 87 | _Legitimate Interests:_ We use your personal information for our legitimate interests, such as to provide you with relevant content, improve our products and services, and for administrative, security, fraud prevention and legal purposes. You may object to the processing of your personal information for these purposes at any time. 88 | 89 | _Consent:_ We may use your personal information, with your consent, for specific purposes such as marketing, surveys, and research. You may withdraw your consent for the specific purpose or object to the processing of your personal information at any time. 90 | 91 | ### Who is your information shared with? 92 | 93 | We may share each of the categories of personal information we collect with the types of third parties described below, for the following business purposes: 94 | 95 | _Sharing with Users and the Public:_ We may share your personal information with other users of the Services and with the public if you choose to make your SaaS Profile public. You have control over what information is public. To change your settings, go to [User Settings](https://help.fullstack.llc/profile) in your profile. You should also be aware that any information you share as part of a project, blog, website etc. may be publicly available and you should consider this carefully when interacting with the Services. 96 | 97 | _Sharing with Managed Accounts and Administrators:_ If you have created a GDN account with your corporate email address, we may share your personal information with your Company if your Company enters into a commercial relationship with GDN. If this happens, then your use of the software and your account is subject to the terms and any data protection agreement between your Company and GDN. 98 | 99 | In addition, if you choose to become a member of a project, your username, email address, IP address, the date access was granted, the date access expires, and your access role will be shared with the group owners of that project. 100 | 101 | _Sharing with Service Providers:_ We share your personal information with our service providers. These are companies who provide services on our behalf, such as hosting our Services, marketing, advertising, social, analytics, support ticketing, credit card processing, security and other such similar services. These companies are subject to contractual requirements that govern the security and confidentiality of your information. 102 | 103 | For example, we use analytics providers, such as Google Analytics, to help us understand the operation and performance of our Services. To learn about how Google uses and shares data it collects through its services, please visit . 104 | 105 | _Sharing with Partners and Resellers:_ GDN works with third parties who provide sales, consulting, support and technical services for our Services. Where permitted and with your consent (if required), we may share your data with these partners and resellers. 106 | 107 | _Sharing with Affiliated Companies:_ GDN will share information collected with [companies owned and operated by us](https://help.fullstack.llc/lmg-info-shared). 108 | 109 | _Sharing for Fraud and Prevention Abuse:_ We may share your information when we have a good faith belief that the disclosure is necessary to prevent fraud, abuse of our services, defend against attacks, and to protect the safety of GDN and our users. 110 | 111 | _Law Enforcement:_ GDN may disclose personal information or other information we collect about you to law enforcement if required in response to a valid subpoena, court order, search warrant, a similar government order, or when we believe in good faith that disclosure is necessary to comply with our legal obligations, to protect our property or rights, or those of third parties or the public at large. 112 | 113 | _Merger or Acquisition:_ We may share your personal information if we are involved in a merger, sale, or acquisition of corporate entities or business units. If any such change of ownership happens, we will ensure that it is under terms that preserve the confidentiality of your personal information, and we will notify you on our website or by email before any transfer of your personal information. 114 | 115 | ### Is your personal information transferred across national borders? 116 | 117 | Our Services are hosted in the United States and information we collect will be stored and processed on our servers in the United States. Our employees, contractors, affiliated organizations and processors that process personal information may be located in the United States or other countries outside of your home country. If you reside in the European Economic Area, United Kingdom, or Switzerland, and we transfer information about you to a jurisdiction that has not been found by the European Commission to have adequate data protections, we will use available safeguards and legal mechanisms to help ensure your rights and protections, including using Standard Contractual Clauses or obtaining your consent. 118 | 119 | ### Security 120 | 121 | We work hard to protect your personal information. We employ administrative, technical, and physical security controls where appropriate, to protect your information. For more information on our security practices please see: [Technical and Organizational Security Measures for fullstack.llc](https://help.fullstack.llc/security-by-default). 122 | 123 | ### Data Retention 124 | 125 | GDN will retain your information for as long as your account is active or as needed to perform our contractual obligations, provide you the Services, comply with legal obligations, resolve disputes, preserve legal rights, or enforce our agreements. 126 | 127 | We may delete inactive accounts and associated projects and repositories after a period of twelve (12) months. 128 | 129 | ## Rights and Choices 130 | 131 | You have the right to access, correct, restrict or delete your personal information, and to port your personal information to another company. While these rights may vary by jurisdiction, GDN provides you with the same rights and choices, no matter where you live. 132 | 133 | You may exercise your choices and rights as follows: 134 | 135 | _To opt out of email marketing:_ You may opt-out of email marketing by clicking the “unsubscribe” link located at the bottom of any email you receive or by visiting our [preference center](https://help.fullstack.llc/optout/) and unsubscribing. You may continue to receive transactional email messages about your account and the Service after you have unsubscribed. 136 | 137 | _To opt-out of Interest-based advertising:_ If you wish to opt-out of interest-based advertising, please visit the Cookie Policy to see your options. 138 | 139 | _Request a copy of your information:_ You may [request a copy of the personal information](https://help.fullstack.llc/gdpr-rfi) that GDN has about you. 140 | 141 | _Update your Information:_ If you already have an account, you may access, update, or alter your user profile information by logging into your account and updating profile settings. 142 | 143 | _To delete your Account:_ You may delete your account by logging into your account and going to the “Delete my Account” option in your profile settings. 144 | 145 | Please note that due to the open source nature of our Services, we may etain limited personal information indefinitely in order to provide a transactional history. For example, if you provide your information in connection with a blog post or comment, we may display that information even if you have deleted your account as we do not automatically delete community posts. Also, if you contribute to a public project and you provide your personal information in connection with that contribution, your personal information will be embedded and publicly displayed with your contribution, and we will not be able to delete or erase it because doing so would break the project. 146 | 147 | If you contribute to a GDN project by commenting in, or creating an issue or merge request and you provide your personal information in connection with that contribution, your personal information associated with your contribution will be deleted and attributed to a ghost user. However, please note that if the content of the contribution contains personal information, this information would remain and you will need to submit a specific request to have this information deleted. 148 | 149 | ### California Privacy Rights 150 | 151 | Under the California Consumer Privacy Act (“CCPA”) you are entitled to certain rights such as access to your specific personal information, details about our processing of your personal information, and the right to delete your information. You may exercise all of these rights as described in the “Your Rights and Choices” section. GDN does not sell your personal information, as defined under CCPA, and has not done so for the past 12 months. 152 | 153 | You may designate, in writing or through a power of attorney, an authorized agent to make requests on your behalf to exercise your rights under the CCPA. Before accepting such a request from an agent, we will require the agent to provide proof you have authorized it to act on your behalf, and we may need you to verify your identity directly with us. To provide or delete specific pieces of personal information we will need to verify your identity to the degree of certainty required by law. We will verify your request by using one of the methods set forth [here](https://help.fullstack.llc/gdpr-rfi). 154 | 155 | ### Information GDN Does Not Collect 156 | 157 | GDN does not intentionally collect sensitive personal information, such as social security numbers, genetic data, health information, or religious information. Although GDN does not request or intentionally collect any sensitive personal information, we realize that users might store this kind of information in a GDN repository. 158 | If you are a child under the age of 13, you may not have an account. GDN does not knowingly collect information from, or direct any of our Services to, children under 13. If we learn or have reason to suspect that a user is under the age of 13, we will close the child’s account. 159 | 160 | ### Policy Changes 161 | 162 | GDN may change its Privacy Policy from time to time. When we do, we will update the date at the top of this Policy. If we decide to make a significant change to our Privacy Policy, we will post a notice of the update on the homepage of our Website. We may also provide notification via email of any material changes to our Privacy Policy. 163 | 164 | ### Contact Us 165 | 166 | Your information is stored by GDN on servers owned by Large Ltd., a holdings company, encrypted and stored at AWS Amazon Web Services. 167 | 168 | It's both our responsibility and the responsibility of our parent conglomerate to ensure legal protection and sheltering of the information Large Ltd. maintains privileged access to, and this information will not leave the Large Ltd. corporate umbrella, but may be shared with sister and/or child organizations. We will never sell core data associated with these enterprises, and it will always remain in-tact as captured, immutable or be purged. 169 | 170 | If you have questions or concerns about the way we are handling your information, please email us with the subject line "Privacy Concern" at `support@fullstack.llc`. 171 | -------------------------------------------------------------------------------- /docs/_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-midnight -------------------------------------------------------------------------------- /docs/images/README.md: -------------------------------------------------------------------------------- 1 | All images are certified to not violate DMCA regulations. No copyright infringing images are allowed on this service. 2 | -------------------------------------------------------------------------------- /docs/images/fullstack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GlobalDeveloperNetwork/contributors/725ac01b3a3ffc52fd9cdffb65c44ce992e86984/docs/images/fullstack.png -------------------------------------------------------------------------------- /docs/images/gitops.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GlobalDeveloperNetwork/contributors/725ac01b3a3ffc52fd9cdffb65c44ce992e86984/docs/images/gitops.png -------------------------------------------------------------------------------- /docs/images/opencollective.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GlobalDeveloperNetwork/contributors/725ac01b3a3ffc52fd9cdffb65c44ce992e86984/docs/images/opencollective.png -------------------------------------------------------------------------------- /docs/images/stackops.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GlobalDeveloperNetwork/contributors/725ac01b3a3ffc52fd9cdffb65c44ce992e86984/docs/images/stackops.png -------------------------------------------------------------------------------- /docs/images/stackstandard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GlobalDeveloperNetwork/contributors/725ac01b3a3ffc52fd9cdffb65c44ce992e86984/docs/images/stackstandard.png -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | [![License](https://img.shields.io/badge/license-apache%202.0-yellow)](https://choosealicense.com/licenses/apache-2.0/) 2 | [![Open Source Stacks](https://img.shields.io/badge/Open%20Source%20Stacks-blue)](http://lmg.systems/ssi-roadmap) 3 | [![Groovy](https://img.shields.io/badge/language-Groovy-green)](https://github.com/apache/groovy) 4 | [![Node.js](https://img.shields.io/badge/language-NodeJS-green)](https://npmjs.com) 5 | [![12 Factor App](https://img.shields.io/badge/app-12--factor-yellow)](https://12factor.net/) 6 | 7 | Open Source Collective 8 | 9 | 10 | # Why GDN? 11 | - We have been officially recognized by Open Collective as a non-profit 501(c)(6) 12 | - Our [ROADMAP!](http://lmg.systems/ssi-roadmap) contains a bus full of Open Source Developers! 13 | - We're tinkering away in order to build something [grand](https://codepen.io/largesoft/live/OJRpeBV). 14 | - Rest assured if you enjoy working across the stack, you are in the right place. 15 | 16 | > Please note! Much of the functionality described in this document is in extrordinarily active development (on Gitlab). 17 | 18 | ## Alpha preview 19 | Please sign up for our early adopters & investors alpha release preview using [this form](https://lmg.systems/zeronine) for contributor-level access to it. 20 | 21 | #### If you inhtend on using any code you find published to Github, expect that it will NOT be functional at minimum until the alpha version is released. 22 | It is slated for FY21Q03 which is essentially between now and the end of March. 23 | 24 | # GDN Contributor Information 25 | Welcome to the [Global Developer Network](https://lmg.systems/gdn-osc) 501(c)(6) [Official Open Source Collective](https://lmg.systems/gdn-osc). 26 | Built by code contributions from open source developers world-wide. 27 | 28 | We intend to accept contributions once our non-profit paperwork is officially approved, and 100% will go towards funding this development effort. 29 | We already have some [corporate sponsorship](https://fullstack.llc), but are always looking for more backers. 30 | 31 | # What are we doing? 32 | We are re-inventing the development process for Full Stack applications with an emphasis on business requirements, domain driven operations, security-first specifications with conformance to industry-standard best practices, and test coverage. 33 | 34 | Just ask us! 35 | 36 | # Discord Community 37 | Please join us on [GDN Discord chat](https://discord.gg/r5vXHwgb). 38 | 39 | ## GDN Repo for Contributors 40 | A repository designed for contributors to the [OpenSourceStacks.com](https://fullstack.llc) project, an initiative for providing a management interface for describing, building, and deploying different full stack strategies using open source software. It will provide freelance gigs for open sourcers while connecting them directly to clients, and will use a structured but enjoyable method for the onboarding process, virtual workforce solutions, and business process oversight to augment the experience via the [Full Stack Engine](https://fullstack.llc). 41 | 42 | ## What is this? 43 | A repository for contributor guidelines and other contributor related information. This repository will also contain a branch for the fully transparent open source [StackStandard.com](https://stackstandard.com) registry, which provides a taxonomy of behaviors from which [developers of packages and themes](https://www.notion.so/investhere/2-StackStandard-com-2563664485504dd9860d53a270df8631#78a9826a8a3740f6a7474f2d052a2ff3) may adopt conformance, and adopt usage of security control specifications for which we provide testing. Should you choose to be an early adopter, you will get a fancy badge for your website that says you adhere to these specific standards. We have a great process for validating the tests and presenting the status of your organization, and we will be marketing early adopters in our future campaigns. 44 | 45 | ## Contributor Benefits 46 | * Early access to our GA Amazon AWS Cloud on EKS. 47 | * The ability to debug your stack on our cloud at no cost. 48 | * The ability to test other combinations of stack technology on our service for free. 49 | 50 | Want to contribute dollars or code? 51 | - Please fill out [this form](http://bit.ly/0point9alpha) 52 | 53 | ## Early adoption of the language 54 | #### (Phase 1) 55 | 56 | GDN provides an open collective network of like-minded developers who are all seeking to participate in creating definitions for the Fullstack Domain Specific Language (FDSL) project. The language is actually a superset of GraphQL and can be used that way. It will also come in a short form notation style language that looks very similar to a DSL (Domain Specific Language) and is highly specific to the Full Stack Strategy domain. (i.e.- describing your stack technology and making sure it is fully functional, tested, and compliant with security controls.) 57 | 58 | ## How does it work? 59 | The FDSL provides an abstraction layer for applying `stack actions` at `build time`, and it does this through packages on NPM that are run as docker containers using our CLI. The CLI user does *not* need to worry about Docker or containers, as they are built intrinsically into CLI code. These `stack actions` running as `containers` perform as compilable tasks on your stack, including API calls, Transformations from RAC (results as code), introspection of packages (RASCI/ Results As Secure Code Introspection), attachment of telemetry for stack tracing (Event Listeners), and Fluentd Logging collectors (for attaching streaming logs to Kubernetes) on the stack. We are using [Terraform](https://www.terraform.io/) for some actions, and if you use our cloud, [Vault](https://www.vaultproject.io/) for secrets management controls (otherwise K8s Secrets). 60 | 61 | ### Testing 62 | These same abstractions allow for the inspection (Selenium UAT), unit and internal integration testing of [Docker](https://hub.docker.com/) images, package management, CDN, and other 3rd party software or API dependencies required to be compliant with specific standards in order to be deployed from a CICD pipeline or through `kubectl`. All a package maintainer needs in order to adopt this standard is our CLI tool, which is pluggable and modular, in order to create the `.stack` definition format and publish it to NPM via Git along with a [HELM3](https://helm.sh/docs/topics/charts/) chart of your stack. This is done automatically for multiple packages using the `monorepo` pattern [described here](https://github.com/GlobalDeveloperNetwork/contributors#loading-your-repo). 63 | 64 | > Since a Helm3 chart obviously needs to be created for each backend, we will [provide consulting](https://discord.gg/r5vXHwgb) for various backends until we have a CLI plugin for creating them. We are supporting the following configurations from our first Generally Available (GA) status: 65 | 66 | Google, Microsoft, and Amazon clouds for GraphQL APIs: 67 | 68 | * Postgres with a Hasura Layer, providing the GraphQL API 69 | * Postgres with an Express or Fastify GraphQL API 70 | * Postgres with a NestJS layer and GraphQL API 71 | * MongoDB with an Express or Fastify GraphQL API 72 | * Firestore with a GraphQL API (firestore-apollo) 73 | * Cosmos DB with a GraphQL API (using Hasura and the Postgres driver) 74 | * DocumentDB or DynamoDB with a GraphQL API (using AWS AppSync and Lambda, or DynamoDB configurations) 75 | * Socketclusters.io for streaming listener events. 76 | * Meili search nodes are also supported for those looking to implement realtime search in their cluster. 77 | 78 | ### Out of the box 79 | We provide the following functions out of the box: 80 | - GitOps strategy - i.e.- we abstract away k8s and make it simple to use for developers who don't have a PhD. in clusterology. 81 | - We provide a comprehensive, recursive installation method as post-install hooks so theme and other developers with many packages can publish easily to our system using one repo and by not having to modify all of their packages in egregious ways. 82 | - All code is built using our CLI (`npx gsys` for no global-conflicts one-time-dependency installs) 83 | - All code is tested using local integration tests and the ability to use Gitlab AutoDevOps or Github actions, while still providing test coverage to StackStandard.com. 84 | - All builds are triggered by a condition, action, and event chain that is langage agnostic, pub/sub socket stream-ready, and provides Vault support for runtime secrets. 85 | - Because we provide hosted Vault integration, you can distribute your app using Content Trust on the images and our CLI will store them on a secure Quay repo we maintain. 86 | - If you need digital asset protection, you can choose to encrypt your assets during S3 cold storage. 87 | - Our StackStandard documentation will explain all of our MVP security configurations, [offerings](https://app.getguru.com/card/c86b5pji/What-security-offers-are-going-to-definitely-be-provided-by-the-StackStandardcom-MVP), and more. 88 | 89 | ## What do you mean by a "Stack Definition"? 90 | A stack definition is a `.stack` file that is generated by a developer when creating their [Kubernetes-based](https://kubernetes.io/docs/home/) [Helm chart](https://helm.sh/docs/topics/charts/). Helm is an open source provider of a charting specification that simplifies deployment of K8s YAML by providing a `values.yaml` and `values.schema.json` file. These values are simply filled out by a user and when deployed they are assembled along with the charts. Our stack definition is created for build time operations, not deployment/ runtime. That being said, we still are supporting running build time integration tests via popular CICD. This is achieved by providing simple webhooks through endpoints that can trigger CICD jobs on our servers. Each version pushed to us is immutable and tree-checksums are validated along with DCT, and potentially Notary trust delegations (in the future). So it is trivial to support the use case of external CICD triggers so long as we can validate the chain of trust requesting it. 91 | 92 | ## Build time Ops 93 | Our focus is on the declaration of immutable artifacts that are secured, and provide digital signatures for validation and verification using GPG. We provide our offering separate from Helm via a CLI (Command Line Interface) that will ask you a series of initialization questions, and through your answers deploy a `.stack` definition locally for local testing. 94 | 95 | ## Testing the API 96 | We provide an indivdual language module for each transformation or integration test, this allows for each module to be public and open source in any language (that supports Git workflows), while still providing the flexibility to run locally. It also ensures that modules are versioned and immutable. As you develop your `.stack` file, you can utilize interactive examples that we provide and browse our documentation at [stackStandard.com](https://stackstandard.com) (will be launched by Feb 15th 2021). 97 | 98 | ## Publishing to your Helm chart 99 | Our CLI will update your existing SSI with conformance standards when tests succeed through our API. You can optionally have our CLI add in your stack definition to the Helm chart itself as YAML declarations, but this is not required. This can be highly useful for distributed applications that want to resell and conform to the FSDL. It is also very useful for UI theme, and other types of distributions where the stack needs to be modified idempotently. 100 | 101 | ## Idempotence and Language Support 102 | Right now we are focusing early adoption of just one language: ES6+ for Node.js stacks. In the near future we will be establishing this FSDL in a way that is language agnostic and supports multiple SDKs. We've planned for it, we just can't execute with at least 100 early adopters for each language. 103 | 104 | ## FSDL Privacy 105 | For some use cases where the stack has been modified to work with on-premise or private 3rd party software systems, it may be best to keep the stack definition private. We adhere to a standard that provides both options. See [StackStandard](https://stackstandard.com) for more details. (Launching January 15th 2021) 106 | 107 | # What does DSL describe? 108 | The DSL is actually a querying meta-language that looks much like javascript and/or string literals, just with additional capabilites. It is designed to make it as simple as possible to "ask" for a behavior based on a specific set of conditions and return a "result-as-code" (RAC) response. The responses are stored as Docker containers that are digitally signed, and distributed using NPM as a generic loader that can be easily re-used as individual NPM modules. This allows you to run everythign locally, and at CICD time, with the added benefit of 3rd party auditing (our service) whenever CICD builds are triggered. 109 | 110 | # Loading your repo 111 | 112 | ## Example Monorepo for Authors of multiple packages that want to use the Gitops.Systems (Gsys) and Fullstack DSL (FDSL) for CICD workflows (i.e.- Gitlab AutoDevOps or Github Actions): 113 | ```bash 114 | $ / package.json 115 | { 116 | "install:verify": "cd projects/verification && npx yarn-recursive", // runs tooling package build for encryption and docker manipulation 117 | "install:cli-all": "cd projects/cli-all && npx yarn-recursive", // runs yarn to build via npx the CLI and all supported plugins 118 | "install:PKG": "cd projects/PKG && npx yarn-recursive && \ 119 | ln -s ./PKG ___INSTALL_YOUR_PACKAGES_HERE && \ 120 | npx @fdsl/verify", // verify all of your own supported packages 121 | "postinstall": "npx yarn gsys && ln -s ./.bin/gsys gsys; gsys verify --recursive" // run verification from the gsys CLI 122 | } 123 | ``` 124 | ## Building a Monorepo: 125 | ```bash 126 | npx yarn-run-all 127 | ``` 128 | 129 | ## Example package contained in the directory of your choice: 130 | ```bash 131 | 132 | $ cat package.json | npx gsys publish behavior 133 | { 134 | "name": "@GlobalDeveloperNetwork/module", 135 | "description": "test-behavior", 136 | "version": "1.0.1", 137 | "author": "Full Stack Engine, LLC", 138 | "bin": { 139 | "gsys": "./bin/run load --with-tests=false ${CONDITION}" 140 | }, 141 | "devDependencies": { 142 | "@gsys/loader": "^1.5.9", 143 | "gsys": "^1.1.0"", 144 | "dockerode": "^3.2.1" 145 | } 146 | } 147 | ``` 148 | 149 | All results are digitally signed and encrypted by DCT using a private and public key pair that can verify author authenticity. 150 | The docker images can be [created by Node](https://www.npmjs.com/package/dockerode), since this is the first language we are focusing on support for. 151 | 152 | --- 153 | 154 | # Legal CYA 155 | 156 | Some portions of this repo are from the [CrateKube project](https://github.com/cratekube/cratekube), i.e.- the architectural standards, which is now deprecated by Cisco. 157 | - The code is deprecated and non-licensed, so we are resurrecting some portions of the project for our CLI. 158 | - This has been checked by our legal team and we are compliant with all applicable laws. 159 | 160 | ___ 161 | 162 | > Questions or concerns about content provided by our service? We are DMCA compliant, so if you do have questions that need to be addressed, please contact our [legal](mailto:legal@large.marketing) staff directly. 163 | 164 | 165 | # Current Sponsors 166 | 167 | 168 | 169 | 172 | 175 | 178 | 181 | 182 |
170 | Stack Standard 171 | 173 | Stack Ops 174 | 176 | Git Ops 177 | 179 | Full Stack 180 |
183 | 184 | 185 | 186 | 187 | 188 | # License Notice 189 | 190 | ___ 191 | Copyright 2021. Global Developer Network (GDN). 192 | 110 Corcoran street, Durham, NC 27701. USA. 193 | 194 | Licensed under the Apache License, Version 2.0 (the "License"); 195 | you may not use this file except in compliance with the License. 196 | You may obtain a copy of the License at 197 | 198 | http://www.apache.org/licenses/LICENSE-2.0 199 | 200 | Unless required by applicable law or agreed to in writing, software 201 | distributed under the License is distributed on an "AS IS" BASIS, 202 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 203 | See the License for the specific language governing permissions and 204 | limitations under the License. 205 | 206 | 214 | --------------------------------------------------------------------------------