Added multiarch support by docker buildx #336

bivasda1 · 2021-02-10T19:21:36Z

Signed-off-by: Bivas Das bivasda1@in.ibm.com

What does this PR do?

Enables docker buildx support in GitHub Actions job to build and publish multiarch docker images. All the workflows (nightly build, PR check, and release) are updated to have multiarch support.

What issues does this PR fix or reference?

This refers to #321

Reviewers

@ericwill Could you please review this PR

bivasda1 · 2021-02-10T19:22:02Z

FYI - @nickboldt - Follow up PR as per comments here - https://issues.redhat.com/browse/CRW-1475?focusedCommentId=15721358&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15721358

ericwill

A few changes are required, please see comments inline. Also, please test to make sure that the regression from the last attempt doesn't happen this time.

.github/workflows/release.yml

.github/workflows/nightly-build-publish.yml

bivasda1 · 2021-02-15T17:10:12Z

@ericwill Can you please review this PR, I have changed Accordingly

Below change requests are updated

Copyright header and also year is Updated
Enabled log into both quay.io and dockerhub
Enabled multiarch build using buildx for Both the happy path image and the base images
Added Platformfile

PLATFORMS

arbitrary-users-patch/build_images.sh

.github/workflows/release.yml

bivasda1 · 2021-02-17T12:06:43Z

@ericwill added Platform file in arbitrary-users-patch and arbitrary-users-patch/happy-path location, accordingly modified the script.

ericwill · 2021-02-19T21:53:31Z

@bivasda1 please rebase the PR and let's merge it next week. There is a 7.26.2 release next week so that will be a good test run.

nickboldt · 2021-02-20T17:13:30Z

@mkuznyetsov FYI ^

@bivasda1 if rebased and ready by EOD Tuesday, we can include in Wednesday's release. If not... will slip to the week after.

Note too that we've been having issues with qemu emulated s390x buildx builds, so you might want to only include ppc64le in this PR as the s390x build might make it harder to validate.

bivasda1 · 2021-02-20T18:57:46Z

@nickboldt I will remove s390x form Platform files and will rebase as quickly as possible.

bivasda1 · 2021-02-22T09:02:54Z

@nickboldt @ericwill I have rebased.

nickboldt · 2021-02-22T19:57:45Z

.github/workflows/release.yml

+          context: .
+          file: ./build/dockerfiles/Dockerfile
+          platforms: ${{  steps.prep.outputs.platforms }}
+          tags:  quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ steps.prep.outputs.version }},quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ steps.prep.outputs.short_sha1 }},quay.io/eclipse/${{ steps.prep.outputs.image }}:${{  github.event.inputs.version }}


you're pushing the same image w/ 3 tags here:

quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ steps.prep.outputs.version }},

quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ github.event.inputs.version }}

quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ steps.prep.outputs.short_sha1 }},

should it be only two pushes for prep.outputs.version and short_sha1? Not sure why we would want the submitted version 7.y.z AND version from VERSION file AND the short sha from the tip of the checked out branch.

@mkuznyetsov WDYT?

Also there's an extra space in ${{ github.event.inputs.version }} which might cause error?

@nickboldt

should it be only two pushes for prep.outputs.version and short_sha1?
Yes

prep.outputs.version-->7.27.0-SNAPSHOT event.inputs.version-->7.27.0

I was trying to release proper version, so that event.inputs.version I have added. Please let me know should I remove event.inputs.version?

I will remove spaces from ${{ github.event.inputs.version }}

we don't release -SNAPSHOT versions to quay.

https://quay.io/repository/eclipse/che-devfile-registry?tab=tags

Just nightly + sha tag and release (7.yy.z) + sha tag.

bivasda1 · 2021-02-23T07:22:14Z

.github/workflows/release.yml

+          context: .
+          file: ./build/dockerfiles/Dockerfile
+          platforms: ${{  steps.prep.outputs.platforms }}
+          tags: quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ steps.prep.outputs.version }},quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ steps.prep.outputs.short_sha1 }}


@ericwill @nickboldt I have removed quay.io/eclipse/${{ steps.prep.outputs.image }}:${{ github.event.inputs.version }} and rebased

outputs.version-->7.27.0-SNAPSHOT

