[Infrastructure] GitHub unintended consequences and triggering artifact generation

[Ryan Sleevi]

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/infrastructure/attachments/20200821/ed49c62a/attachment-0001.html>