-
Notifications
You must be signed in to change notification settings - Fork 23
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
Move acceptance tests at PRs to NUE #1429
base: master
Are you sure you want to change the base?
Conversation
08de81c
to
ab51286
Compare
Running this jenkins pipeline at the same place we have the open build service should make the process faster and less complex. However, in NUE we have less hardware, so we can have max 6 envs. Given we have only 6 envs in NUE and not 10 as we have in PRV, we need to do a cleanup, specifically remove the "custom" pipelines, like "jordi", "qe-squad", and "iron" ones. This way, we have 3 for generic master PR testing, 1 for 4.3 PR, one for master reference, and one for 4.3 reference. Fix rhlike and deblike minion names for PR Testing in NUE Fix domain for pr testing: domain should depend on the localization fix deblike macs in NUE Share environments between uyuni and suma4.3, because we have less hardware but also less users, thus we do not need to rebase. Signed-off-by: Jordi Massaguer Pla <jmassaguerpla@suse.com>
fix container url build repos is 15.6 Signed-off-by: Jordi Massaguer Pla <jmassaguerpla@suse.com>
324100a
to
7b85565
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thank you !
@@ -1,10 +1,10 @@ | |||
#!/usr/bin/env groovy | |||
|
|||
node('pull-request-test') { | |||
node('pull-request-test-nue') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't care too much where this node is located and this is only used to trigger the pipeline. But.. see below:
def pipeline = load "jenkins_pipelines/environments/common/pipeline-pull-request.groovy"
pipeline.run(params)
We should define the node we want to use, as otherwise, this will always goes through the node defined at this point, meaning always NUE.
Something like:
node(my_calculated_node) {
def pipeline = load "jenkins_pipelines/environments/common/pipeline-pull-request.groovy"
pipeline.run(params)
}
I think, another approach it could be to pass it by param into the run method, and inside it calculate the agent to use.
Make sense for you?
@@ -35,6 +35,14 @@ node('pull-request-test') { | |||
first_env = 1; | |||
last_env = 10; | |||
email_to = params.email_to; | |||
if (platform_localisation == "NUE") { | |||
domain = "mgr.suse.de" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, and really just a matter of taste, I would have both domains as constants in pipeline-pull-request-envs.groovy
.
Then use the platform_localisation
passed as string parameter in the pipeline to calculate which domain to use inside pipeline-pull-request-envs.groovy
.
The reasoning about it, is that those domains might change over the years and we might have multiple pipelines using the pipeline-pull-request-envs.groovy
, so it looks more maintainable fmpov.
Related card about domain changes https://github.com/SUSE/spacewalk/issues/25378
Signed-off-by: Jordi Massaguer Pla <jmassaguerpla@suse.com>
fix build repo
Running this jenkins pipeline at the same place we have the openbuildservice should make the process faster and less complex.