From a996cea8ae2d3c1f4adeb8122bf35450c3d3c561 Mon Sep 17 00:00:00 2001 From: Cezar Silva Date: Mon, 28 Oct 2024 22:21:54 -0300 Subject: [PATCH 01/17] Initialize develop --- .github/docs/CODE_OF_CONDUCT.md | 69 +++++ .github/docs/CONTRIBUTING.md | 321 +++++++++++++++++++++++ .github/docs/PULL_REQUEST_TEMPLATE.md | 41 +++ README.md | 32 +-- docs/CODE_OF_CONDUCT.md | 89 ++++--- docs/CONTRIBUTING.md | 358 +++++++++++++------------- docs/PULL_REQUEST_TEMPLATE.md | 60 +++-- 7 files changed, 681 insertions(+), 289 deletions(-) create mode 100644 .github/docs/CODE_OF_CONDUCT.md create mode 100644 .github/docs/CONTRIBUTING.md create mode 100644 .github/docs/PULL_REQUEST_TEMPLATE.md diff --git a/.github/docs/CODE_OF_CONDUCT.md b/.github/docs/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..6f46866 --- /dev/null +++ b/.github/docs/CODE_OF_CONDUCT.md @@ -0,0 +1,69 @@ +# Contributor Code of Conduct + +**Table of Contents:** + +* [Summary](#summary) +* [Our Standards](#our-standards) +* [Our Responsibilities](#our-responsibilities) +* [Scope](#scope) +* [Enforcement](#enforcement) +* [Attribution](#attribution) + +**Version**: 1.0.2 + +## Summary + +As contributors and maintainers of Embedded Artistry projects, we will respect everyone who contributes by posting issues, updating documentation, submitting pull requests, providing feedback in comments, and any other activities. + +Communication regarding Embedded Artistry projects through any channel must be constructive and never resort to personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct. Courtesy and respect shall be extended to everyone involved in this project. Our experiences as individuals differs widely, and as such contributors are expected to be respectful of differing viewpoints and ideas. + +We expect all contributors to uphold our standards of conduct. If any member of the community violates this code of conduct, the Embedded Artistry team and project maintainers will take action. We reserve the right to remove issues, comments, and PRs that do not comply with our conduct standards. Repeated or significant offenses will result in blocked accounts and disassociation with our projects and the Embedded Artistry community. + +If you are subject to or witness unacceptable behavior, or have any other concerns, please email us at contact@embeddedartistry.com. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or + advances +* Trolling +* Insults or other derogatory comments +* Personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, discussions in the Embedded Artistry forum, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting Embedded Artistry at contact@embeddedartistry.com. + +All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. We are obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], [version 1.4][version] + +[homepage]: https://www.contributor-covenant.org +[version]: https://www.contributor-covenant.org/version/1/4/code-of-conduct.html \ No newline at end of file diff --git a/.github/docs/CONTRIBUTING.md b/.github/docs/CONTRIBUTING.md new file mode 100644 index 0000000..fbf15a1 --- /dev/null +++ b/.github/docs/CONTRIBUTING.md @@ -0,0 +1,321 @@ +# Contributing Guide + +Write something nice and instructive as an intro. Talk about what kind of contributions you are interested in. + +> Welcome! We love receiving contributions from our community, so thanks for stopping by! There are many ways to contribute, including submitting bug reports, improving documentation, submitting feature requests, reviewing new submissions, or contributing code that can be incorporated into the project. + +This document describes our development process. Following these guidelines shows that you respect the time and effort of the developers managing this project. In return, you will be shown respect in addressing your issue, reviewing your changes, and incorporating your contributions. + +If you're not looking for some kinds of contributions, note that up front: + +> Please, don't use the issue tracker for support questions. Instead use: a, b, or Stack Overflow. + +**Table of Contents:** + +1. [Code of Conduct](#code-of-conduct) +2. [Important Resources](#important-resources) +2. [Questions](#questions) +3. [Feature Requests](#feature-requests) +4. [Improving Documentation](#improving-documentation) +5. [Reporting Bugs](#reporting-bugs) +6. [Contributing Code](#contributing-code) + 1. [Getting Started](#getting-started) + 1. [Finding an Issue!](#finding-an-issue) + 1. [Development Process](#development-process) + 1. [Building the Project](#building-the-project) + 1. [Testing](#testing) + 1. [Style Guidelines](#style-guidelines) + 1. [Code Formatting Rules](#code-formatting) + 1. [Whitespace Cleanup](#whitespace-cleanup) +1. [Pull Request Guidelines](#pull-request-process) + 1. [Review Process](#review-process) + 1. [Addressing Feedback](#addressing-feedback) +1. [Community](#community) + + +## Code of Conduct + +If you have a code of conduct document: + +> By participating in this project, you agree to abide by our [Code of Conduct][0]. We expect all contributors to follow the [Code of Conduct][0] and to treat fellow humans with respect. + +If not, lay some ground rules down up front. + +## Important Resources + +Include Short Links to Important Resources: + +* docs: handbook / road map +* bugs: issue tracker / bug report tool +* comms: forum link, developer list, IRC/email +* wiki + +## Questions + +How do you prefer people to ask questions? Via an issue? Is there an IRC channel, Google group, or other way to get help? Should issues that are questions get a specific label? Can they email you directly? + +## Feature Requests + +Provide information on the process for requesting new features. Do you have a specific label that should be applied? Is sign-off needed? + +If you have a road map, goals, works in progress, or a development philosophy, make sure to share the information. Try to make sure that users have enough information to evaluate whether a feature request is appropriate for your project up front. Examples: + +> Please create a new GitHub issue for any major changes and enhancements that you wish to make. Please provide the feature you would like to see, why you need it, and how it will work. Discuss your ideas transparently and get community feedback before proceeding. + +> Major Changes that you wish to contribute to the project should be discussed first in an GitHub issue that clearly outlines the changes and benefits of the feature. + +> Small Changes can directly be crafted and submitted to the GitHub Repository as a Pull Request. See the section about Pull Request Submission Guidelines, and for detailed information the core development documentation. + +## Reporting Bugs + +**If you find a security vulnerability, do NOT open an issue. Email EMAIL@DOMAIN.COM instead.** + +Ask contributors to check before filing a new issue. Also, provide any references to FAQs or debugging guides that you might have. + +> Before you submit your issue, please [search the issue archive][6] - maybe your question or issue has already been identified or addressed. + +Tell contributors how to file a useful bug report. What information do you need? (e.g. version, architecture, log files, expected behavior, observed behavior). + +> If you find a bug in the source code, you can help us by [submitting an issue to our GitHub issue tracker][6]. Even better, you can submit a Pull Request with a fix. + +Does your project use an issue template? Provide instructions and expectations for filling it out. + +Have you seen an awesome issue report? Link to it for others to view! + +## Improving Documentation + +Include notes for how users can improve the documentation. + +> Should you have a suggestion for the documentation, you can open an issue and outline the problem or improvement you have - however, creating the doc fix yourself is much better! + +> If you want to help improve the docs, it's a good idea to let others know what you're working on to minimize duplication of effort. Create a new issue (or comment on a related existing one) to let others know what you're working on. If you're making a small change (typo, phrasing) don't worry about filing an issue first. + +> For large fixes, please build and test the documentation before submitting the PR to be sure you haven't accidentally introduced any layout or formatting issues. + +``` +Provide instructions on building and viewing documentation +``` + +## Contributing Code + +This section is used to get new contributors up and running with dependencies, development, testing, style rules, formatting rules, and other things they should know. + +If you have a label for beginner issues, talk about that here so they know where to look: + +> Unsure where to begin contributing to Atom? You can start by looking through these beginner and help-wanted issues: Beginner issues - issues which should only require a few lines of code, and a test or two. Help wanted issues - issues which should be a bit more involved than beginner issues. + +Working on your first open source project or pull request? Here are some helpful tutorials: + +* [How to Contribute to an Open Source Project on GitHub][2] +* [Make a Pull Request][3] +* [First Timers Only][4] + +### Getting Started + +Install these dependencies: + +``` +with some examples +``` + +Provide some instructions for your work flow (e.g. fork the repository) + +> You will need to fork the main repository to work on your changes. Simply navigate to our GitHub page and click the "Fork" button at the top. Once you've forked the repository, you can clone your new repository and start making edits. + +> In git it is best to isolate each topic or feature into a “topic branch”. While individual commits allow you control over how small individual changes are made to the code, branches are a great way to group a set of commits all related to one feature together, or to isolate different efforts when you might be working on multiple topics at the same time. + +> While it takes some experience to get the right feel about how to break up commits, a topic branch should be limited in scope to a single issue + +``` +# Checkout the master branch - you want your new branch to come from master +git checkout master + +# Create a new branch named newfeature (give your branch its own simple informative name) +git branch newfeature + +# Switch to your new branch +git checkout newfeature +``` + +For more information on the GitHub fork and pull-request processes, [please see this helpful guide][5]. + +### Finding an Issue + +The list of outstanding feature requests and bugs can be found on our on our [GitHub issue tracker][6]. Pick an unassigned issue that you think you can accomplish and add a comment that you are attempting to do it. + +Provide notes on different kinds of issues or labels + +> `starter` labeled issues are deemed to be good low-hanging fruit for newcomers to the project +> `help-wanted` labeled issues may be more difficult than `starter` and may include new feature development +> `doc` labeled issues must only touch content in the `docs` folder. + +### Development Process + +What is your development process? + +> This project follows the [git flow](http://nvie.com/posts/a-successful-git-branching-model/) branching model of product development. + +Talk about branches people should work on. Specifically, where is the starting point? `master`, `development`, etc. + +> You should be using the master branch for the most stable release; please review [release notes](https://github.com/openopps/openopps-platform/releases) regularly. We do releases every week or two and send out notes. If you want to keep up with the latest changes, we work in the `dev` branch. If you are using dev, keep an eagle-eye on commits and/or join our daily stand-up. + +### Building the Project + +What branches should be work be started off of? + +Include instructions on how to build the project. + +``` +with some examples +``` + +Provide instructions on adding a new file/module to the build + +``` +with some examples +``` + +Keep your tests as simple as possible. + +### Testing + +If you add code you need to add tests! We’ve learned the hard way that code without tests is undependable. If your pull request reduces our test coverage because it lacks tests then it will be rejected. + +Provide instructions for adding new tests. Provide instructions for running tests. + +``` +with examples +``` + +### Style Guidelines + +If your code has any style guidelines, add them here or provide links to relevant documents. If you have an automated checker, make sure to provide instructions on how to run it. + +### Code Formatting + +If your code has any formatting guidelines that aren't covered in the style guidelines above, add them here. + +If you're using an auto-formatting tool like clang-format + +``` +Provide instructions for running the formatting tool +``` + +### Whitespace Cleanup + +Don’t mix code changes with whitespace cleanup! If you are fixing whitespace, include those changes separately from your code changes. If your request is unreadable due to whitespace changes, it will be rejected. + +> Please submit whitespace cleanups in a separate pull request. + +### Git Commit Guidelines + +Do you have any guidelines for your commit messages? Include them here. + +> The first line of the commit log must be treated as as an email +subject line. It must be strictly no greater than 50 characters long. +The subject must stand on its own and not only make external +references such as to relevant bug numbers. + +> The second line must be blank. + +> The third line begins the body of the commit message (one or more +paragraphs) describing the details of the commit. Paragraphs are each +separated by a blank line. Paragraphs must be word wrapped to be no +longer than 76 characters. + +> The last part of the commit log should contain all "external +references", such as which issues were fixed. + +> For further notes about git commit messages, [please read this blog post][7]. + +## Pull Request Process + +Do you have any labeling conventions? + +Add notes for pushing your branch: + +> When you are ready to generate a pull request, either for preliminary review, or for consideration of merging into the project you must first push your local topic branch back up to GitHub: + +``` +git push origin newfeature +``` + +Include a note about submitting the PR: + +> Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to your branch. Your pull request will automatically track the changes on your development branch and update. + +1. Ensure any install or build dependencies are removed before the end of the layer when doing a + build. +2. Update the README.md with details of changes to the interface, this includes new environment + variables, exposed ports, useful file locations and container parameters. +3. Increase the version numbers in any examples files and the README.md to the new version that this + Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/). +4. You may merge the Pull Request in once you have the sign-off of two other developers, or if you + do not have permission to do that, you may request the second reviewer to merge it for you. + +### Review Process + +Who reviews it? Who needs to sign off before it’s accepted? When should a contributor expect to hear from you? How can contributors get commit access, if at all? + +> The core team looks at Pull Requests on a regular basis in a weekly triage meeting that we hold in a public Google Hangout. The hangout is announced in the weekly status updates that are sent to the puppet-dev list. Notes are posted to the Puppet Community community-triage repo and include a link to a YouTube recording of the hangout. After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity. + +> Except for critical, urgent or very small fixes, we try to leave pull requests open for most of the day or overnight if something comes in late in the day, so that multiple people have the chance to review/comment. Anyone who reviews a pull request should leave a note to let others know that someone has looked at it. For larger commits, we like to have a +1 from someone else on the core team and/or from other contributor(s). Please note if you reviewed the code or tested locally -- a +1 by itself will typically be interpreted as your thinking its a good idea, but not having reviewed in detail. + +Perhaps also provide the steps your team will use for checking a PR. Or discuss the steps run on your CI server if you have one. This will help developers understand how to investigate any failures or test the process on their own. + +### Addressing Feedback + +Once a PR has been submitted, your changes will be reviewed and constructive feedback may be provided. Feedback isn't meant as an attack, but to help make sure the highest-quality code makes it into our project. Changes will be approved once required feedback has been addressed. + +If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your fork so it's easier to merge. + +To update your forked repository, follow these steps: + +``` +# Fetch upstream master and merge with your repo's master branch +git fetch upstream +git checkout master +git merge upstream/master + +# If there were any new commits, rebase your development branch +git checkout newfeature +git rebase master +``` + +If too much code has changed for git to automatically apply your branches changes to the new master, you will need to manually resolve the merge conflicts yourself. + +Once your new branch has no conflicts and works correctly, you can override your old branch using this command: + +``` +git push -f +``` + +Note that this will overwrite the old branch on the server, so make sure you are happy with your changes first! + +## Community + +Do you have a mailing list, Google group, slack channel, IRC channel? Link to them here. + +> Anyone actively contributing to or using OpenOpps should join our [Mailing List](https://groups.google.com/forum/#!forum/openopps-platform). +We also have a public Slack chat team. If you're interested in following along with the development process or have questions, feel free to [join us](https://openopps.slack.com). + +Include Other Notes on how people can contribute + +* You can help us answer questions our users have here: +* You can help build and design our website here: +* You can help write blog posts about the project by: +* You can help with newsletters and internal communications by: + +* Create an example of the project in real world by building something or +showing what others have built. +* Write about other people’s projects based on this project. Show how +it’s used in daily life. Take screenshots and make videos! + +[0]: CODE_OF_CONDUCT.md +[1]: style_guidelines.md +[2]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github +[3]: http://makeapullrequest.com/ +[4]: http://www.firsttimersonly.com +[5]: https://gist.github.com/Chaser324/ce0505fbed06b947d962 +[6]: link/to/your/project/issue/tracker +[7]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html \ No newline at end of file diff --git a/.github/docs/PULL_REQUEST_TEMPLATE.md b/.github/docs/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 0000000..376cc94 --- /dev/null +++ b/.github/docs/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,41 @@ +# Pull Request Template + +## Description + +Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. + +Fixes # (issue) + +## Type of change + +Please delete options that are not relevant. + +- [ ] Bug fix (non-breaking change which fixes an issue) +- [ ] New feature (non-breaking change which adds functionality) +- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) +- [ ] This change requires a documentation update + +## How Has This Been Tested? + +Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration + +- [ ] Test A +- [ ] Test B + +**Test Configuration**: +* Firmware version: +* Hardware: +* Toolchain: +* SDK: + +## Checklist: + +- [ ] My code follows the style guidelines of this project +- [ ] I have performed a self-review of my own code +- [ ] I have commented my code, particularly in hard-to-understand areas +- [ ] I have made corresponding changes to the documentation +- [ ] My changes generate no new warnings +- [ ] I have added tests that prove my fix is effective or that my feature works +- [ ] New and existing unit tests pass locally with my changes +- [ ] Any dependent changes have been merged and published in downstream modules +- [ ] I have checked my code and corrected any misspellings \ No newline at end of file diff --git a/README.md b/README.md index 9155b16..bfdbd0b 100644 --- a/README.md +++ b/README.md @@ -1,31 +1 @@ -# Configuration Server - -Servidor de Configuração dedicado a armazenar arquivos de configurações das aplicações e de oferecer serviço rest para disponibilizar os dados. - -## Estrutura do projeto - -``` text - -├── .github -│ └── workflows -│ └── script -│ └── manifest.sh -│ └── postgres.yml -│ └── grafana.yml -│ └── deploy.yml -├── app -│ └── profile -│ └── service -├── docs -│ └── CONTRIBUTING.md -│ └── CODE_OF_CONDUCT.md -│ └── PULL_REQUEST_TEMPLATE.md -└── README.md -``` - -## Licença - -> [!IMPORTANT] -> *O código fonte neste projeto não possui licença de uso.* - -É terminantemente proibido reproduzir, distribuir, alterar, utilizar engenharia reversa ou valer-se de qualquer tentativa de reverter ao seu código-fonte qualquer dos componentes que compõem o SOFTWARE, bem como utilizar subterfúgios para burlar a quantidade de usuários licenciados. +# template diff --git a/docs/CODE_OF_CONDUCT.md b/docs/CODE_OF_CONDUCT.md index db26ae8..bdf8226 100644 --- a/docs/CODE_OF_CONDUCT.md +++ b/docs/CODE_OF_CONDUCT.md @@ -1,70 +1,69 @@ -# Contributor Code of Conduct# Código de Conduta do Colaborador +# Contributor Code of Conduct -**Índice:** +**Table of Contents:** -* [Resumo](#resumo) -* [Nossos Padrões](#nossos-padrões) -* [Nossas responsabilidades](#nossas-responsabilidades) -* [Escopo](#escopo) -* [Aplicação](#aplicação) -* [Atribuição](#atribuição) +* [Summary](#summary) +* [Our Standards](#our-standards) +* [Our Responsibilities](#our-responsibilities) +* [Scope](#scope) +* [Enforcement](#enforcement) +* [Attribution](#attribution) -**Versão**: 1.0.2 +**Version**: 1.0.2 -## Resumo +## Summary -Como contribuidores e mantenedores de projetos do Embedded Artistry, respeitaremos todos que contribuem postando problemas, atualizando documentação, enviando pull requests, fornecendo feedback em comentários e quaisquer outras atividades. +As contributors and maintainers of Embedded Artistry projects, we will respect everyone who contributes by posting issues, updating documentation, submitting pull requests, providing feedback in comments, and any other activities. -A comunicação relativa aos projetos da Embedded Artistry através de qualquer canal deve ser construtiva e nunca recorrer a ataques pessoais, trolling, assédio público ou privado, insultos ou outra conduta não profissional. Cortesia e respeito devem ser estendidos a todos os envolvidos neste projeto. Nossas experiências como indivíduos diferem amplamente e, como tais, espera-se que os colaboradores respeitem os diferentes pontos de vista e ideias. +Communication regarding Embedded Artistry projects through any channel must be constructive and never resort to personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct. Courtesy and respect shall be extended to everyone involved in this project. Our experiences as individuals differs widely, and as such contributors are expected to be respectful of differing viewpoints and ideas. -Esperamos que todos os colaboradores mantenham nossos padrões de conduta. Se algum membro da comunidade violar este código de conduta, a equipe da Embedded Artistry e os mantenedores do projeto entrarão em ação. Reservamo-nos o direito de remover questões, comentários e PRs que não estejam em conformidade com nossos padrões de conduta. Ofensas repetidas ou significativas resultarão no bloqueio de contas e na dissociação de nossos projetos e da comunidade Embedded Artistry. +We expect all contributors to uphold our standards of conduct. If any member of the community violates this code of conduct, the Embedded Artistry team and project maintainers will take action. We reserve the right to remove issues, comments, and PRs that do not comply with our conduct standards. Repeated or significant offenses will result in blocked accounts and disassociation with our projects and the Embedded Artistry community. -Se você estiver sujeito ou testemunhar um comportamento inaceitável, ou tiver qualquer outra preocupação, envie um email para contact@embeddedartistry.com. +If you are subject to or witness unacceptable behavior, or have any other concerns, please email us at contact@embeddedartistry.com. -## Nossos padrões +## Our Standards -Exemplos de comportamentos que contribuem para a criação de um ambiente positivo -incluem: +Examples of behavior that contributes to creating a positive environment +include: -* Usando uma linguagem acolhedora e inclusiva -* Respeitar diferentes pontos de vista e experiências -* Aceitar graciosamente críticas construtivas -* Foco no que é melhor para a comunidade -* Mostrar empatia para com outros membros da comunidade +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members -Exemplos de comportamento inaceitável por parte dos participantes incluem: +Examples of unacceptable behavior by participants include: -* O uso de linguagem ou imagens sexualizadas e atenção sexual indesejada ou - avanços -* Trollagem -* Insultos ou outros comentários depreciativos -* Ataques pessoais ou políticos -* Assédio público ou privado -* Publicar informações privadas de terceiros, como endereços físicos ou eletrônicos, sem permissão explícita +* The use of sexualized language or imagery and unwelcome sexual attention or + advances +* Trolling +* Insults or other derogatory comments +* Personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting -* Outra conduta que poderia razoavelmente ser considerada inadequada em um ambiente profissional +## Our Responsibilities -## Nossas responsabilidades +Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. -Os mantenedores do projeto são responsáveis ​​por esclarecer os padrões de comportamento aceitável e espera-se que tomem medidas corretivas apropriadas e justas em resposta a quaisquer casos de comportamento inaceitável. +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. -Os mantenedores do projeto têm o direito e a responsabilidade de remover, editar ou rejeitar comentários, commits, códigos, edições de wiki, problemas e outras contribuições que não estejam alinhadas com este Código de Conduta, ou de banir temporária ou permanentemente qualquer contribuidor por outros comportamentos que eles considerem inadequados, ameaçadores, ofensivos ou prejudiciais. +## Scope -## Escopo +This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, discussions in the Embedded Artistry forum, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. -Este Código de Conduta se aplica tanto nos espaços do projeto quanto nos espaços públicos quando um indivíduo representa o projeto ou sua comunidade. Exemplos de representação de um projeto ou comunidade incluem usar um endereço de e-mail oficial do projeto, postar através de uma conta oficial de mídia social, discussões no fórum Embedded Artistry ou atuar como representante nomeado em um evento online ou offline. A representação de um projeto pode ser definida e esclarecida pelos mantenedores do projeto. +## Enforcement -## Aplicação +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting Embedded Artistry at contact@embeddedartistry.com. -Instâncias de comportamento abusivo, de assédio ou de outra forma inaceitável podem ser relatadas entrando em contato com a Embedded Artistry em contact@embeddedartistry.com. +All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. We are obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. -Todas as reclamações serão analisadas e investigadas e resultarão numa resposta considerada necessária e adequada às circunstâncias. Somos obrigados a manter a confidencialidade em relação ao relator de um incidente. Mais detalhes sobre políticas de aplicação específicas podem ser publicados separadamente. +Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. -Os mantenedores do projeto que não seguirem ou aplicarem o Código de Conduta de boa fé poderão enfrentar repercussões temporárias ou permanentes, conforme determinado por outros membros da liderança do projeto. +## Attribution -## Atribuição +This Code of Conduct is adapted from the [Contributor Covenant][homepage], [version 1.4][version] -Este Código de Conduta foi adaptado do [Acordo do Colaborador][página inicial], [versão 1.4][versão] - -[página inicial]: https://www.contributor-covenant.org -[versão]: https://www.contributor-covenant.org/version/1/4/code-of-conduct.html \ No newline at end of file +[homepage]: https://www.contributor-covenant.org +[version]: https://www.contributor-covenant.org/version/1/4/code-of-conduct.html diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index b0d9904..fbf15a1 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -1,327 +1,321 @@ -# Guia de contribuição +# Contributing Guide -Escreva algo agradável e instrutivo como introdução. Fale sobre que tipo de contribuições você está interessado. +Write something nice and instructive as an intro. Talk about what kind of contributions you are interested in. -> Bem vindo! Adoramos receber contribuições da nossa comunidade, por isso, obrigado pela visita! Há muitas maneiras de contribuir, incluindo enviar relatórios de bugs, melhorar a documentação, enviar solicitações de recursos, revisar novos envios ou contribuir com código que pode ser incorporado ao projeto. +> Welcome! We love receiving contributions from our community, so thanks for stopping by! There are many ways to contribute, including submitting bug reports, improving documentation, submitting feature requests, reviewing new submissions, or contributing code that can be incorporated into the project. -Este documento descreve nosso processo de desenvolvimento. Seguir essas diretrizes mostra que você respeita o tempo e o esforço dos desenvolvedores que gerenciam este projeto. Em troca, você será respeitado ao abordar seu problema, revisar suas alterações e incorporar suas contribuições. +This document describes our development process. Following these guidelines shows that you respect the time and effort of the developers managing this project. In return, you will be shown respect in addressing your issue, reviewing your changes, and incorporating your contributions. -Se você não está procurando algum tipo de contribuição, observe isso antecipadamente: +If you're not looking for some kinds of contributions, note that up front: -> Por favor, não use o rastreador de problemas para perguntas de suporte. Em vez disso, use: a, b ou Stack Overflow. +> Please, don't use the issue tracker for support questions. Instead use: a, b, or Stack Overflow. -**Índice:** +**Table of Contents:** -1. [Código de Conduta](#código-de-conduta) -2. [Recursos importantes](#recursos importantes) -2. [Perguntas](#perguntas) -3. [Solicitações de recursos](#feature-requests) -4. [Melhorando a documentação](#improving-documentation) -5. [Relatando Bugs](#reporting-bugs) -6. [Código de contribuição](#código de contribuição) - 1. [Primeiros passos](#primeiros passos) - 1. [Encontrando um problema!](#encontrando um problema) - 1. [Processo de Desenvolvimento](#processo de desenvolvimento) - 1. [Construindo o Projeto](#construindo o Projeto) - 1. [Teste](#teste) - 1. [Diretrizes de estilo](#diretrizes de estilo) - 1. [Regras de formatação de código](#code-formatting) - 1. [Limpeza de espaço em branco](#limpeza de espaço em branco) -1. [Diretrizes de solicitação pull](#pull-request-process) - 1. [Processo de revisão](#processo de revisão) - 1. [Feedback de endereçamento](#feedback de endereçamento) -1. [Comunidade](#comunidade) +1. [Code of Conduct](#code-of-conduct) +2. [Important Resources](#important-resources) +2. [Questions](#questions) +3. [Feature Requests](#feature-requests) +4. [Improving Documentation](#improving-documentation) +5. [Reporting Bugs](#reporting-bugs) +6. [Contributing Code](#contributing-code) + 1. [Getting Started](#getting-started) + 1. [Finding an Issue!](#finding-an-issue) + 1. [Development Process](#development-process) + 1. [Building the Project](#building-the-project) + 1. [Testing](#testing) + 1. [Style Guidelines](#style-guidelines) + 1. [Code Formatting Rules](#code-formatting) + 1. [Whitespace Cleanup](#whitespace-cleanup) +1. [Pull Request Guidelines](#pull-request-process) + 1. [Review Process](#review-process) + 1. [Addressing Feedback](#addressing-feedback) +1. [Community](#community) -## Código de Conduta -Se você tiver um documento de código de conduta: +## Code of Conduct -> Ao participar deste projeto, você concorda em cumprir nosso [Código de Conduta][0]. Esperamos que todos os colaboradores sigam o [Código de Conduta][0] e tratem os outros seres humanos com respeito. +If you have a code of conduct document: -Caso contrário, estabeleça algumas regras básicas desde o início. +> By participating in this project, you agree to abide by our [Code of Conduct][0]. We expect all contributors to follow the [Code of Conduct][0] and to treat fellow humans with respect. -## Recursos importantes +If not, lay some ground rules down up front. -Inclua links curtos para recursos importantes: +## Important Resources -* documentos: manual / roteiro -* bugs: rastreador de problemas / ferramenta de relatório de bugs -* comunicações: link do fórum, lista de desenvolvedores, IRC/e-mail +Include Short Links to Important Resources: + +* docs: handbook / road map +* bugs: issue tracker / bug report tool +* comms: forum link, developer list, IRC/email * wiki -## Questões +## Questions -Como você prefere que as pessoas façam perguntas? Por meio de um problema? Existe um canal de IRC, grupo do Google ou outra forma de obter ajuda? As questões que são perguntas deveriam receber um rótulo específico? Eles podem enviar um e-mail diretamente para você? +How do you prefer people to ask questions? Via an issue? Is there an IRC channel, Google group, or other way to get help? Should issues that are questions get a specific label? Can they email you directly? -## Solicitações de recursos +## Feature Requests -Forneça informações sobre o processo de solicitação de novos recursos. Você tem um rótulo específico que deve ser aplicado? A aprovação é necessária? +Provide information on the process for requesting new features. Do you have a specific label that should be applied? Is sign-off needed? -Se você tiver um roteiro, metas, trabalhos em andamento ou uma filosofia de desenvolvimento, compartilhe as informações. Tente garantir que os usuários tenham informações suficientes para avaliar antecipadamente se uma solicitação de recurso é apropriada para o seu projeto. Exemplos: +If you have a road map, goals, works in progress, or a development philosophy, make sure to share the information. Try to make sure that users have enough information to evaluate whether a feature request is appropriate for your project up front. Examples: -> Crie um novo problema no GitHub para quaisquer alterações e melhorias importantes que você deseja fazer. Forneça o recurso que você gostaria de ver, por que precisa dele e como funcionará. Discuta suas ideias de forma transparente e obtenha feedback da comunidade antes de prosseguir. +> Please create a new GitHub issue for any major changes and enhancements that you wish to make. Please provide the feature you would like to see, why you need it, and how it will work. Discuss your ideas transparently and get community feedback before proceeding. -> As principais alterações com as quais você deseja contribuir para o projeto devem ser discutidas primeiro em uma edição do GitHub que descreva claramente as alterações e os benefícios do recurso. +> Major Changes that you wish to contribute to the project should be discussed first in an GitHub issue that clearly outlines the changes and benefits of the feature. -> Pequenas alterações podem ser criadas diretamente e enviadas ao repositório GitHub como uma solicitação pull. Consulte a seção sobre Diretrizes para envio de solicitações pull e, para obter informações detalhadas, a documentação principal de desenvolvimento. +> Small Changes can directly be crafted and submitted to the GitHub Repository as a Pull Request. See the section about Pull Request Submission Guidelines, and for detailed information the core development documentation. -## Relatando Bugs +## Reporting Bugs -**Se você encontrar uma vulnerabilidade de segurança, NÃO abra um problema. Em vez disso, envie um e-mail para EMAIL@DOMAIN.COM.** +**If you find a security vulnerability, do NOT open an issue. Email EMAIL@DOMAIN.COM instead.** -Peça aos colaboradores para verificarem antes de registrar um novo problema. Além disso, forneça referências a perguntas frequentes ou guias de depuração que você possa ter. +Ask contributors to check before filing a new issue. Also, provide any references to FAQs or debugging guides that you might have. -> Antes de enviar seu problema, [pesquise o arquivo de problemas][6] - talvez sua dúvida ou problema já tenha sido identificado ou resolvido. +> Before you submit your issue, please [search the issue archive][6] - maybe your question or issue has already been identified or addressed. -Diga aos colaboradores como registrar um relatório de bug útil. De que informações você precisa? (por exemplo, versão, arquitetura, arquivos de log, comportamento esperado, comportamento observado). +Tell contributors how to file a useful bug report. What information do you need? (e.g. version, architecture, log files, expected behavior, observed behavior). -> Se você encontrar um bug no código-fonte, você pode nos ajudar [enviando um problema para nosso rastreador de problemas do GitHub][6]. Melhor ainda, você pode enviar uma solicitação pull com uma correção. +> If you find a bug in the source code, you can help us by [submitting an issue to our GitHub issue tracker][6]. Even better, you can submit a Pull Request with a fix. -Seu projeto usa um modelo de problema? Forneça instruções e expectativas para preenchê-lo. +Does your project use an issue template? Provide instructions and expectations for filling it out. -Você viu um relatório de problema incrível? Link para ele para que outros vejam! +Have you seen an awesome issue report? Link to it for others to view! -## Melhorando a documentação +## Improving Documentation -Inclua notas sobre como os usuários podem melhorar a documentação. +Include notes for how users can improve the documentation. -> Se você tiver uma sugestão para a documentação, poderá abrir um problema e descrever o problema ou melhoria que possui - no entanto, criar você mesmo a correção do documento é muito melhor! +> Should you have a suggestion for the documentation, you can open an issue and outline the problem or improvement you have - however, creating the doc fix yourself is much better! -> Se você quiser ajudar a melhorar a documentação, é uma boa ideia informar outras pessoas no que você está trabalhando para minimizar a duplicação de esforços. Crie um novo problema (ou comente um problema existente) para que outras pessoas saibam no que você está trabalhando. Se você estiver fazendo uma pequena alteração (erro de digitação, frase), não se preocupe em registrar um problema primeiro. +> If you want to help improve the docs, it's a good idea to let others know what you're working on to minimize duplication of effort. Create a new issue (or comment on a related existing one) to let others know what you're working on. If you're making a small change (typo, phrasing) don't worry about filing an issue first. -> Para grandes correções, crie e teste a documentação antes de enviar o PR para ter certeza de que não introduziu acidentalmente nenhum problema de layout ou formatação. +> For large fixes, please build and test the documentation before submitting the PR to be sure you haven't accidentally introduced any layout or formatting issues. ``` -Fornece instruções sobre como criar e visualizar a documentação +Provide instructions on building and viewing documentation ``` -## Código de contribuição +## Contributing Code + +This section is used to get new contributors up and running with dependencies, development, testing, style rules, formatting rules, and other things they should know. -Esta seção é usada para colocar novos contribuidores em funcionamento com dependências, desenvolvimento, testes, regras de estilo, regras de formatação e outras coisas que eles devem saber. +If you have a label for beginner issues, talk about that here so they know where to look: -Se você tiver um rótulo para questões para iniciantes, fale sobre isso aqui para que eles saibam onde procurar: +> Unsure where to begin contributing to Atom? You can start by looking through these beginner and help-wanted issues: Beginner issues - issues which should only require a few lines of code, and a test or two. Help wanted issues - issues which should be a bit more involved than beginner issues. -> Não sabe por onde começar a contribuir para o Atom? Você pode começar analisando estes problemas para iniciantes e para quem precisa de ajuda: Problemas para iniciantes - problemas que devem exigir apenas algumas linhas de código e um ou dois testes. Questões procuradas por ajuda - questões que deveriam ser um pouco mais complicadas do que questões para iniciantes. +Working on your first open source project or pull request? Here are some helpful tutorials: -Está trabalhando em seu primeiro projeto de código aberto ou pull request? Aqui estão alguns tutoriais úteis: +* [How to Contribute to an Open Source Project on GitHub][2] +* [Make a Pull Request][3] +* [First Timers Only][4] -* [Como contribuir para um projeto de código aberto no GitHub][2] -* [Faça uma solicitação pull][3] -* [Somente para iniciantes] [4] -### Começando +### Getting Started -Instale estas dependências: +Install these dependencies: ``` -com alguns exemplos +with some examples ``` -Forneça algumas instruções para o seu fluxo de trabalho (por exemplo, bifurcar o repositório) +Provide some instructions for your work flow (e.g. fork the repository) -> Você precisará bifurcar o repositório principal para trabalhar em suas alterações. Basta navegar até nossa página GitHub e clicar no botão "Fork" na parte superior. Depois de bifurcar o repositório, você pode clonar seu novo repositório e começar a fazer edições. +> You will need to fork the main repository to work on your changes. Simply navigate to our GitHub page and click the "Fork" button at the top. Once you've forked the repository, you can clone your new repository and start making edits. -> No git é melhor isolar cada tópico ou recurso em uma “ramificação de tópico”. Embora os commits individuais permitam que você controle sobre quão pequenas alterações individuais são feitas no código, as ramificações são uma ótima maneira de agrupar um conjunto de commits, todos relacionados a um recurso, ou de isolar diferentes esforços quando você estiver trabalhando em vários tópicos no mesmo momento. mesmo tempo. +> In git it is best to isolate each topic or feature into a “topic branch”. While individual commits allow you control over how small individual changes are made to the code, branches are a great way to group a set of commits all related to one feature together, or to isolate different efforts when you might be working on multiple topics at the same time. -> Embora seja necessária alguma experiência para ter a noção correta sobre como dividir commits, uma ramificação de tópico deve ter escopo limitado a um único problema +> While it takes some experience to get the right feel about how to break up commits, a topic branch should be limited in scope to a single issue ``` -# Faça check-out do branch master - você deseja que seu novo branch venha do master -mestre de checkout git +# Checkout the master branch - you want your new branch to come from master +git checkout master -# Crie um novo branch chamado newfeature (dê ao seu branch um nome simples e informativo) -novidade do branch git +# Create a new branch named newfeature (give your branch its own simple informative name) +git branch newfeature -# Mude para sua nova filial -git checkout novidade +# Switch to your new branch +git checkout newfeature ``` -Para obter mais informações sobre os processos de fork e pull-request do GitHub, [consulte este guia útil][5]. +For more information on the GitHub fork and pull-request processes, [please see this helpful guide][5]. -### Encontrando um problema +### Finding an Issue -A lista de solicitações de recursos e bugs pendentes pode ser encontrada em nosso [rastreador de problemas do GitHub] [6]. Escolha um problema não atribuído que você acha que pode realizar e adicione um comentário informando que está tentando fazê-lo. +The list of outstanding feature requests and bugs can be found on our on our [GitHub issue tracker][6]. Pick an unassigned issue that you think you can accomplish and add a comment that you are attempting to do it. -Forneça notas sobre diferentes tipos de questões ou rótulos +Provide notes on different kinds of issues or labels -> Problemas rotulados como 'iniciais' são considerados bons frutos ao alcance dos recém-chegados ao projeto -> Problemas rotulados como 'procura-se ajuda' podem ser mais difíceis do que 'iniciais' e podem incluir o desenvolvimento de novos recursos -> Problemas rotulados como `doc` só devem tocar no conteúdo da pasta `docs`. +> `starter` labeled issues are deemed to be good low-hanging fruit for newcomers to the project +> `help-wanted` labeled issues may be more difficult than `starter` and may include new feature development +> `doc` labeled issues must only touch content in the `docs` folder. -### Processo de Desenvolvimento +### Development Process -Qual é o seu processo de desenvolvimento? +What is your development process? -> Este projeto segue o modelo ramificado de desenvolvimento de produto [git flow](http://nvie.com/posts/a-successful-git-branching-model/). +> This project follows the [git flow](http://nvie.com/posts/a-successful-git-branching-model/) branching model of product development. -Fale sobre ramos nos quais as pessoas deveriam trabalhar. Especificamente, onde está o ponto de partida? `mestre`, `desenvolvimento`, etc. +Talk about branches people should work on. Specifically, where is the starting point? `master`, `development`, etc. -> Você deve usar o branch master para a versão mais estável; revise as [notas de versão](https://github.com/openopps/openopps-platform/releases) regularmente. Fazemos lançamentos a cada uma ou duas semanas e enviamos notas. Se você quiser se manter atualizado com as últimas mudanças, trabalhamos no branch `dev`. Se você estiver usando dev, fique atento aos commits e/ou participe do nosso stand-up diário. +> You should be using the master branch for the most stable release; please review [release notes](https://github.com/openopps/openopps-platform/releases) regularly. We do releases every week or two and send out notes. If you want to keep up with the latest changes, we work in the `dev` branch. If you are using dev, keep an eagle-eye on commits and/or join our daily stand-up. -### Construindo o Projeto +### Building the Project -Em quais filiais o trabalho deve ser iniciado? +What branches should be work be started off of? -Inclua instruções sobre como construir o projeto. +Include instructions on how to build the project. ``` -com alguns exemplos +with some examples ``` -Forneça instruções sobre como adicionar um novo arquivo/módulo à compilação +Provide instructions on adding a new file/module to the build ``` -com alguns exemplos +with some examples ``` -Mantenha seus testes o mais simples possível. +Keep your tests as simple as possible. -### Teste +### Testing -Se você adicionar código, precisará adicionar testes! Aprendemos da maneira mais difícil que código sem testes não é confiável. Se sua solicitação pull reduzir nossa cobertura de teste porque faltam testes, ela será rejeitada. +If you add code you need to add tests! We’ve learned the hard way that code without tests is undependable. If your pull request reduces our test coverage because it lacks tests then it will be rejected. -Forneça instruções para adicionar novos testes. Forneça instruções para executar testes. +Provide instructions for adding new tests. Provide instructions for running tests. ``` -com exemplos +with examples ``` -### Diretrizes de estilo +### Style Guidelines -Se o seu código tiver diretrizes de estilo, adicione-as aqui ou forneça links para documentos relevantes. Se você tiver um verificador automatizado, forneça instruções sobre como executá-lo. +If your code has any style guidelines, add them here or provide links to relevant documents. If you have an automated checker, make sure to provide instructions on how to run it. -### Formatação de código +### Code Formatting -Se o seu código tiver diretrizes de formatação que não sejam abordadas nas diretrizes de estilo acima, adicione-as aqui. +If your code has any formatting guidelines that aren't covered in the style guidelines above, add them here. -Se você estiver usando uma ferramenta de formatação automática como clang-format +If you're using an auto-formatting tool like clang-format ``` -Forneça instruções para executar a ferramenta de formatação +Provide instructions for running the formatting tool ``` -### Limpeza de espaço em branco - -Não misture alterações de código com limpeza de espaços em branco! Se você estiver corrigindo espaços em branco, inclua essas alterações separadamente das alterações no código. Se sua solicitação estiver ilegível devido a alterações de espaços em branco, ela será rejeitada. - -> Envie limpezas de espaços em branco em uma solicitação pull separada. +### Whitespace Cleanup -### Diretrizes de commit do Git +Don’t mix code changes with whitespace cleanup! If you are fixing whitespace, include those changes separately from your code changes. If your request is unreadable due to whitespace changes, it will be rejected. -Você tem alguma diretriz para suas mensagens de commit? Inclua-os aqui. +> Please submit whitespace cleanups in a separate pull request. -> A primeira linha do log de commit deve ser tratada como um email -linha de assunto. Não deve ter mais de 50 caracteres. -O sujeito deve ser independente e não apenas fazer -referências como números de bugs relevantes. +### Git Commit Guidelines -> A segunda linha deve ficar em branco. +Do you have any guidelines for your commit messages? Include them here. -> A terceira linha inicia o corpo da mensagem de commit (um ou mais -parágrafos) descrevendo os detalhes do commit. Os parágrafos são cada -separados por uma linha em branco. Os parágrafos devem ser quebrados por palavras para não haver -mais de 76 caracteres. +> The first line of the commit log must be treated as as an email +subject line. It must be strictly no greater than 50 characters long. +The subject must stand on its own and not only make external +references such as to relevant bug numbers. -> A última parte do log de commit deve conter todos os "externos -referências", como quais problemas foram corrigidos. +> The second line must be blank. -> Para mais notas sobre mensagens de commit do git, [leia esta postagem do blog][7]. +> The third line begins the body of the commit message (one or more +paragraphs) describing the details of the commit. Paragraphs are each +separated by a blank line. Paragraphs must be word wrapped to be no +longer than 76 characters. -## Processo de solicitação pull +> The last part of the commit log should contain all "external +references", such as which issues were fixed. -Você tem alguma convenção de rotulagem? +> For further notes about git commit messages, [please read this blog post][7]. -Adicione notas para enviar seu branch: +## Pull Request Process -> Quando estiver pronto para gerar uma solicitação pull, seja para revisão preliminar ou para consideração de fusão no projeto, você deve primeiro enviar seu branch de tópico local de volta ao GitHub: - -``` -git push origem novidade -``` +Do you have any labeling conventions? -Inclua uma observação sobre o envio do PR: +Add notes for pushing your branch: -> Depois de confirmar e enviar todas as alterações para o GitHub, vá para a página do seu fork no GitHub, selecione seu branch de desenvolvimento e clique no botão pull request. Se você precisar fazer algum ajuste em sua solicitação pull, basta enviar as atualizações para sua filial. Sua solicitação pull rastreará automaticamente as alterações em seu branch de desenvolvimento e atualização. +> When you are ready to generate a pull request, either for preliminary review, or for consideration of merging into the project you must first push your local topic branch back up to GitHub: ``` -git push origem novidade +git push origin newfeature ``` -Inclua uma observação sobre o envio do PR: +Include a note about submitting the PR: -> Depois de confirmar e enviar todas as alterações para o GitHub, vá para a página do seu fork no GitHub, selecione seu branch de desenvolvimento e clique no botão pull request. Se você precisar fazer algum ajuste em sua solicitação pull, basta enviar as atualizações para sua filial. Sua solicitação pull rastreará automaticamente as alterações em seu branch de desenvolvimento e atualização. +> Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to your branch. Your pull request will automatically track the changes on your development branch and update. -1. Certifique-se de que todas as dependências de instalação ou construção sejam removidas antes do final da camada ao fazer uma - construir. -2. Atualize o README.md com detalhes das alterações na interface, incluindo novo ambiente - variáveis, portas expostas, locais de arquivos úteis e parâmetros de contêiner. -3. Aumente os números de versão em quaisquer arquivos de exemplo e no README.md para a nova versão que este - Pull Request representaria. O esquema de versionamento que usamos é [SemVer](http://semver.org/). -4. Você pode mesclar a solicitação pull assim que tiver a aprovação de dois outros desenvolvedores ou se desejar - não tem permissão para fazer isso, você pode solicitar que o segundo revisor mescle-o para você. +1. Ensure any install or build dependencies are removed before the end of the layer when doing a + build. +2. Update the README.md with details of changes to the interface, this includes new environment + variables, exposed ports, useful file locations and container parameters. +3. Increase the version numbers in any examples files and the README.md to the new version that this + Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/). +4. You may merge the Pull Request in once you have the sign-off of two other developers, or if you + do not have permission to do that, you may request the second reviewer to merge it for you. -### Processo de revisão +### Review Process -Quem analisa isso? Quem precisa assinar antes de ser aceito? Quando um colaborador deve esperar receber notícias suas? Como os contribuidores podem obter acesso de commit, se é que conseguem? +Who reviews it? Who needs to sign off before it’s accepted? When should a contributor expect to hear from you? How can contributors get commit access, if at all? -> A equipe principal analisa as solicitações pull regularmente em uma reunião de triagem semanal que realizamos em um Hangout público do Google. O hangout é anunciado nas atualizações de status semanais enviadas para a lista puppet-dev. As notas são postadas no repositório de triagem da comunidade da Puppet Community e incluem um link para uma gravação do hangout no YouTube. Após o feedback ser dado, esperamos respostas dentro de duas semanas. Após duas semanas, poderemos encerrar a solicitação pull se ela não mostrar nenhuma atividade. +> The core team looks at Pull Requests on a regular basis in a weekly triage meeting that we hold in a public Google Hangout. The hangout is announced in the weekly status updates that are sent to the puppet-dev list. Notes are posted to the Puppet Community community-triage repo and include a link to a YouTube recording of the hangout. After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity. -> Exceto para correções críticas, urgentes ou muito pequenas, tentamos deixar solicitações pull abertas durante a maior parte do dia ou durante a noite se algo chegar no final do dia, para que várias pessoas tenham a chance de revisar/comentar. Qualquer pessoa que analisar uma solicitação pull deve deixar uma nota para que outras pessoas saibam que alguém a analisou. Para commits maiores, gostamos de receber o +1 de outra pessoa da equipe principal e/ou de outro(s) colaborador(es). Observe que se você revisou o código ou testou localmente - um +1 por si só normalmente será interpretado como se você achasse que é uma boa ideia, mas não revisou em detalhes. +> Except for critical, urgent or very small fixes, we try to leave pull requests open for most of the day or overnight if something comes in late in the day, so that multiple people have the chance to review/comment. Anyone who reviews a pull request should leave a note to let others know that someone has looked at it. For larger commits, we like to have a +1 from someone else on the core team and/or from other contributor(s). Please note if you reviewed the code or tested locally -- a +1 by itself will typically be interpreted as your thinking its a good idea, but not having reviewed in detail. -Talvez também forneça as etapas que sua equipe usará para verificar um PR. Ou discuta as etapas executadas em seu servidor de CI, se você tiver um. Isso ajudará os desenvolvedores a entender como investigar falhas ou testar o processo por conta própria. +Perhaps also provide the steps your team will use for checking a PR. Or discuss the steps run on your CI server if you have one. This will help developers understand how to investigate any failures or test the process on their own. -### Abordando Feedback +### Addressing Feedback -Depois que um PR for enviado, suas alterações serão analisadas e comentários construtivos poderão ser fornecidos. O feedback não pretende ser um ataque, mas sim ajudar a garantir que o código da mais alta qualidade chegue ao nosso projeto. As alterações serão aprovadas assim que o feedback necessário for abordado. +Once a PR has been submitted, your changes will be reviewed and constructive feedback may be provided. Feedback isn't meant as an attack, but to help make sure the highest-quality code makes it into our project. Changes will be approved once required feedback has been addressed. -Se um mantenedor pede para você “rebasear” seu PR, ele está dizendo que muito código mudou e que você precisa atualizar seu fork para que seja mais fácil mesclar. +If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your fork so it's easier to merge. -Para atualizar seu repositório bifurcado, siga estas etapas: +To update your forked repository, follow these steps: ``` -# Busque o upstream master e mescle com o branch master do seu repositório -git buscar upstream -mestre de checkout git -git mesclar upstream/mestre - -# Se houver novos commits, rebase seu branch de desenvolvimento -git checkout novidade -mestre de rebase git +# Fetch upstream master and merge with your repo's master branch +git fetch upstream +git checkout master +git merge upstream/master + +# If there were any new commits, rebase your development branch +git checkout newfeature +git rebase master ``` -Se muito código foi alterado para que o git aplique automaticamente as alterações de suas ramificações ao novo mestre, você mesmo precisará resolver manualmente os conflitos de mesclagem. +If too much code has changed for git to automatically apply your branches changes to the new master, you will need to manually resolve the merge conflicts yourself. -Assim que seu novo branch não tiver conflitos e funcionar corretamente, você poderá substituir seu branch antigo usando este comando: +Once your new branch has no conflicts and works correctly, you can override your old branch using this command: ``` git push -f ``` -Observe que isso substituirá o branch antigo no servidor, portanto, primeiro certifique-se de estar satisfeito com suas alterações! +Note that this will overwrite the old branch on the server, so make sure you are happy with your changes first! -## Comunidade +## Community -Você tem uma lista de discussão, grupo do Google, canal Slack, canal IRC? Link para eles aqui. +Do you have a mailing list, Google group, slack channel, IRC channel? Link to them here. -> Qualquer pessoa que contribua ativamente ou use o OpenOpps deve participar da nossa [lista de e-mails](https://groups.google.com/forum/#!forum/openopps-platform). -Também temos uma equipe de bate-papo pública no Slack. Se você estiver interessado em acompanhar o processo de desenvolvimento ou tiver dúvidas, sinta-se à vontade para [juntar-se a nós](https://openopps.slack.com). +> Anyone actively contributing to or using OpenOpps should join our [Mailing List](https://groups.google.com/forum/#!forum/openopps-platform). +We also have a public Slack chat team. If you're interested in following along with the development process or have questions, feel free to [join us](https://openopps.slack.com). -Incluir outras notas sobre como as pessoas podem contribuir +Include Other Notes on how people can contribute -* Você pode nos ajudar a responder perguntas de nossos usuários aqui: -* Você pode ajudar a construir e projetar nosso site aqui: -* Você pode ajudar a escrever postagens no blog sobre o projeto: -* Você pode ajudar com boletins informativos e comunicações internas: +* You can help us answer questions our users have here: +* You can help build and design our website here: +* You can help write blog posts about the project by: +* You can help with newsletters and internal communications by: -* Crie um exemplo do projeto no mundo real construindo algo ou -mostrando o que outros construíram. -* Escreva sobre projetos de outras pessoas com base neste projeto. Mostrar como -é usado na vida diária. Faça capturas de tela e faça vídeos! +* Create an example of the project in real world by building something or +showing what others have built. +* Write about other people’s projects based on this project. Show how +it’s used in daily life. Take screenshots and make videos! [0]: CODE_OF_CONDUCT.md [1]: style_guidelines.md [2]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github [3]: http://makeapullrequest.com/ -[4]: http://www.firsttimesonly.com +[4]: http://www.firsttimersonly.com [5]: https://gist.github.com/Chaser324/ce0505fbed06b947d962 -[6]: link/para/seu/projeto/problema/rastreador +[6]: link/to/your/project/issue/tracker [7]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html \ No newline at end of file diff --git a/docs/PULL_REQUEST_TEMPLATE.md b/docs/PULL_REQUEST_TEMPLATE.md index e08d873..836f9c7 100644 --- a/docs/PULL_REQUEST_TEMPLATE.md +++ b/docs/PULL_REQUEST_TEMPLATE.md @@ -1,43 +1,41 @@ -# Modelo de solicitação pull +# Pull Request Template -## Descrição +## Description -Inclua um resumo da alteração e qual problema foi corrigido. Inclua também motivação e contexto relevantes. Liste todas as dependências necessárias para essa alteração. +Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. -Correções # (problema) +Fixes # (issue) -## Tipo de mudança +## Type of change -Exclua as opções que não são relevantes. +Please delete options that are not relevant. -- [] Correção de bug (alteração ininterrupta que corrige um problema) -- [] Novo recurso (alteração ininterrupta que adiciona funcionalidade) -- [] Alteração significativa (correção ou recurso que faria com que a funcionalidade existente não funcionasse conforme o esperado) -- [ ] Esta alteração requer uma atualização da documentação +- [ ] Bug fix (non-breaking change which fixes an issue) +- [ ] New feature (non-breaking change which adds functionality) +- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) +- [ ] This change requires a documentation update -## Como isso foi testado? +## How Has This Been Tested? -Descreva os testes que você executou para verificar suas alterações. Forneça instruções para que possamos reproduzir. Liste também quaisquer detalhes relevantes para sua configuração de teste +Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration -- [ ] Teste A -- [ ] Teste B -- [ ] Teste C +- [ ] Test A +- [ ] Test B -**Configuração de teste**: - -* Versão do Firmware: -* Ferragens: -* Conjunto de ferramentas: +**Test Configuration**: +* Firmware version: +* Hardware: +* Toolchain: * SDK: -## Lista de verificação: - -- [ ] Meu código segue as diretrizes de estilo deste projeto -- [ ] Realizei uma auto-revisão do meu próprio código -- [ ] Comentei meu código, principalmente em áreas difíceis de entender -- [ ] Fiz alterações correspondentes na documentação -- [ ] Minhas alterações não geram novos avisos -- [ ] Adicionei testes que provam que minha correção é eficaz ou que meu recurso funciona -- [ ] Testes de unidade novos e existentes passam localmente com minhas alterações -- [ ] Quaisquer alterações dependentes foram mescladas e publicadas em módulos downstream -- [ ] Verifiquei meu código e corrigi quaisquer erros ortográficos \ No newline at end of file +## Checklist: + +- [ ] My code follows the style guidelines of this project +- [ ] I have performed a self-review of my own code +- [ ] I have commented my code, particularly in hard-to-understand areas +- [ ] I have made corresponding changes to the documentation +- [ ] My changes generate no new warnings +- [ ] I have added tests that prove my fix is effective or that my feature works +- [ ] New and existing unit tests pass locally with my changes +- [ ] Any dependent changes have been merged and published in downstream modules +- [ ] I have checked my code and corrected any misspellings From e715a71f5555726c4339a5756ee3c7d19f42ad62 Mon Sep 17 00:00:00 2001 From: Cezar Silva Date: Fri, 14 Feb 2025 22:29:26 -0300 Subject: [PATCH 02/17] feat: merge main -> develop --- .idea/workspace.xml | 120 ++++++++++++++++++++++++++++++++++++++++++++ welcome-to-docker | 1 + 2 files changed, 121 insertions(+) create mode 100644 .idea/workspace.xml create mode 160000 welcome-to-docker diff --git a/.idea/workspace.xml b/.idea/workspace.xml new file mode 100644 index 0000000..8049106 --- /dev/null +++ b/.idea/workspace.xml @@ -0,0 +1,120 @@ + + + + + + + + + + + + + { + "lastFilter": { + "state": "OPEN", + "assignee": "CezarFelipe" + } +} + { + "selectedUrlAndAccountId": { + "url": "https://github.com/brazona/conf.git", + "accountId": "e125a2c5-bc0b-4812-972d-1433170fd0bc" + } +} + + + + { + "associatedIndex": 2 +} + + + + + + + + + + + + + + + + + + + + + + + + + 1730296255091 + + + + + + \ No newline at end of file diff --git a/welcome-to-docker b/welcome-to-docker new file mode 160000 index 0000000..373269c --- /dev/null +++ b/welcome-to-docker @@ -0,0 +1 @@ +Subproject commit 373269cd29c49cd2fb93fc2274e31d56651d1379 From df5329866dd4f584b905d76c8c0f3349878b1702 Mon Sep 17 00:00:00 2001 From: Cezar Silva Date: Fri, 14 Feb 2025 23:01:26 -0300 Subject: [PATCH 03/17] feat: alterado nomeclaturo aplicacao conf --- .github/workflows/build.yml | 2 +- .github/workflows/config-server-service.yml | 22 ++++++++++----------- .github/workflows/exemplo/build.yml | 2 +- .idea/workspace.xml | 2 +- app/service/deployment.yml | 4 ++-- app/service/pom.xml | 4 ++-- 6 files changed, 18 insertions(+), 18 deletions(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index fb0fb92..feeae65 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -17,7 +17,7 @@ env: REGISTRY_DOCKER: ghcr.io REPOSITORY_DOCKER: ${{ github.repository }} VERSION_TYPE: '' - APP: config-server-service + APP: conf jobs: info-environment: diff --git a/.github/workflows/config-server-service.yml b/.github/workflows/config-server-service.yml index 2adc219..28e1943 100644 --- a/.github/workflows/config-server-service.yml +++ b/.github/workflows/config-server-service.yml @@ -9,12 +9,12 @@ name: Config Server Service Pipeline on: push: paths: - - 'app/profile/config-server-service/**' + - 'app/profile/conf/**' branches: - 'main' pull_request: paths: - - 'app/profile/config-server-service/**' + - 'app/profile/conf/**' branches: - 'main' - 'develop' @@ -22,7 +22,7 @@ on: - 'release/**' workflow_dispatch: env: - GITHUB_REPOSITORY: brazona/config-server-service + GITHUB_REPOSITORY: brazona/conf jobs: #identifica as variaveis identify: @@ -40,7 +40,7 @@ jobs: permissions: write-all needs: [identify] env: - FILE_PATH: 'app/profile/config-server-service/dsv/.env' + FILE_PATH: 'app/profile/conf/dsv/.env' outputs: envfile: ${{ steps.envfile_search.outputs.envfile }} steps: @@ -50,15 +50,15 @@ jobs: - name: File Env Homologation if: contains(needs.identify.outputs.github_env_file_field, 'HOMOLOGATION_ENV') run: | - echo "FILE_PATH=app/profile/config-server-service/hmg/.env" >> $GITHUB_ENV + echo "FILE_PATH=app/profile/conf/hmg/.env" >> $GITHUB_ENV - name: File Env Staging if: contains(needs.identify.outputs.github_env_file_field, 'STAGING_ENV') run: | - echo "FILE_PATH=app/profile/config-server-service/stg/.env" >> $GITHUB_ENV + echo "FILE_PATH=app/profile/conf/stg/.env" >> $GITHUB_ENV - name: File Env Production if: contains(needs.identify.outputs.github_env_file_field, 'PRODUCTION_ENV') run: | - echo "FILE_PATH=app/profile/config-server-service/prd/.env" >> $GITHUB_ENV + echo "FILE_PATH=app/profile/conf/prd/.env" >> $GITHUB_ENV - name: Out Envfile path id: envfile_search run: echo "envfile=${{ env.FILE_PATH }}" >> $GITHUB_OUTPUT @@ -116,7 +116,7 @@ jobs: permissions: write-all needs: [identify] env: - FILE_PATH: 'app/profile/config-server-service/dsv/configmap.yml' + FILE_PATH: 'app/profile/conf/dsv/configmap.yml' outputs: configmap: ${{ steps.configmap_search.outputs.configmap }} steps: @@ -126,15 +126,15 @@ jobs: - name: File Env Homologation if: contains(needs.identify.outputs.github_env_file_field, 'HOMOLOGATION_ENV') run: | - echo "FILE_PATH=app/profile/config-server-service/hmg/configmap.yml" >> $GITHUB_ENV + echo "FILE_PATH=app/profile/conf/hmg/configmap.yml" >> $GITHUB_ENV - name: File Env Staging if: contains(needs.identify.outputs.github_env_file_field, 'STAGING_ENV') run: | - echo "FILE_PATH=app/profile/config-server-service/stg/configmap.yml" >> $GITHUB_ENV + echo "FILE_PATH=app/profile/conf/stg/configmap.yml" >> $GITHUB_ENV - name: File Env Production if: contains(needs.identify.outputs.github_env_file_field, 'PRODUCTION_ENV') run: | - echo "FILE_PATH=app/profile/config-server-service/prd/configmap.yml" >> $GITHUB_ENV + echo "FILE_PATH=app/profile/conf/prd/configmap.yml" >> $GITHUB_ENV - name: Out Configmap path id: configmap_search run: echo "configmap=${{ env.FILE_PATH }}" >> $GITHUB_OUTPUT diff --git a/.github/workflows/exemplo/build.yml b/.github/workflows/exemplo/build.yml index 683f1ca..05409d4 100644 --- a/.github/workflows/exemplo/build.yml +++ b/.github/workflows/exemplo/build.yml @@ -18,7 +18,7 @@ env: REGISTRY_DOCKER: ghcr.io REPOSITORY_DOCKER: ${{ github.repository }} VERSION_TYPE: '' - APP: config-server-service + APP: conf jobs: info-environment: diff --git a/.idea/workspace.xml b/.idea/workspace.xml index 8049106..3c80417 100644 --- a/.idea/workspace.xml +++ b/.idea/workspace.xml @@ -80,7 +80,7 @@