That's the wrong version to release. We would want 7.27.0, not the -SNAPSHOT version. Releases are for releases, nightly is for snapshots. :D

nickboldt · 2021-02-23T15:56:16Z

.github/workflows/release.yml

+        run: |
+          SHORT_SHA1=$(git rev-parse --short HEAD)
+          echo ::set-output name=short_sha1::${SHORT_SHA1}
+          VERSION=$(head -n 1 VERSION)


If this value != inputs.version we should use inputs.version.

In fact I'm not sure why we need BOTH a computed value (7.27.0-SNAPSHOT) and an input value (7.27.0).

I would expect that if the input is missing, we compute it... but I believe part of the release process is to SET the value in the VERSION file, so there's no point reading the file before we set the value. :)

Instead I'd just take the value from the input as it should be the same as the VERSION file, once the release is complete.

Correct @mkuznyetsov ?

@nickboldt do you expect ci-multiarch workflows should be formatted https://github.com/eclipse/che-dashboard/blob/master/.github/workflows/ci-multiarch.yaml#L91-L115 referenced to eclipse-che/che-dashboard#119 (comment)

@nickboldt as of now, make-release.sh is called first from another workflow, which makes changes to VERSION file, and then this workflow does the rest. Here it reads the VERSION file, in case it was triggered by the push to the release branch, which has no inputs

Because it was slightly confusing, I made a PR (about which I've forgot 😃 )
https://github.com/eclipse/che-devfile-registry/pull/338/files
it makes make-release.sh to be called from this workflow

So which approach are we taking? Right now as it stands, the 7.27.0-SNAPSHOT problem won't happen because the workflow is triggered after the file is changed. But we can have this PR wait until https://github.com/eclipse/che-devfile-registry/pull/338/files is merged and then adjust the approach. What do you guys think? cc @nickboldt @mkuznyetsov

PR 338 is ready to merge, after fixing all the shellcheck complaints. https://github.com/eclipse/che-devfile-registry/pull/338/files

I've merged it, @bivasda1 please adjust the PR to make sure -SNAPSHOT isn't pushed as part of the tag

nickboldt · 2021-02-23T17:39:20Z

do you expect ci-multiarch workflows should be formatted

Since I don't own this project, I'll let the TL comment... but my $0.02 is that it seems like from a project management perspective it might be better/more efficient to have:

1 GH action that can handle all three (four) arches
rather than
1 GH action action for x64 and ppc64 (and aarch64), while a travis script separately handles s390x.

mkuznyetsov · 2021-02-23T17:42:53Z

.github/workflows/release.yml

        required: true
+        default: '7.y.z'


I'd suggest having an empty default value, so we wouldn't have accidental workflow runs with 7.y.z taken as a default parameter.

bivasda1 · 2021-02-24T07:36:42Z

do you expect ci-multiarch workflows should be formatted https://github.com/eclipse/che-dashboard/blob/master/.github/workflows/ci-multiarch.yaml#L91-L115 referenced to eclipse-che/che-dashboard#119

Since I don't own this project, I'll let the TL comment... but my $0.02 is that it seems like from a project management perspective it might be better/more efficient to have:

1 GH action that can handle all three (four) arches
rather than

1 GH action action for x64 and ppc64 (and aarch64), while a travis script separately handles s390x.

@ericwill Could you please share your thoughts @nickboldt suggestions

bivasda1 · 2021-02-24T09:09:41Z

@nickboldt Could you please review this PR,I think Versioning issue is resolved now.

bivasda1 · 2021-02-26T18:23:19Z

Please remove this file: .github/workflows/.nightly-build-publish.yml.swp

Could u please review the PR I have deleted .github/workflows/.nightly-build-publish.yml.swp

nickboldt · 2021-03-02T19:06:58Z

please rebase, you're out of date again :(

Signed-off-by: Bivas Das <bivasda1@in.ibm.com>

bivasda1 · 2021-03-03T12:19:39Z

@nickboldt Rebased and Added buildx support make-release.sh

ericwill

Let's give it a shot

nickboldt · 2021-03-08T14:25:44Z

seems legit for x and power arches but this won't work for s390x and will need to be refactored in future.

+1 for pushing this for now, with the caveat that we'll need something like eclipse-che/che-dashboard#177 to support pushing each per-arch to quay independently, then combining them into a single multi-arch digest/manifest.

nickboldt

+1, but won't work for s390x.

ArvinB · 2021-03-08T14:41:12Z

Just commenting...here is a bash script very similar to what I do for building multi-arch images. As @nickboldt mentioned from eclipse-che/che-dashboard#177 that there is a risk of building for s390x. My issue primarily is that the CentOS repo's do not contain the packages for s390x. I don't have enough knowledge yet on which repo(s) to include, so for now I disable them all so that basically the yum and dnf updates all just pass on through.

registry=quay.io
repo=some/path
version=1.0.0
platforms=("amd64" "s390x")

tags=""
for platform in ${platforms[*]}
do
  echo "Building for linux/$platform"
  tag=$registry/$repo:${version}_$platform
  docker buildx build --load --platform linux/$platform -t $tag .
  docker push $tag
  tags="${tags} ${tag}"
done

docker manifest create $registry/$repo:$version $tags
docker manifest push $registry/$repo:$version
docker buildx imagetools inspect $registry/$repo:$version

FYI
@sleshchenko There is great interest in building multi-arch.

ericwill · 2021-03-08T15:03:28Z

@bivasda1 so the build was successful, but please fix/update the following in a new PR:

the 7.28.0-SNAPSHOT tag shouldn't be there
a nightly tag hasn't been published/updated -- likely this is what the 7.28.0-SNAPSHOT tag should be

https://quay.io/repository/eclipse/che-devfile-registry?tab=tags

nickboldt · 2021-03-08T16:39:43Z

There, I fixed it. :) https://quay.io/repository/eclipse/che-devfile-registry?tab=tags&tag=nightly

