Closed felipesabino closed 7 years ago
Node Braindump:
Warnings
.env
.nvmrc
docker-compose.yml
tasks/options/env.coffee (grunt config)
node_modules
npm-shrinkwrap.json
package.json
yarn.lock
Procfile
Look for Amazon Secret keys: ?<![A-Za-z0-9/+=])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=]
Is there any way to warn if one file changed and some other file related to the first didn't?
Such as: Podfile
changed and no Podfile.lock
was commited
Could implement this regex pattern for hungarian notation :
Some stuff taken from the latest 2 CRs on iOS projects
Info.plist
contains ATS ExceptionsInfo.plist
contains Landscape modePodfile
has pods should not using fixed versionsPodfile
has pods being loaded from external git repos (specially or only if they are not indigotech
)TODO
or print("")
were addedfatalError
is added, most likely it should use the error handlers or throw exceptionsNot sure how we would check for it, but it would be nice to have
Info.plist
has hardcoded data (like facebook IDs of bundle identifiers)cc @filipemp @ghashi @marcelorisse
Stuff taken from Node project CR
npm install -g
is foundconsole.log
(or console.*
?) was addedpackage.json
file was modified but there were no changes onyarn.lock
or shrinkwrap
Not sure how we would check for it, but it would be nice to have
.travis.yml
, .nvmrc
, package.json
and README (or just warn if node version has change just in one of these locations)cc @askmon @fabiothiroki @marcelorisse @adrianshiokawa
@felipesabino
console.error
be acceptable? This way we can debug using papertrail or another similar toolpackages.json
every package should have its version fixed (do not use ^
or ~
), or explicitly set the major and minor versions (ie.: 1.2.x
)@fabiothiroki
Shouldn't at least console.error be acceptable?
👍
At packages.json every package should have its version fixed, or at least the tilde (~) so we don't experience incompatibility issues
👍
@felipesabino @fabiothiroki
At packages.json every package should have its version fixed, or at least the tilde (~) so we don't experience incompatibility issues
Ok for development stages. But once we go live, I feel we should restrict to fixed versions only.
.gitignore
, Gemfile
, Gemfile.lock
, .travis.yml
>>>
Strings to make sure rebase was successfulGemfile
was modified and Gemfile.lock
was notyarn.lock
, docker-compose.yml
, Procfile
, npm-shrinkwrap.json
, node_modules
, env.coffee
npm install -g
is used.env
or .nvmrc
files are modifiedconsole.log
is added package.json
was modified and yarn.lock
or shrinkwrap
was notCakefile
, settings.yml.erb
, Fastfile
Podfile
was modified and Podfile.lock
was notTODO
is addedprint(“”)
is addedfatalError
is added.gradle
or Manifest.xml
files are modified@eiditakahashi I have just one suggestion. One of the node checks is:
At packages.json every package should have its version fixed (do not use ^ or ~), or explicitly set the major and minor versions (ie.: 1.2.x)
I believe that we should enforce all 3 digits to be set, not just major and minor. Specially since we are checking for ~
which is analogous to 1.2.x
.
iOS: (problema visto na aprovação da Raia iOS)
Barba:
FYI, ontem vimos que o app crashava caso o
ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES
estivesse setado praNO
então add as strings das permissões na plist. O que passou batido, pelo menos para mim, é que o problema também era a inclusão de todos aqueles pacotes binários em uma versão que a Apple não curtiu. Logo, ontem no fim do dia tornamos a receber uma mensagem da Apple, dessa vez somente com o texto referente aos tais binários. Hoje, depois de pesquisar pelo nosso querido stackoverflow cheguei nisso: https://github.com/indigotech/br-raia-app-ios/pull/1460 Estamos testanto :pray:
Inspirado por esse problema e dado que iremos buscar por palavras proibidas, talvez seja fácil de verificar se no arquivo do Cakefile exista tal config. Além disso, vcs tbm saibam de configurações indesejadas que poderíamos testar tanto no Android e iOS. Eu conversei com o Feijão e ele disse que tal problema não é recorrente e não precisaria ser corrigido assim ou pelo menos não agora (não é urgente). Acho que a solução é barata e vou deixar registrado aqui para dar visibilidade a todos e quem sabe algo a ser atacado no futuro
I am closing this in favor of 1.0.0 release and the remaining items were added to #8, #9, #10, #11 and #12
Please create new issues (or even PR 🎉 ) if you need extra checks to be added
What are most common problems we can automate and test for using Danger?
(More info on what is this repo, what does Taqtile danger implementation is and to add your suggestion on the implementation, go to issue #2)
General
.gitignore
>>>
strings to make sure rebase was successful (inspired by this commit to develop)Platform Specific
Node.js
iOS
Android
Windows
😢 As we do not have any CI for Windows yet, everything related to Windows will be considered only for future releases
Web