Create edxCypressTestsJob.groovy

[kashifch]

No description provided.

[kashifch]

Hi @estute,

I have tried to create a DSL job for the cypress tests, I was testing it locally and wanted to send it to you after it is tested but my Jenkins gets corrupted and I have to do the setup again. It would be good ff you can take a look and suggest any improvements. I used the approach in https://github.com/edx/jenkins-job-dsl/blob/master/platform/jobs/edxEndToEndTestsJob.groovy and created 3 maps, one triggering on PR creation, one triggering on Merging into master and the third is supposed to be triggered by stage deployment but couldn't find a relevant trigger for it. I think the e2e tests are triggered by a GOCD pipeline, do we have to take a similar path?

Also do we need to take care of environment vars in the DSL as well, or should we just create these manually on Jenkins and call these in Jenkinsfile

[estute]

@kashifch regarding your questions:

• I think adding these tests into the GOCD pipeline makes sense. That way, we consider it part of the release process and it can block a deployment from occurring if a bug/regression is found. Take a look at this: https://github.com/edx/edx-gomatic/blob/f32501e158520ef0df8e0e9e0bfae087ae59e1b2/edxpipelines/patterns/edxapp.py#L645. You can do the work in the Jenkinsfile/DSL to run this way, and test it out by sending a curl with a token. You can treat the GOCD work as a separate task.
• We do not support doing anything manual on build-jenkins. The server is fully automated and manual changes can be lost when we run out automation. This way, we can have code reviews and history for things like environment variables and job definitions. Now, as for if the variable should be in the DSL or the pipeline, my first question is- how sensitive is the value? If it's a password/token or something like that, we should store it as a credential and allow the job to use it as an encrypted variable. Otherwise, putting it into the Jenkinsfile should be fine. The only time I would opt for putting it into the DSL would be if you wanted to create multiple jobs from one Jenkinsfile. We do this in the edx-platform. We have a Jenkinsfile for bok choy tests, and use the DSL to create multiple jobs pointing to the same Jenkinsfile but w/ different environment variables.

This is an example of what I mean:

• https://github.com/edx/jenkins-job-dsl/blob/master/platform/jobs/pipelines/edxPlatformPipelinePr.groovy#L29
• https://github.com/edx/jenkins-job-dsl/blob/master/platform/jobs/pipelines/edxPlatformPipelinePr.groovy#L288
• https://github.com/edx/edx-platform/blob/master/scripts/Jenkinsfiles/bokchoy