Obtiene SHA correcto para calcular entradas faltantes #2751
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
La versión anterior usaba github.event.pull_request.merge_commit_sha para obtener el commit con el merge entre la rama origen y la rama destino. Sin embargo, este atributo no siempre está disponible. En primer lugar, el atributo puede ser un string o null: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=opened#pull_request Y segundo, la documentación aclara que el atributo se establece sólo si el atributo "mergeable" es "true", lo cual no ocurre necesariamente de forma inmediate después de abrir un PR. Según https://docs.github.com/en/free-pro-team@latest/rest/pulls/pulls?apiVersion=2022-11-28#get-a-pull-request: """ The value of the mergeable attribute can be true, false, or null. If the value is null, then GitHub has started a background job to compute the mergeability. After giving the job time to complete, resubmit the request. When the job finishes, you will see a non-null value for the mergeable attribute in the response. If mergeable is true, then merge_commit_sha will be the SHA of the test merge commit. """ Este delay en el cálculo de la mergeabilidad de los PRs es probablemente lo que está causando que nuestra acción no funcione como deseamos: al ejecutarse la primera vez cuando se abre el PR, la acción NO tiene un merge_commit_sha establecido, por lo que la acción "checkout" procede con el valor por defecto para el evento pull_request_target, que es la rama destino, por lo que todas las entradas aparecen como no traducidas. Este commit cambia el SHA al que hacemos checkout al principio de esta acción para simplemente obtener el HEAD de la rama de origen. En retrospectiva, obtener el commit de merge no reporta beneficios. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
|
Excellent 👌 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
La versión anterior usaba github.event.pull_request.merge_commit_sha para obtener el commit con el merge entre la rama origen y la rama destino. Sin embargo, este atributo no siempre está disponible. En primer lugar, el atributo puede ser un string o null:
https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=opened#pull_request
Y segundo, la documentación aclara que el atributo se establece sólo si el atributo "mergeable" es "true", lo cual no ocurre necesariamente de forma inmediate después de abrir un PR. Según
https://docs.github.com/en/free-pro-team@latest/rest/pulls/pulls?apiVersion=2022-11-28#get-a-pull-request:
"""
The value of the mergeable attribute can be true, false, or null. If the value is null, then GitHub has started a background job to compute the mergeability. After giving the job time to complete, resubmit the request. When the job finishes, you will see a non-null value for the mergeable attribute in the response. If mergeable is true, then merge_commit_sha will be the SHA of the test merge commit. """
Este delay en el cálculo de la mergeabilidad de los PRs es probablemente lo que está causando que nuestra acción no funcione como deseamos: al ejecutarse la primera vez cuando se abre el PR, la acción NO tiene un merge_commit_sha establecido, por lo que la acción "checkout" procede con el valor por defecto para el evento pull_request_target, que es la rama destino, por lo que todas las entradas aparecen como no traducidas.
Este commit cambia el SHA al que hacemos checkout al principio de esta acción para simplemente obtener el HEAD de la rama de origen. En retrospectiva, obtener el commit de merge no reporta beneficios.