Also deleted the 7.28.0-SNAPSHOT tag

nickboldt · 2021-03-08T16:49:36Z

But also... the image is not multiarch :(

#23 [linux/arm64 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
#23 sha256:3075bc83c5d59c32a9b1a25f5afd028722d2f71f259502bc813ddbcec8d90bf5
#23 0.092 /bin/sh: /tmp/install-editor-tooling.sh: not found
#23 ERROR: executor failed running [/bin/sh -c /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh]: exit code: 127

#12 [linux/amd64 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
#12 sha256:feb2a9698386ef81638fdeab39c0d81e0bbdad912bc578d7027b6a30d8144c40
#12 0.229 container process is already dead
#12 CANCELED

#17 [linux/ppc64le 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
#17 sha256:6d32b5832d93ea6889e549b5179b2c324f77d75fb4ce4be71c5176c98682b25b
#17 0.235 container process is already dead
#17 CANCELED
------
 > [linux/arm64 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh:
------
Dockerfile:10
--------------------
   8 |     # Install common terminal editors in container to aid development process
   9 |     COPY install-editor-tooling.sh /tmp
  10 | >>> RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
  11 |     
  12 |     USER 10001
--------------------
error: failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh]: exit code: 127
Pushing quay.io/eclipse/che-antora-2.3:nightly to remote registry
An image does not exist locally with the tag: quay.io/eclipse/che-antora-2.3
The push refers to repository [quay.io/eclipse/che-antora-2.3]
Building quay.io/eclipse/che-cpp-rhel7:nightly based on registry.access.redhat.com/devtools/llvm-toolset-rhel7 ...
time="2021-03-08T15:15:42Z" level=warning msg="No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load"

-- https://github.com/eclipse/che-devfile-registry/runs/2057571221?check_suite_focus=true

and if I skopeo inspect I only get amd64:

$➔ skopeo --override-os ppc64le inspect docker://quay.io/eclipse/che-devfile-registry:nightly | jq -r .Architecture
amd64

Contrast with:

$➔ skopeo inspect docker://quay.io/eclipse/che-dashboard:multiarch-next --raw | jq -r '.manifests[].platform.architecture'
amd64
arm64
ppc64le
s390x

ArvinB · 2021-03-08T17:03:02Z

@nickboldt I am curious how this will get resolved, because this is similar to the issue I faced when trying to build registry images for s390x.

nickboldt · 2021-03-08T18:08:44Z

well, there's the approach in https://github.com/eclipse/che-dashboard/blob/master/.github/workflows/ci-multiarch.yaml ...

prabhav-thali · 2021-03-09T08:18:13Z

.github/workflows/nightly-build-publish.yml

+        with:
+          context: .
+          file: ./build/dockerfiles/Dockerfile
+          platforms: ${{ steps.package.outputs.content }}


@nickboldt Image is still single arch because I guess slight change is required here. Instead of platforms: ${{ steps.package.outputs.content }}, it needs to be platforms: ${{ steps.prep.outputs.platforms }} as defined on line 37.

bivasda1 · 2021-03-09T13:16:09Z

But also... the image is not multiarch :(

#23 [linux/arm64 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
#23 sha256:3075bc83c5d59c32a9b1a25f5afd028722d2f71f259502bc813ddbcec8d90bf5
#23 0.092 /bin/sh: /tmp/install-editor-tooling.sh: not found
#23 ERROR: executor failed running [/bin/sh -c /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh]: exit code: 127

#12 [linux/amd64 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
#12 sha256:feb2a9698386ef81638fdeab39c0d81e0bbdad912bc578d7027b6a30d8144c40
#12 0.229 container process is already dead
#12 CANCELED

#17 [linux/ppc64le 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
#17 sha256:6d32b5832d93ea6889e549b5179b2c324f77d75fb4ce4be71c5176c98682b25b
#17 0.235 container process is already dead
#17 CANCELED
------
 > [linux/arm64 5/6] RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh:
------
Dockerfile:10
--------------------
   8 |     # Install common terminal editors in container to aid development process
   9 |     COPY install-editor-tooling.sh /tmp
  10 | >>> RUN /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh
  11 |     
  12 |     USER 10001
--------------------
error: failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c /tmp/install-editor-tooling.sh && rm -f /tmp/install-editor-tooling.sh]: exit code: 127
Pushing quay.io/eclipse/che-antora-2.3:nightly to remote registry
An image does not exist locally with the tag: quay.io/eclipse/che-antora-2.3
The push refers to repository [quay.io/eclipse/che-antora-2.3]
Building quay.io/eclipse/che-cpp-rhel7:nightly based on registry.access.redhat.com/devtools/llvm-toolset-rhel7 ...
time="2021-03-08T15:15:42Z" level=warning msg="No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load"

-- https://github.com/eclipse/che-devfile-registry/runs/2057571221?check_suite_focus=true

and if I skopeo inspect I only get amd64:

$➔ skopeo --override-os ppc64le inspect docker://quay.io/eclipse/che-devfile-registry:nightly | jq -r .Architecture
amd64

Contrast with:

$➔ skopeo inspect docker://quay.io/eclipse/che-dashboard:multiarch-next --raw | jq -r '.manifests[].platform.architecture'
amd64
arm64
ppc64le
s390x

@nickboldt @ericwill
there are these images which are not multiarch. So do we need to excluded from build for releasing multiarch?

che-antora-2.3          docker.io/antora/antora:2.3.3
che-dotnet-2.2          mcr.microsoft.com/dotnet/core/sdk:2.2-stretch
che-dotnet-3.1          mcr.microsoft.com/dotnet/core/sdk:3.1.301-buster
che-nodejs8-centos      registry.centos.org/che-stacks/centos-nodejs
che-php-7               quay.io/eclipse/che-php-base:7.4
che-python-3.6          centos/python-36-centos7:1

che-cpp-rhel7           registry.access.redhat.com/devtools/llvm-toolset-rhel7->not compatible for arm64
che-rust-1.39           rust:1.39.0-slim->not compatible for ppc64le

Even we can enable multiarch for these repos.

che-php-7               quay.io/eclipse/che-php-base:7.4->registry.access.redhat.com/ubi8/php-72
che-python-3.6          centos/python-36-centos7:1->registry.access.redhat.com/ubi8/python-36

ericwill · 2021-03-09T14:19:35Z

@nickboldt @ericwill
there are these images which are not multiarch. So do we need to excluded from build for releasing multiarch?

che-antora-2.3          docker.io/antora/antora:2.3.3
che-dotnet-2.2          mcr.microsoft.com/dotnet/core/sdk:2.2-stretch
che-dotnet-3.1          mcr.microsoft.com/dotnet/core/sdk:3.1.301-buster
che-nodejs8-centos      registry.centos.org/che-stacks/centos-nodejs
che-php-7               quay.io/eclipse/che-php-base:7.4
che-python-3.6          centos/python-36-centos7:1

che-cpp-rhel7           registry.access.redhat.com/devtools/llvm-toolset-rhel7->not compatible for arm64
che-rust-1.39           rust:1.39.0-slim->not compatible for ppc64le

Even we can enable multiarch for these repos.

che-php-7               quay.io/eclipse/che-php-base:7.4->registry.access.redhat.com/ubi8/php-72
che-python-3.6          centos/python-36-centos7:1->registry.access.redhat.com/ubi8/python-36

Yes we need to exclude stacks that aren't available on multi-arch. For example if rust is x86 only, then it should be excluded from builds on other arches.

nickboldt · 2021-03-09T14:50:56Z

For arch specific devfile exclusion filtering, see what we're dong downstream in CRW:

if there's a .s390x or .ppc64le version of a devfile, use that instead of the default. If file is empty, remove the devfile entirely
switch from openjdk to openj9 image:
- https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.7-rhel-8/dependencies/che-devfile-registry/build/scripts/swap_images.sh
if the devfile references a sidecar which doesn't exist (or doesn't exist for the current arch), remove the devfile while adding digests:
- https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.7-rhel-8/dependencies/che-devfile-registry/build/scripts/write_image_digests.sh#L22-L26

