Eric/use mule in jenkins#1072
Conversation
This includes changes that allow travis to use mule to execute our ci process
Multiple proxies are not supported in go 1.12, so since proxies fail occasionally, we'll use only direct for now. After upgrading to 1.13, we'll add proxies here
These are failing inconsistently with timeouts. Increasing it since it seems to be passing most of the time
… eric/useMuleInJenkins
| echo Verifying a generic node will start directly | ||
| ${BINDIR}/algod -d ${DATADIR} & | ||
| algod -d ${DATADIR} & | ||
| sleep 1 |
There was a problem hiding this comment.
If this does becomes an issue, this is not the correct place to fix it. you might want to try to sleep in case the pgrep returns no pids in update_running_count
There was a problem hiding this comment.
I'm surprised the answer isn't to make verify_at_least_one_running have a retry loop like verify_one_running has
There was a problem hiding this comment.
@tsachiherman @brianolson I just updated verify_at_least_one_running to include the retry loop and removed the sleep statements. Good thinking.
Removed unnecessary sleep statements.
… eric/useMuleInJenkins
| proc ::AlgorandGoal::TakeAccountOnline { ADDRESS FIRST_ROUND LAST_ROUND TEST_PRIMARY_NODE_DIR } { | ||
| if { [ catch { | ||
| spawn goal account changeonlinestatus --address $ADDRESS --firstvalid $FIRST_ROUND --lastvalid $LAST_ROUND -d datadir | ||
| spawn goal account changeonlinestatus --address $ADDRESS --firstvalid $FIRST_ROUND --lastvalid $LAST_ROUND -d datadir --online |
There was a problem hiding this comment.
this change is supposed to be a no-op. i.e. the default for --online is true. If this is not the case, then we have a bug, which is unrelated to this PR.
There was a problem hiding this comment.
@tsachiherman The --online is required by the goal account changeonlinestatus command. Without it, the command fails. I will create a ticket to fix the command and update this test case to remove the --online option.
https://github.com/algorand/go-algorand-internal/issues/541.
Created pull request: #1170
@tsachiherman Reverted the addition of the --online flag since it will no longer be necessary.
There was a problem hiding this comment.
The PR(#1170) looks good to me, but I wonder how this test did not detect this issue before.
It's quite concerning that we have a test that is supposed to test exactly one thing - and the test doesn't alert us when that thing is broken.
There was a problem hiding this comment.
We found this issue by running the integration tests as part of the Jenkins/Mule pipeline testing. The issue was causing the test test/e2e-go/cli/goal/expect/listExpiredParticipationKeyTest.exp to fail. What is puzzling is why this error does not surface as part of the Travis build and testing. I created this ticket to resolve: https://github.com/algorand/go-algorand-internal/issues/542
since it is no longer a required field.
onetechnical
left a comment
There was a problem hiding this comment.
Hmm, the mule-specific changes here look okay at a glance, but the test changes give me pause. Is it possible to add commentary around changes as to why they were made?
The resource-constrained platforms require more time to complete the steps of the tests. Especially for the expect tests that are running 2 node networks for goal to interact with. |
| mkdir -p $(SRCPATH)/tmp/node_pkgs && \ | ||
| CHANNEL=$(BUILDCHANNEL) PKG_ROOT=$(SRCPATH)/tmp/node_pkgs NO_BUILD=True VARIATIONS=$(OS_TYPE)-$(ARCH) \ | ||
| scripts/build_packages.sh $(OS_TYPE)/$(ARCH) && \ | ||
| mkdir -p $(SRCPATH)/tmp/node_pkgs/$(BUILDCHANNEL)/$(OS_TYPE)-$(ARCH)/data && \ |
There was a problem hiding this comment.
I'm pretty sure that this is going to break the existing mule tasks (see the package*.yaml files in the root dir) because this path is different.
If you look at the PKG_ROOT var in the deleted snippet above it's expecting the build assets to be put in a different path than the one you have now.
| export PATH=$(SRCPATH)/tmp/node_pkgs/$(BUILDCHANNEL)/$(OS_TYPE)-$(ARCH)/bin:$$PATH && \ | ||
| export PATH=$(SRCPATH)/tmp/node_pkgs/$(BUILDCHANNEL)/$(OS_TYPE)-$(ARCH)/tools:$$PATH && \ | ||
| export PATH=$(SRCPATH)/tmp/node_pkgs/$(BUILDCHANNEL)/$(OS_TYPE)-$(ARCH)/test-utils:$$PATH && \ | ||
| export SRCROOT=$(SRCPATH) && \ |
There was a problem hiding this comment.
Looks like these env vars should be precede the call to the shell script rather than exporting them before the call to the script.
There was a problem hiding this comment.
Look below to see where the call to test/scripts/e2e.sh is appended to the series of exports.
There was a problem hiding this comment.
The script needs the env vars, not the calling environment. It's a common shell idiom to do:
FOO=foo BAR=bar my_script.sh
Also, the ci-build target is doing it that way and it would be great to keep that consistency.
I realize this was existing code, but it would be great if you could change it.
Ben's package scripts depend on this structure
Eric/use mule in jenkins
|
@egieseke Thanks for the changes, I added one more comment. |
|
Just approved. I'm assuming the brittleness of the tests will be addressed in future tickets. |
onetechnical
left a comment
There was a problem hiding this comment.
I'm okay with this, but let's pay close attention to how it affects tests. This is also predicated on us doing a deeper dive into tests.
Summary
Create a Jenkins mule pipeline to build and test go-algorand.
https://github.com/algorand/go-algorand-internal/issues/424
Test Plan
Setup and executed Jenkins pipeline:
https://jenkins.algodev.network/job/JenkinsMulePipeline/