-
Notifications
You must be signed in to change notification settings - Fork 3
Conversation
@whimboo can you have a look at this? |
Here some comments while looking at this:
More inline. |
@@ -39,6 +39,119 @@ | |||
<filterQueue>false</filterQueue> | |||
<properties class="hudson.model.View$PropertyList"/> | |||
</hudson.model.AllView> | |||
<listView> | |||
<owner class="hudson" reference="../../.."/> | |||
<name>-mozilla-central</name> |
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.
Please keep the alphabetical order for views.
If we are going with the clone-workspace-scm.jpi plugin, you want to remove the copy_artifact plugin. But first please check any kind of issues with clone-workspace-scm before making this decision. |
@whimboo, I dropped the clone-workspace-scm.jpi plugin and switched to copy_artifact plugin. |
<hudson.views.LastDurationColumn/> | ||
<hudson.views.BuildButtonColumn/> | ||
</columns> | ||
<includeRegex>^mozilla-central.*</includeRegex> |
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.
Beside the nightly builds I do not see entries for beta and release builds. Where are those?
I haven't said to drop the clone-workspace plugin. I asked you what the benefits are by using it compared to copy artifacts. But you didn't gave any answer to your observation. What's that bad on clone-workspace, so that you have replaced it? Regarding the job names we will have complete testruns for desktop, which span any backend tests and ui tests driven with Mozmill. There is no distinction yet, and I don't think we will have such in the near future. But separation might exist for the authentication method. That would have to be part of the job name. |
I haven't kept the clone-workspace plugin because we already had copy_artifacts landed and it didn't seemed to me a good practice to add a new plugin in favor of already existing one which does basically the same thing. |
@whimboo I made the changes, and I hope I replayed to all questions. |
<?xml version='1.0' encoding='UTF-8'?> | ||
<project> | ||
<actions/> | ||
<description>Job for holding the helper scripts for running the TPS testruns </description> |
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.
I think this script has to be run manually after the first start? In that case please update the README file and mention that.
Beside the remaining update for the README it looks fine. |
@whimboo I updated the readme, and squashed the commits. |
Quick note once again... I would prefer if you rebase your commits when the PR has been finalized, and no additional content gets added. |
If this is the first time you've started Jenkins, or your workspaces have | ||
recently been deleted, you will need to run an admin job to finish the setup. | ||
Open http://localhost:8080/view/+admin/ and schedule a build for the 'scripts' | ||
job by clicking the clock icon in the last column. |
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.
It's enough to say +admin/, and build the 'scripts' job.
@whimboo I updated the nit |
Ok, looks fine. Please rebase the PR, so I can get it landed. Thanks. |
@whimboo Rebased, Thanks. |
This is for issue #24, I added just jobs for desktop, for mobile if we decide we want to run them to we can just copy the job and add an extra parameter in xshell command.
Regarding trigger.py, I added just a plain script with options so it won't throw when called, this will be overwrited by upcoming pr from issue #17.