--> moved to eclipse-che/che#19239

bivasda1 · 2021-03-09T15:00:34Z

For arch specific devfile exclusion filtering, see what we're dong downstream in CRW:

if there's a .s390x or .ppc64le version of a devfile, use that instead of the default. If file is empty, remove the devfile entirely

https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.7-rhel-8/dependencies/che-devfile-registry/build/scripts/swap_yamlfiles.sh

https://github.com/redhat-developer/codeready-workspaces/tree/crw-2.6-rhel-8/dependencies/che-devfile-registry/devfiles/00_java-microprofile-xp2 (x only)

https://github.com/redhat-developer/codeready-workspaces/tree/crw-2.6-rhel-8/dependencies/che-devfile-registry/devfiles/00_java-microprofile-xp1 (z & p only)

switch from openjdk to openj9 image:

https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.7-rhel-8/dependencies/che-devfile-registry/build/scripts/swap_images.sh

if the devfile references a sidecar which doesn't exist (or doesn't exist for the current arch), remove the devfile while adding digests:

https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.7-rhel-8/dependencies/che-devfile-registry/build/scripts/write_image_digests.sh#L22-L26

@nickboldt Thanks for your details :)

Partial revert of #336 Related to eclipse-che/che#19486 Signed-off-by: Eric Williams <ericwill@redhat.com>

