[Infrastructure] GitHub unintended consequences and triggering artifact generation

[Ryan Sleevi]

On Fri, Aug 21, 2020 at 11:30 AM Ryan Sleevi <sleevi at google.com> wrote:

>
>
> On Fri, Aug 21, 2020 at 5:10 AM Dimitris Zacharopoulos (HARICA) <
> 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> 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/20200821/78a67dc2/attachment.html>