Feda /dev/ - No Javascript allowed | Página 1978

aren-pulid0 #59311 26 Sep

#59304 lint != format

pero vamos a ver, si es lo mismo que si lo hace un compañero, dime que exactamente que diferencia hay que haya 1 commit a que haya 2 (uno con el del compañero y otro en menos de 10 segundos del formateo). Ojo, repito, en una rama que tiene abierta una pull request. ¿Que diferencia hay? ¿Que más da traerte 1 commit que 2 commits?

En todo caso molesta al que no tiene el prettier bien configurado, hace push y la ci le arregla el formateo, ahí tendrá que hacer pull de los cambios cuando quiera hacer un nuevo push usando el git push origin head, si lo tienes bien configurado tú, no tienes ningún problema en ningún momento

Es más, te reto a que lo pruebes, no te llevará mas de 20 minutos

1 respuesta

Dr_Manhattan #59312 26 Sep 4life

#59308 opina de deportes sin tener ni idea, igual que aquí, pero allí hacen algo para solucionarlo

1 respuesta

Fyn4r #59313 26 Sep Inocente

#59312 A mi me gustaban sus trolleos en el hilo del xokas

JackWhy #59314 26 Sep

#59311 Madre mía, un commit solo para un formateo...

1 respuesta

aren-pulid0 #59315 26 Sep

#59314 que problema hay, en una pull request que luego vas a hacer squash and merge?

HeXaN #59316 26 Sep

Coño, que todavía seguís con el tema.

1 respuesta

ManKorR #59317 26 Sep :psyduck:

#59316 tu que harías?

2 respuestas

Fyn4r #59318 26 Sep Inocente

#59317 ya te respondo yo: plegar el pc e ir a entrenar que ya son las 6, luego la raid del wow

5

HeXaN #59319 26 Sep

#59317 Nosotros tenemos Prettier en local (on save), en hook y luego en CI. Si es mejor o peor me la pela, no es mi trabajo.

1 respuesta

aren-pulid0 #59320 26 Sep

#59319 exactamente, y si te saltas el local y el hook, la ci te lo corrige, mejor a que solo te haga block.

1 1 respuesta

Kaledros #59321 26 Sep

Yo sólo digo que si tienes miedo de que un linter te comitee cosas a ciegas al arrancar la CI la solución es fácil: pásalo antes en local y no tendrá nada que tocar.

Otro día hablamos de que si tienes incertidumbre acerca del comportamiento de una herramienta igual deberías darle una vuelta a lo que estás haciendo.

2

Don_Correcto #59322 26 Sep Paper hands

Como diría el mejor ingeniero de software de todos los tiempos:

Cuánta sobreingeniería - desu

W0rd #59323 26 Sep

#59320 O que no pase la build y te oblige a ti a modificarlo antes de mergear la PR.

Una pipeline no deberia modificar el repositorio, mas que nada por problemas de sincronizacion como ya han explicado. No es una especie de cajon donde todo lo que mergeas se corrige solo al cabo de un tiempo.

Ademas que a la hora de hacer una review a una PR ayuda a que el codigo este formateado, estas herramientas no son solo para el que lee el codigo fuente de vez en cuando.

1 respuesta

JuAn4k4 #59324 26 Sep

#59301 En Inditex no pagan mal, a mi me dijeron en un puesto tech lead que 120-125K€ eran asumibles, no llegue a oferta porque cuando me mandaron deberes les dije que no, así que no se como de cierto era.

1 respuesta

Kaledros #59325 26 Sep

#59324JuAn4k4:
cuando me mandaron deberes

Es acojonante, eh. Lo de mandar deberes para absolutamente cualquier puesto, por inercia y sin pensarlo dos veces.

aren-pulid0 #59326 26 Sep

#59323 otra vez, en una rama con una pull request abierta, en la propia rama se hace el commit, lo probáis y a ver si dejáis de decir tonterías de sincronización y conflictos.

1 respuesta

isvidal #59327 27 Sep

No

4

aren-pulid0 #59328 27 Sep

Feda /dev/ - Brain 404

Lo de negar algo sin si quiera pensarlo, ya ni probarlo (que es lo que deberíais hacer antes de hablar), es acojonante, lo de los conflictos y desincronizaciones es que vamos jajajajaaja si a poco que lo pienses 1 minuto ya te das cuenta que no pasa.

Pero bueno doy la batalla por perdida

2 respuestas

newfag #59329 27 Sep

#59328 No es brain 404 es ego 200

HeXaN #59330 27 Sep

