[Infrastructure] GitHub unintended consequences and triggering artifact generation

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Mon Aug 24 03:21:03 MST 2020


This is really helpful, thanks!

If anyone can find the time, it would be great to have some quick 
instructions on how to add "tags" on GitHub using the web UI. I could 
even use the local git CLI if it's easier to do that.

I believe the end goal is to add version tags for each produced Final 
Guideline.


DZ.

On 21/8/2020 6:31 μ.μ., Ryan Sleevi wrote:
>
>
> On Fri, Aug 21, 2020 at 11:30 AM Ryan Sleevi <sleevi at google.com 
> <mailto:sleevi at google.com>> wrote:
>
>
>
>     On Fri, Aug 21, 2020 at 5:10 AM Dimitris Zacharopoulos (HARICA)
>     <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>
>         On 20/8/2020 9:07 μ.μ., Ryan Sleevi wrote:
>>
>>
>>         On Thu, Aug 20, 2020 at 11:56 AM Dimitris Zacharopoulos
>>         (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>>
>>
>>             I followed
>>             https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period
>>
>>             for SC30 and SC31 based on the existing pull request and
>>             review
>>             (https://github.com/cabforum/documents/pull/203). 
>>
>>             The process had a step to delete the temporary branch
>>             (Ballot-SC30-and-31), which I did. Unfortunately, this
>>             also closed
>>             https://github.com/cabforum/documents/pull/207 because it
>>             was depending
>>             on the temporary branch Ballot-SC30-and-31.
>>
>>             Ryan, is this something you can fix? 
>>
>>
>>         Yes, it's no big deal and what I expected to happen.
>>
>>             We should probably update the
>>             instructions accordingly.
>>
>>
>>         For what? I used a non-standard approach that intentionally
>>         isn't documented to begin with ;-)
>
>         No objections to this approach. What I meant by "update the
>         instructions" was more of adding a "hint" to ballot proposers
>         with language on how to avoid such situations (e.g. "Use
>         separate branches for follow-up ballots..." or "don't create
>         new ballots on branches that are used for PR against the main
>         cabforum/documents branch"). I didn't intend to change the
>         existing workflow if it wasn't necessary. You might be
>         perfectly familiar with how Git repos work and interact with
>         each other, but another ballot proposer might get confused :)
>
>>
>>         I think we likely want to focus our documentation on common,
>>         normal flows intended for those not wanting to learn Git or
>>         GitHub (totally understandable) or the Chair and Vice-Chair
>>         to produce results, and don't need to try to document every
>>         scenario or use case. Weird edge cases (like where I've
>>         created multiple branches to show in-progress stuff) is
>>         something I think we can and should deal with on an ad-hoc
>>         basis, because it's rare, exceptional, and trying to document
>>         all the edge cases just introduces more room for failure.
>
>         I agree.
>>
>>             I also went to download the artifacts
>>             (https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx)
>>
>>             after the merge, but they were not updated according to
>>             the last
>>             commits. I assume that the artifacts are created the
>>             first time you
>>             create the pull request and not when you add commits to
>>             that pull
>>             request afterwards. Is that correct?
>>
>>
>>         No. The artifacts are generated for every commit.
>>
>>         It's not clear to me what you're describing, so hopefully you
>>         can clarify. The URL you linked is only updated after you
>>         merge the commit.
>
>         I merged the commit and waited a few minutes before
>         downloading the docx artifact, but the document was old.
>
>>         If you want to view commits as you add them to the PR, before
>>         it is merged, the link is to the branch name - e.g.
>>         https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx
>>
>>         If you added commits to the branch after you merged, and did
>>         not merge those, don't do that, that's not part of any
>>         documented instruction :)
>
>         This practice is avoided, and I believe we have configured the
>         repo to technically forbid that (i.e. require at least a
>         review by a second repo maintainer before merge to main is
>         allowed).
>
>>             What would be the best way to generate these artifacts
>>             now? We probably
>>             need to update the workflow to include steps to create
>>             the artifacts
>>             after the last merge.
>>
>>
>>         Doubtful! It's probably just that you didn't let the update
>>         process complete :)
>>
>>         https://travis-ci.org/github/cabforum/documents/builds/719653438
>>         shows it took 2 minutes and 6 seconds to generate the
>>         artifacts. Did you try to view immediately after committing,
>>         and before 2 minutes and 6 seconds had passed?
>>
>>         This is one of those things that is in the file of
>>         "improvements to consider" (switching to GitHub actions
>>         <https://github.com/cabforum/documents/projects/1#card-41784176>,
>>         so it adds the UI signals).
>
>         I could almost swear that I waited more than 2 minutes and 6
>         seconds before trying to download the artifacts, but
>         apparently I didn't :-)
>
>         Next time I will be more patient and wait, until we manage to
>         have UI signals for the CI.
>
>
>     Right now, https://travis-ci.org/github/cabforum/documents/builds/
>
>     But I almost hesitate to document that, because I'd like to fix
>     that "real soon" (modulo time commitments), since the GitHub
>     Actions would let you view it directly (as an attached artifact)
>
>
> Oh, and I suppose one bit I should have clarified: you don't need to 
> run the build after the merge. If your branch is mergable and in sync, 
> the branch's copy of the document is going to be identical to the main 
> repo. So just grab the copy from the PR branch, which does have UI 
> signals already (which also shows the CI status as failing, running, 
> or successful per-commit)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/infrastructure/attachments/20200824/1fec952e/attachment.html>


More information about the Infrastructure mailing list