Diferencia entre revisiones de «Flujo de trabajo con GitHub»

De Wiki de EGC
Saltar a: navegación, buscar
(Página creada con «Como ya hemos comentado en la asignatura, una forma muy habitual de trabajar con GitHub es por medio de [https://help.github.com/articles/about-pull-requests/ pull requests...»)
 
(→‎Ejercicio)
 
(No se muestra una edición intermedia del mismo usuario)
Línea 10: Línea 10:
 
= Ejercicio =
 
= Ejercicio =
  
−
# Vamos a añadir una nueva característica a nuestra aplicación que permita decir hola en distintos idiomas. Para eso, vamos a crear una rama con nombre add-languages.
+
# Vamos a añadir una nueva característica a nuestra aplicación. Para eso, vamos a crear una rama nueva.
−
# En la nueva rama creada vamos a editar el fichero greeting.html en src/main/resources/templates con este contenido<source lang="html">
+
# En al rama nueva hacemos los cambios deseados.
−
<!DOCTYPE HTML>
 
−
<html xmlns:th="http://www.thymeleaf.org">
 
−
<head>
 
−
    <title>Getting Started: Serving Web Content</title>
 
−
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 
−
</head>
 
−
<body>
 
−
    <p th:text="${hello} + ', ' + ${name} + '!'" />
 
−
</body>
 
−
</html>
 
−
</source>
 
−
# añadimos la clase GreetingTranslator:<source lang="java">
 
−
package hello;
 
−
 
 
−
public class GreetingTranslator {
 
−
 
−
public String sayHelloIn(String lang) {
 
−
String hello;
 
−
if ("en".equals(lang)) {
 
−
hello = "hello";
 
−
} else if ("es".equals(lang)) {
 
−
hello = "hola";
 
−
} else {
 
−
hello = "no hablo tu idioma";
 
−
}
 
−
}
 
−
 
 
−
}
 
−
</source>
 
−
# y modificamos el método greeting de la clase GreetingController como sigue:<source lang="java">
 
−
    @RequestMapping("/greeting")
 
−
    public String greeting(@RequestParam(value="name", required=false, defaultValue="World") String name,
 
−
      @RequestParam(value="lang", required=false, defaultValue="en") String lang,
 
−
      Model model) {
 
−
    model.addAttribute("hello", greetingTranslator.sayHelloIn(lang));
 
−
        model.addAttribute("name", name);
 
−
        return "greeting";
 
−
    }
 
−
</source>
 
 
# Haz un commit de estos cambios y haz un push de la nueva rama a GitHub
 
# Haz un commit de estos cambios y haz un push de la nueva rama a GitHub
−
# Una vez que hemos decidido que estos cambios abarcan la funcionalidad deseada, vamos a crear una pull request siguiendo estas instrucciones: https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request
+
# Una vez que hemos decidido que estos cambios abarcan la funcionalidad deseada, vamos a crear una pull request siguiendo estas instrucciones: https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request (Fíjate bien que la pull request la haces a la rama <code>master</code> de tu repositorio y no a otro repositorio ni a <code>resinas/master</code>).
 
# Si abres la pull request que se ha creado, podrás observar abajo cómo se ejecuta una nueva build en Travis CI con la pull request.
 
# Si abres la pull request que se ha creado, podrás observar abajo cómo se ejecuta una nueva build en Travis CI con la pull request.
 +
# ¿Ha funcionado con éxito la build de la pull request o ha fallado? ¿Por qué motivo?

Revisión actual del 17:43 19 nov 2018

Como ya hemos comentado en la asignatura, una forma muy habitual de trabajar con GitHub es por medio de pull requests. Las pull requests se crean desde una rama a otra del repositorio y permite decirle a otros qué cambios has hecho en un repositorio en GitHub. Una vez que un pull request se abre, puedes discutir y revisar los cambios potenciales con colaboradores y continuar haciendo commits antes de que los cambios se integren en el repositorio. Un escenario muy habitual donde se trabaja con pull requests es si se sigue un flujo de desarrollo del estilo de GitHub Flow.

Cuando se abre una pull request, Travis CI recibe una notificación de pull request de GitHub. Esta notificación se transforma en una nueva build. Durante la build se actualiza el estado de los commits a uno de los siguientes:

  • un warning porque aún se está construyendo
  • que la pull request se debe de integrar con cuidado porque la build falló
  • que la pull request se puede integrar sin problemas porque la build tuvo éxito

Travis CI inicia una build cuando se abre por primera vez una pull request y cuando se añaden commits a ella. Además, la prueba se realiza a partir de un merge de la rama con la feature y la rama master, no únicamente de la rama con la feature.

Ejercicio

  1. Vamos a añadir una nueva característica a nuestra aplicación. Para eso, vamos a crear una rama nueva.
  2. En al rama nueva hacemos los cambios deseados.
  3. Haz un commit de estos cambios y haz un push de la nueva rama a GitHub
  4. Una vez que hemos decidido que estos cambios abarcan la funcionalidad deseada, vamos a crear una pull request siguiendo estas instrucciones: https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request (Fíjate bien que la pull request la haces a la rama master de tu repositorio y no a otro repositorio ni a resinas/master).
  5. Si abres la pull request que se ha creado, podrás observar abajo cómo se ejecuta una nueva build en Travis CI con la pull request.
  6. ¿Ha funcionado con éxito la build de la pull request o ha fallado? ¿Por qué motivo?
Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Flujo_de_trabajo_con_GitHub&oldid=7933»