#59326 ¿Me estás diciendo que podemos tener diferentes pipelines dependiendo de si la rama es de PR a si es de develop/master/comosellame? Imposible.

1 respuesta

aren-pulid0 #59331 27 Sep

#59330 magia negra

isvidal #59332 27 Sep

#59328 Gracias a dios que en las empresas serias no existen dev-ops y somos los propios equipos de ingenieros los que mantenemos nuestras CI

La realidad es que lo he probado siendo mas novato, y sorpresa, con el tiempo te das cuenta de todas las razones por las que esta mal.

4 respuestas

Zoko #59333 27 Sep

#59332isvidal:
en las empresas serias no existen dev-ops

4

Dr_Manhattan #59334 27 Sep 4life

#59332isvidal:
equipos de ingenieros

1

pantocreitor #59335 27 Sep

Buenos días a todos, incluso a los agnósticos de los pre-hooks commits

EDIT: algún afectado por aquí???? https://health.aws.amazon.com/health/status

JuAn4k4 #59336 27 Sep

#59332 Nosotros tenemos algún caso de uso, el CI crea el PR se lo auto aprueba y lo mergea. Sobre todo para hacer deploys a dev/stage/prod con gitops.
También tenemos alguno que otro para hacer releases y bump versions/tags.
Y alguno que otro de auto generación de clientes http que el repo lo administra enteramente un CI bot.

1 1 respuesta

aren-pulid0 #59337 27 Sep

#59332isvidal:
La realidad es que lo he probado siendo mas novato, y sorpresa, con el tiempo te das cuenta de todas las razones por las que esta mal.

Si hasta hace 2 días como quién dice no sabías lo que eran las Github Actions ni como funcionaban. Es más, te pregunto, ¿exactamente que problemas y/o que está mal? Descríbeme el caso de uso, cuando ocurre el problema y cual es la consecuencia.

A ver si me entero y mejoro, si tu alternativa es mejor yo me callo y aprendo.

#59332isvidal:
Gracias a dios que en las empresas serias no existen dev-ops y somos los propios equipos de ingenieros los que mantenemos nuestras CI

Y esto bastante temerario decirlo eh jajaja, casi todas las empresas tienen un equipo de Platform/SRE/DevOps

3 respuestas

Fyn4r #59338 27 Sep Inocente

#59337

A ver si me entero y mejoro, si tu alternativa es mejor yo me callo y aprendo.

Ahora mismo me caes un poco mejor

wdaoajw #59339 27 Sep

#59337 dime qué no tienes ni idea de plataforma sin decirme que que no tienes ni idea de plataforma.

Cuando un dev dice esas cosas queda claro que no son conscientes ni de cómo se despliega, ni de cómo se monitoriza, ni de cómo se asegura un entorno y mucho menos a una escala medio-grande.

Que desplegar 3 apps para la startup pepe es fácil, imagina desplegar 10XXX apps cada una con sus actions customs, su observability, sus permisos, etc etc

2 respuestas

Wei-Yu #59340 27 Sep

#59337aren-pulid0:
Es más, te pregunto, ¿exactamente que problemas y/o que está mal?

Hay que partir de la base de que no es una dicotomía entre "la pipeline cambia el código fuente" y "el mundo está en llamas y no se puede trabajar" si no, cambiar el código fuente en la pipeline vs tener un check con el dry run para validar que no habrá merge conflicts por cambios de estilo.

"Beneficios" de hacerlo mutando el código desde la pipeline? El smell cultural de que sabes mejor que otros compañeros lo que esos compañeros necesitan.

Problemas? Cambiar el código fuente de forma automática parece que no suena suficiente absurdo y dejando de lado casos obvios en los que el formato cambia el significado del código (hola python), tienes muchos corner cases en los que no sabes qué ocurrirá. Hace un tiempo tuve un probelma con prettier inyectando leading & trailing whitespaces en el código. Además de eso, los raw literals (r"") suelen ser sensibles a espaciados, saltos de línea, tabs y otras muchas cosas, lo que te expone a reventar código en runtime.

Esos problemas son hechos, los aceptas o los minificas (un whitespace o un salto de línea no es nada hombre). Dejando los hechos de lado, yo, a título personal creo que la pipeline debería ser una caja negra stateless. Añadir algo así es añadir carga cognitiva y de aquí a un año no sabes cómo van a evolucionar los productos, procesos y equipos. Y obviamente de aquí a un año nadie se va a acordar de que algo así está metido.

Ya lo dijeron más atrás, pero crear una PR para que una persona la revise? Bien. Cambiar el código solo? Mal.

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales