[Infrastructure] GitHub unintended consequences and triggering artifact generation

[Dimitris Zacharopoulos (HARICA)]

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.


Thanks,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/infrastructure/attachments/20200821/8d9e5dad/attachment.html>