Wait longer for docker to start up in workflow/reproducible.yaml.

[daniel-wong-dfinity-org]

Motivation

macos-12 was timing out (example).

Changes

Overall effect: docker now has 10 minutes to start up before we give up, instead of 3 minutes.

Implementation: Instead of using the official actions-setup-docker, I forked it from the original repo. The "real" changes are in the fork. The changes here just point to the fork instead of the official repo.

The changes in the fork are suggested by a long-open pull request to the official actions-setup-docker repo. The maintainers have not responded to that PR, nor to related issue reports in almost a year. This is why I forked their repo.

Tests

.github/workflows/reproducible.yaml now gets past the actions-setup-docker step after 3 min 15 s; it only needed 15 additioinal seconds to work (example).

Todos

• [ X ] Add entry to changelog (if necessary).

References

• NNS1-2914

[dskloetd]

Should we really own a fork of this repo? Is this a temporary solution? What is the long term plan?
Should the fork live in a DFINITY account rather than your account?

[daniel-wong-dfinity-org]

Ideally, no, but the maintainers of the original are not responding to an existing pull request, nor to related issue reports.

Yes, Ideally, the repo would be owned by DFINITY. Not sure how to do that, because when I forked, it said I wasn't allowed to make it a DFINITY repo 🤷 Maybe, this is just a matter of asking IT to grant me permission?

[dskloetd]

Can you ask around what would be the normal process for something like this?
Since this isn't a very urgent issue, I'd rather do it properly.

[bitdivine]

In the past I have been allowed to use forks - if anything the fork is a bit more trustworthy than the original. The original in this case is by a single developer we have no relationship with. But I do also put effort into merging fixes upstream, both internally (e.g. PRs to the sdk) and externally (e.g. with yq). I would hope that forks are not forever.

The developer seems to be Chinese. I wanted to sponsor them, as developers tend to be responsive to sponsors and this might get the fix merged upstream but couldn't understand their sponsoring page. @daniel-wong-dfinity-org - do you understand Chinese? Maybe you would have better luck? I could also use the GitHub sponsoring system. I tend not to use that if developers have posted a more specific sponsoring link.

There is a general problem with governance of open source projects, specifically with maintainers falling off the face of the planet or being unresponsive. One thing that would be nice to have is a stock DAO that works well for small projects, not the big projects like OpenChat where setting up the DAO is like an IPO. Just a small thing that covers succession planning and maintenance.

[daniel-wong-dfinity-org]

At this point, I think it is fair to assume that rousing the original developer is infeasible.

I have figured out how to create a "fork" that is controlled by dfinity, and have pointed to that.

Seems like everyone would now consider this to be "proper" enough.

(ofc, ideally the original developer would accept the pull request, and we can go back to pointing at that and delete all of our forks.)

[daniel-wong-dfinity-org]

Bah. The workflow runner cannot see dfinity/actions-setup-docker, even though it definitely exists.

[dskloetd]

It doesn't exist if I try it in an incognito window so it should probably be made public.

[dskloetd]

Thanks!