bivasda1 requested review from benoitf, ericwill, JPinkney, sunix, svor, tsmaeder, vinokurig and vitaliy-guliy as code owners February 10, 2021 19:21

ericwill requested a review from nickboldt February 10, 2021 19:39

ericwill suggested changes Feb 10, 2021

View reviewed changes

bivasda1 commented Feb 15, 2021

View reviewed changes

PLATFORMS Outdated Show resolved Hide resolved

arbitrary-users-patch/build_images.sh Show resolved Hide resolved

.github/workflows/release.yml Outdated Show resolved Hide resolved

ericwill previously approved these changes Feb 19, 2021

View reviewed changes

bivasda1 force-pushed the master branch from 3f1e350 to 2b4805b Compare February 22, 2021 08:52

nickboldt reviewed Feb 22, 2021

View reviewed changes

nickboldt mentioned this pull request Feb 22, 2021

Multiarch build support by docker buildx eclipse-che/che-dashboard#119

Merged

bivasda1 force-pushed the master branch from 2b4805b to 46a5243 Compare February 23, 2021 07:09

bivasda1 commented Feb 23, 2021

View reviewed changes

nickboldt reviewed Feb 23, 2021

View reviewed changes

mkuznyetsov reviewed Feb 23, 2021

View reviewed changes

bivasda1 force-pushed the master branch from 46a5243 to dde818b Compare February 24, 2021 09:04

