Reprise du message précédent :

Fait bien regarder les benchs mais cette plateforme est pas mal  
 
J'ai acheté mon 6900K y'a 4 mois (toujours en train de le monter ), mais si c'était maintenant j'aurais bien pris un Threadripper

 
Threadripper c'est magnifique mais c'est trop cher pour mon budget Mon côté geek déjà qui me fait changer de config, alors bon TR non Et puis TR en mini ITX c'est pas vraiment possible vu la taille du socket

Vu que ça parle config, j'ai actuellement 8Go de ram.
Je ne fais pas grand chose avec ma machine chez moi à part Chrome + Quake Champions.
 
La config recommandée pour Quake nécessite 16Go de ram. Vous pensez que c'est réellement utile ?

Je mange 8Go de ram rien qu'avec chrome + firefox + slack (google apps + confluence + jira ça pardonne pas   )

Je suis parti sur 64Go, pour pas être emmerdé
(J'ai de gros dataset)

J'ai jamais eu besoin de 16Go de RAM chez moi.  
Pour ça que j'ai 32.

C'est surtout la corrélation ram, nombre de FPS qui m'intrigue (sachant que le jeu est sur un SSD).

On t'as déjà dit que pornhub en 4K c'était pas un dataset

 
Ta trop de fric toi Achète moi donc un Threadripper, je te dirai si ça vaut le coup

Dans le même genre un MBP avec 8Go c'est viable pour un usage pas trop intensif, ou l'upgrade à 16Go est indispensable ?

 
moi j'ai ça et je trouve qu'il rame.  
 
Mais j'ai webstorm et Fusion360 ouvert en même temps assez souvent.

C'est quoi le goulot d'étranglement du coup ? CPU ?
 
XaT

Le MBP payé avec l'argent sale de Vates en plus

 
Non pour la reconnaissance d'image j'ai 2x 1080Ti
 

c'est ma croix : je gagne extremement bien ma vie, mais je me fais chier dans ma grosse COGIP
 
remarque cette nuit j'ai fait du Python + PowerBI pour le taf, c'était assez sympa à faire

 
quitte à choisir, la nuit je préfère dormir ...  

non, de 0x90corp

 
Ta pas moyen de te mettre à temps partiel, gagner moins mais bosser sur des trucs que t'aimerai ?

 
Bon ça va alors

 
You know how they call a MacBook in France ?
They call it "LE"MacBook

j'ai récupéré une bonne partie du variable, une prime de départ, et un bon prix sur le portable
 
(le type arrivé après moi n'a pas réalisé l'objectif qui m'était assigné non plus alors qu'il a eu un an de plus)

alors que les employés de vates doivent bosser sur des vieux Dell achetés d'occasion à 150€

 
Ah non monsieur C'est faux
 
edit : ceci dit c'est pas une mauvaise idée  

Le projet sur lequel je bosse contient un Dockerfile pour faire tourner l'application et développer en local facilement.
 
Le projet est versionné et packagé (en RPM) avec Maven. L'intégration se fait avec Jenkins.
 
J'aimerais pouvoir exécuter tous les goals avant la phase "package" dans l'image Docker (j'arrive à la monter à la volé dans un pipeline Jenkins) mais que le packaging (et l'upload sur le Nexus) se fasse en dehors de cette image (ce que je n'arrive pas à faire pour le moment).
 
Pourquoi ? J'aimerais que l'image Docker ne contienne que la configuration nécessaire pour faire tourner le projet. Actuellement pour faire une release j'ai été obligé d'inclure dans le Dockerfile toute la configuration nécessaire pour faire tourner Maven et construire un RPM (je vous passe les problèmes de droits et de fichiers de configuration Maven présent sur la machine Jenkins et pas dans l'image).
 
Je n'ai pas envie de copier/coller cette partie dans les Dockerfile des prochains projets.
 
C'est possible ? J'ai du mal à trouver ce que je cherche sur le net.
 
En plus c'est pour packager du PHP (ouais, c'est loin d'être optimal).  
 
Au départ le pom.xml se résumait au numéro de version et à la configuration du plugin RPM et des repo Nexus). Toutes les steps avant le packaging (récupération des dépendances composer et npm, phase de tests phpunit, etc) était exécuté dans l'image Docker via les "sh" des pipelines Jenkins :
 

node {
   def container
 
    stage("Cleaning workspace" ) {
        deleteDir()
    }
 
    stage("Getting sources" ) {
      git branch: 'develop', credentialsId: '...', url: 'git@bitbucket.org:foo/bar.git'
    }
 
    stage("Building the Docker image" ) {
        container = docker.build('foo', '--build-arg BUILD_UID=$(id -u) --build-arg BUILD_GID=$(id -g) --build-arg BUILD_UNAME=$(whoami) .')
    }
 
    container.inside('-u jenkins:jenkins') {
        stage("Installing vendors" ) {
            // The Docker Image installs it with the root user, it's not available for the Jenkins user
            sh "composer global require fxp/composer-asset-plugin:~1.3 --no-ansi"
            sh "composer install --no-progress --no-ansi"
            sh "npm install"
        }
 
        stage("Compiling CSS" ) {
            sh "./node_modules/.bin/gulp sass"
        }
 
        stage("Running PHPUnit" ) {
            sh "./vendor/bin/phpunit ./tests/unit"
        }
    }
 
    stage("Building RPM" ) {
        if (env.JOB_NAME == "myafm-develop" ) {
            sh "mvn clean deploy"
        } else if (env.JOB_NAME == "myafm-release" ) {
            sh "mvn -Dresume=false release:prepare release:perform"
        }
    }
 
    stage("Deploying" ) {
        if (env.JOB_NAME == "myafm-develop" ) {
            build job: 'myafm-deploy', parameters: [string(name: 'env', value: 'dev')]
        } else if (env.JOB_NAME == "myafm-release" ) {
            build job: 'myafm-deploy', parameters: [string(name: 'env', value: 'stg')]
        }
    }
}

 
Ce pipeline fonctionne parfaitement pour les snapshots. Le problème c'est que lorsque maven fait une release, la phase "release:prepare" pousse un tag puis la phase "release:perform" checkout se tag et à partir de ces sources génère le RPM. Du coup vu que la récupération des vendors (et la génération de la CSS) se fait en dehors de Maven le RPM est incomplet.
 
Une autre piste serait, lors de la phase "release:perform" de copier les dépendences et fichiers générés en amont avant la phase de release mais ça me semble foireux (et je n'ai rien trouvé à ce sujet qui me permettrait de faire ça).
 
Ça fait une semaine que je tourne en rond sur ce build ça commence à m'énerver (et à coûter de l'argent )

Tranquille, le visiteur, il s'est posé dans mon salon et en a fait le tour.
 

 
Je crois que je n'ai jamais vu un petit oiseau aussi peu farouche. Il s'est laissé caresser. Comportement plutôt inattendu.
 

Soit c'est un drone, soit t'es une princesse Disney

Pour une fois que t'as une femelle dans ton salon

Comme quoi c'était un vraiment gros connard et un digne suppot de satan le patron

bring your own device merde
 

AAF

Merci mais j'avais fini mon apport de valeur
Je vais trouver autre chose pour la peine !

Bah justement tes trois étapes dans "container.inside", ça n'a pas de sens de les exécuter dans un conteneur je dirais.
 
Déjà première question, pourquoi utiliser maven vu que tu exécutes composer/npm/gulp à la main? Je connais pas PHP et je touche pas aux natasseries côté front-end, mais y a pas moyen de tout faire avec un seul outil, genre npm?
 
Ensuite si tu utilises Docker, pourquoi continuer à faire des RPM?
 
Tu devrais avoir Jenkins qui package tes artefacts, construit une image Docker avec ceux-ci, la publie et la taggue, et c'est tout.

C'est deja le cas pour ceux qui veulent (et ça nous arrange ). Par contre on hésite pas a équiper dès que demandé

Sinon, au taf y'a un mec qui ressemble à kadreg qui se promène de temps en temps dans les couloirs.
 
En tout cas il ressemble à un type que j'ai vu il y a longtemps, mais je ne me rappelle plus qui.

Cette fraîcheur au bural 15 degrés de moins qu'hier

edit : pardon 17 degrés de moins

J'ai une compagnie de transport en hélicoptère et on fait du BYOD les pilotes doivent amener leur propre hélico  

Bon j'ai craqué pour le changement de config, avec le code GRILLE sur HFR shop, livraison point relais et puis paiement en 3 fois, ça sera indolore come ça

 
1) Si ça a du sens car les dépendances composer dépendent de la version de PHP installée. PHP n'est pas forcément installé sur la machine Jenkins ou pas forcément dans la même version que le projet.
 
2) Maven c'est historique, ça nous permet de packager "facilement" en RPM, de versionner et de pousser sur le Nexus. A vrai dire j'aimerais bien dégager cette merde mais je n'ai pas encore trouvé d'alternative pour avoir une archive complète (vendor, css & js compilés, etc) prête à être déployée.
 
3) On ne package pas l'image Docker car elle ne sert que pour le développement.

Si tu arrives à faire ça tu auras grandement amélioré ton haut de bilan !

Je bosse depuis 2 jours sur une RAO... Cette fumisterie,, bordel...
 
Les définitions de composants pour les écritures des abaques fournies par le client sont débiles, les métriques utilisées pour les niveaux de complexité donnent une granularité qui n'a aucun sens...
 
Et encore, nous on a le marché depuis 4 ans, donc on peut faire des rapprochements avec certains trucs, mais les autres candidats, ils feront aussi bien de remplir les cases aux dés.