Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PH] Create workflow to test backward compatibility of performance harness #1356

Merged
merged 44 commits into from
Jul 14, 2023

Conversation

oschwaldp-oci
Copy link
Member

@oschwaldp-oci oschwaldp-oci commented Jun 30, 2023

Create workflow to test backward compatibility of performance harness with prior leap releases.

Introduces a reusable workflow build-base for the steps common to these workflows.

Resolves: #1156

@oschwaldp-oci oschwaldp-oci added the OCI Work exclusive to OCI team label Jun 30, 2023
@oschwaldp-oci oschwaldp-oci self-assigned this Jun 30, 2023
@oschwaldp-oci oschwaldp-oci marked this pull request as draft June 30, 2023 14:56
Base automatically changed from GH-1156-initial-ph-cicd-workflow to main June 30, 2023 18:18
Copy link
Member

@spoonincode spoonincode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is still in draft but I have some maintenance concerns with where it's going.

uses: AntelopeIO/upload-artifact-large-chunks-action@v1
with:
name: ${{matrix.platform}}-build
path: build.tar.zst
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't be copy pasting the 3 jobs above. If we need a leap build to be performed as part of this workflow we should refactor the existing workflows so that building leap is a reusable workflow, that way it can be used from the per-PR workflow and from here.

Performing a build here may not strictly be required since you can download artifacts from other workflow runs, but that requires the user to manually perform a build with the other workflow (and waiting for it to complete) before calling this workflow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spoonincode - Starting to address this initially with a reusable workflow build-base. Would like to further refine to allow it to either do the build from scratch or, if the build exists, reuse the artifacts. Still strategizing how to make this work.

with:
owner: AntelopeIO
repo: leap
file: 'leap-.*-${{matrix.platform}}.04-x86_64.deb' # Ex. leap-3.1.4-ubuntu20.04-x86_64.deb
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might be able to combine these two if blocks via something like file: '(leap).*${{matrix.platform}}.04.*(x86_64|amd64).deb'

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, good call. Addressed: c63042b

- name: Extract and Place Rev Leap Version artifacts
run: |
mkdir tmp
dpkg -x leap*.deb tmp
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why extract it instead of installing it? This won't be reliable across versions due to dependency changes. For example, let's say in 5.0 we no longer require gmp: it won't be in the base builder image any longer yet leap 4.0 requires that to be installed to run. Using the leap-4.0.deb resolves these for us.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. Addressed: b7dea9b

run: |
echo "Workflow Stub"
cd build
ctest --output-on-failure -R performance_test_basic_read_only_trxs --timeout 480
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having all of these manually defined like this is at risk to forgetting to add one later. Maybe we should have a new label for performance tests, or maybe just -R performance_test is enough.

Copy link
Member Author

@oschwaldp-oci oschwaldp-oci Jul 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Collapsing these back down into a regular expression is the plan. Was splitting them out to get clearer information when a test failed during initial debugging. Although it is going to make skipping tests of newer features more difficult, where older versions of nodeos aren't expected to succeed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe I can do this with a mix of -R and -E depending on nodeos version.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed: 800a37e

cleos time-limit option was added in 3.2 but is not in 3.1 so need to be able to differentiate on minor version number.
…orted command line options in earlier versions.
@oschwaldp-oci oschwaldp-oci marked this pull request as ready for review July 11, 2023 21:05
@oschwaldp-oci oschwaldp-oci changed the title Create workflow to test backward compatibility of performance harness [PH] Create workflow to test backward compatibility of performance harness Jul 12, 2023
password: ${{secrets.GITHUB_TOKEN}}
package-name: builders
build-base:
uses: AntelopeIO/leap/.github/workflows/build_base.yaml@GH-1156-ph-cicd-nodeos-versions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should just be

 uses: .github/workflows/build_base.yaml

Hardcoding AntelopeIO and/or leap breaks forks/mirrors, and we shouldn't be hardcoding the branch -- it should just use the same ref as the caller

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed: 477f62c and 0da3e7b

@@ -23,28 +23,17 @@ on:
type: string

permissions:
packages: read
packages: write
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would need to refresh my memory on how permissions & reusable workflows work to know for sure.. but can we leave this to read and only plumb through the write permission on the resusable workflow call? That is, can we do something like

 build-base:
    uses: .github/workflows/build_base.yaml
    permissions:
       packages: write
       contents: read

Copy link
Member Author

@oschwaldp-oci oschwaldp-oci Jul 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. Finally got that to work. Had tried a couple other options before and didn't get the right combination it seems. Addressed: 495d6ea and 4e19e36

Copy link
Member

@spoonincode spoonincode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just one permission nit, otherwise it seems good best I can tell

value: ${{ jobs.d.outputs.p }}

permissions:
packages: write
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should just be read, since below the build-platforms job has

    permissions:
      packages: write
      contents: read

So I think as long as build_base.yaml is called with packages: write, which it seems to be:

build-base:
uses: ./.github/workflows/build_base.yaml
permissions:
packages: write
contents: read

Having packages: read in this location should cause all jobs in this workflow other then build-platform be read, where build-platform is write.

(btw your ph_backward_compatibility.yaml already does this)

permissions:
packages: read
contents: read

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. Slipped past when I was changing the others. I've corrected that now.

platform-file: .cicd/platforms.json
password: ${{secrets.GITHUB_TOKEN}}
package-name: builders
build-base:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this job (that uses the reusable workflow) doesn't have a name it seems to show up as simply build-base in the GUI in various places. I'm a little surprises it doesn't inherit the callee workflow name. Maybe we could consider giving this a name (even just Build) to show up nicer.

Screenshot 2023-07-13 at 22-22-58 PH Create workflow to test backward compatibility of performance harness · AntelopeIO_leap@b59fede


Screenshot 2023-07-13 at 22-23-21 AntelopeIO_leap C implementation of the Antelope protocol

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated with name Run Build Workflow:
image
image

@oschwaldp-oci oschwaldp-oci merged commit d243f85 into main Jul 14, 2023
31 checks passed
@oschwaldp-oci oschwaldp-oci deleted the GH-1156-ph-cicd-nodeos-versions branch July 14, 2023 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OCI Work exclusive to OCI team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CICD support for previous versions of nodeos for Performance Harness
3 participants