bivasda1 force-pushed the master branch 2 times, most recently from 0548984 to 953c109 Compare February 26, 2021 18:20

bivasda1 force-pushed the master branch from 953c109 to e44019d Compare March 3, 2021 12:07

Rebased and Added Multiarch support using buildx

f738cde

Signed-off-by: Bivas Das <bivasda1@in.ibm.com>

bivasda1 force-pushed the master branch from e44019d to f738cde Compare March 3, 2021 12:15

ericwill approved these changes Mar 4, 2021

View reviewed changes

nickboldt self-requested a review March 8, 2021 14:25

nickboldt approved these changes Mar 8, 2021

View reviewed changes

ericwill merged commit c6567ce into eclipse-che:master Mar 8, 2021

che-bot added this to the 7.28 milestone Mar 8, 2021

prabhav-thali reviewed Mar 9, 2021

View reviewed changes

ericwill mentioned this pull request Mar 9, 2021

Enable devfile exclusion filtering based on architecture eclipse-che/che#19239

Closed

prabhav-thali mentioned this pull request Mar 17, 2021

Add s390x support in GH actions #346

Closed

ericwill mentioned this pull request Apr 1, 2021

Disable multi-arch builds for dev containers and happy path #362

Merged

9 tasks

ericwill added a commit that referenced this pull request Apr 1, 2021

Disable multi-arch builds for dev containers and happy path (#362)

65a109f

Partial revert of #336 Related to eclipse-che/che#19486 Signed-off-by: Eric Williams <ericwill@redhat.com>

nickboldt pushed a commit that referenced this pull request Apr 1, 2021

Disable multi-arch builds for dev containers and happy path (#362)

b2c7afb

Partial revert of #336 Related to eclipse-che/che#19486 Signed-off-by: Eric Williams <ericwill@redhat.com>

Added multiarch support by docker buildx #336

Added multiarch support by docker buildx #336

Conversation

bivasda1 commented Feb 10, 2021

What does this PR do?

What issues does this PR fix or reference?

Reviewers

bivasda1 commented Feb 10, 2021

ericwill left a comment

Choose a reason for hiding this comment

bivasda1 commented Feb 15, 2021

bivasda1 commented Feb 17, 2021

ericwill commented Feb 19, 2021

nickboldt commented Feb 20, 2021

bivasda1 commented Feb 20, 2021

bivasda1 commented Feb 22, 2021

nickboldt Feb 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bivasda1 Feb 23, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mkuznyetsov Feb 23, 2021 • edited Loading

Choose a reason for hiding this comment

ericwill Mar 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nickboldt commented Feb 23, 2021 • edited Loading

Choose a reason for hiding this comment

bivasda1 commented Feb 24, 2021 • edited by nickboldt Loading

bivasda1 commented Feb 24, 2021 • edited Loading

bivasda1 commented Feb 26, 2021

nickboldt commented Mar 2, 2021

bivasda1 commented Mar 3, 2021

ericwill left a comment

Choose a reason for hiding this comment

nickboldt commented Mar 8, 2021

nickboldt left a comment

Choose a reason for hiding this comment

ArvinB commented Mar 8, 2021

ericwill commented Mar 8, 2021

nickboldt commented Mar 8, 2021

nickboldt commented Mar 8, 2021

ArvinB commented Mar 8, 2021 • edited Loading

nickboldt commented Mar 8, 2021

Choose a reason for hiding this comment

bivasda1 commented Mar 9, 2021 • edited Loading

ericwill commented Mar 9, 2021

nickboldt commented Mar 9, 2021 • edited Loading

bivasda1 commented Mar 9, 2021

nickboldt Feb 22, 2021 •

edited

Loading

bivasda1 Feb 23, 2021 •

edited

Loading

mkuznyetsov Feb 23, 2021 •

edited

Loading

ericwill Mar 1, 2021 •

edited

Loading

nickboldt commented Feb 23, 2021 •

edited

Loading

bivasda1 commented Feb 24, 2021 •

edited by nickboldt

Loading

bivasda1 commented Feb 24, 2021 •

edited

Loading

ArvinB commented Mar 8, 2021 •

edited

Loading

bivasda1 commented Mar 9, 2021 •

edited

Loading

nickboldt commented Mar 9, 2021 •

edited

Loading