Closed Bug 957852 Opened 12 years ago Closed 11 years ago

Add files and cronjob for mciconf on mozqa1.qa.scl3

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

task
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bburton, Assigned: cturra)

References

Details

(Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/152] [qa-automation-blocked])

Add files and cronjob for mciconf on mozqa1.qa.scl3 * source: https://github.com/mozilla/mciconf/tree/release * desired URL: http://www.mozqa.com/mciconf
[root@mozqa1.qa.scl3 ~]# cd /data/www/mozqa.com/ [root@mozqa1.qa.scl3 mozqa.com]# ls ca data index.html mozmill-env qa-testcase-data webapi-permissions-tests [root@mozqa1.qa.scl3 mozqa.com]# git clone https://github.com/mozilla/mciconf Cloning into 'mciconf'... remote: Reusing existing pack: 699, done. remote: Total 699 (delta 0), reused 0 (delta 0) Receiving objects: 100% (699/699), 3.84 MiB | 1.79 MiB/s, done. Resolving deltas: 100% (302/302), done. -> % svn ci -m "cronjob and script for mciconf, bug 957852" Adding webapp/files/mozqa/data-bin/mciconfig-github-pull.sh Adding webapp/files/mozqa/etc-crond/mciconf-github-pull Transmitting file data .. Committed revision 80363. Info: Applying configuration version '80362' Notice: /File[/data/bin/mciconfig-github-pull.sh]/ensure: defined content as '{md5}51f5eb527e01850eeb280fa9bd361830' Notice: /File[/etc/cron.d/mciconf-github-pull]/ensure: defined content as '{md5}48bd0c481f14f9d67e78ba4ac8fd6b82'
Confirmed working, so RF!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Correct. Thanks!
Status: RESOLVED → VERIFIED
Sorry for reopening this, but somehing has not been correctly added to cron here. You did the initial checkout on Jan 8th, which is still the date of the dirs and files right now. None of the pushing we did on the release branch in the repository ended up on mozqa.com. Can someone please check that ASAP, so that we can use the tool for the upcoming release update tests? Thanks a lot!
Severity: normal → major
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Whiteboard: [qa-automation-blocked]
Can we please get someone to check that? It's somewhat important for us to be able to push code to our production server. Thanks.
Assignee: bburton → server-ops-webops
Severity: major → critical
Status: REOPENED → NEW
OS: Mac OS X → All
Hardware: x86 → All
Dropping this down a notch so that we could get someone in the morning...
Severity: critical → major
Meh that still paged. I'll take this and find someone in the morning.
Assignee: server-ops-webops → ashish
Ok, I took a look at this and it should be fixed now. The script didn't have +x set... Next cron run in 2 mins.
Status: NEW → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → FIXED
> Notice: /Stage[main]/Webapp::Mozqa/File[/data/bin/mciconfig-github-pull.sh]/mode: mode changed '0644' to '0775'
There are some more problems here: * There are local changes, so the git pull command in the cron job doesn't work because we don't force a local reset before the pull. Because of that we never get updates * Some tool is modifying our permissions on all the files from the repository to 644 -> 755. May this be puppet? We should stop it from doing so. * The current branch we are pulling from is gh-pages. But that is our staging instance. So this was never correctly setup, even mentioned so in comment 0. 'release' is the correct branch here.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: ashish → server-ops-webops
Severity: major → normal
Whiteboard: [qa-automation-blocked] → [kanban:https://kanbanize.com/ctrl_board/4/152] [qa-automation-blocked]
Can we get an update here? Any ETA when this can be solved?
If it takes forever for IT to get those things fixed, we will consider to move mozqa1 to puppetagain, which is also open, and we could work on fixes ourselves.
2 months without an update here. :( Jake, when can this finally be corrected?
Severity: normal → critical
Flags: needinfo?(nmaul)
Paging on call. I'll take this until the morning and try and hand over to someone from webops.
Assignee: server-ops-webops → rwatson
looks like there were local changes that were causing git to exit in error. [root@mozqa1.qa.scl3 ~]# bash -x /data/bin/mciconfig-github-pull.sh + DATA_DIR=/data/www/mozqa.com/mciconf + cd /data/www/mozqa.com/mciconf + git pull -q error: Your local changes to the following files would be overwritten by merge: app/css/app.css app/data/platforms.json app/js/controllers/appController.js app/js/directives/directives.js app/templates/document.html app/templates/form.html Please, commit your changes or stash them before you can merge. Aborting i git stash[ed] these changes and ran again. can you confirm everything looks as expected now? [root@mozqa1.qa.scl3 mciconf]# bash -x /data/bin/mciconfig-github-pull.sh + DATA_DIR=/data/www/mozqa.com/mciconf + cd /data/www/mozqa.com/mciconf + git pull -q [root@mozqa1.qa.scl3 mciconf]# git log -1 commit 913854925bb14cf4f455c5dec195dd51ae3b79ce Author: Henrik Skupin <mail@hskupin.info> Date: Wed Aug 27 22:22:18 2014 +0200 Non-released versions of Firefox are not listed even when candidate builds exist (#24)
Flags: needinfo?(nmaul) → needinfo?(hskupin)
Assignee: rwatson → cturra
i am going to mark this bug as r/fixed. :whimboo - if there is still an issue here, please feel free to reopen.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
I think at the moment it looks fine code wise. Thanks Chris. I have actually no idea why those files have been changed locally. All what we do is grabbing updates via the cron job. So can I propose an update to the bash script? Something I would like to see that in those cases we always force an update, and local changes should be discarded first. Can we make the bash file look like: DATA_DIR=/data/www/mozqa.com/mciconf cd $DATA_DIR git reset --hard git pull -q
Status: RESOLVED → REOPENED
Flags: needinfo?(hskupin)
Resolution: FIXED → ---
Oh, and I have seen that git is operating on the wrong branch! $ git branch -a * gh-pages remotes/origin/HEAD -> origin/gh-pages remotes/origin/gh-pages remotes/origin/master remotes/origin/release As stated in comment 0 the code has to be based of branch release!
Status: REOPENED → ASSIGNED
i have updated the cron as requested and did a `git checkout` of the release branch. [root@mozqa1.qa.scl3 mciconf]# git checkout release Branch release set up to track remote branch release from origin. Switched to a new branch 'release' [root@mozqa1.qa.scl3 mciconf]# git pull Already up-to-date. [root@mozqa1.qa.scl3 mciconf]# git log -1 commit ce2a02757300568f4dc108ce9e6c56600a70dedc Author: Cosmin Malutan <cosmin.malutan@softvision.ro> Date: Tue Feb 18 17:59:04 2014 +0200 Warn the user when invalid platform gets parsed from uploaded config file(#12)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Thanks Chris. That seems to work fine now. So I rebased the latest changes from gh-pages to the release branch, and pushed them to upstream. Sadly I didn't see them updated within the 15min period, which we usually used to pull our web related repositories on this host. Checking the crontab entry for mciconf-github-pull I noticed that there is no execution each 15min but once per hour. So can you please do the last remaining change here from "15 * ..." to "*/15 * ..." in the crontab file? Once that has been done we can really close this bug as fixed!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
updated cron pushed out via puppet and should be available within 30 minutes. marking this as r/fixed again :) $ svn diff sIndex: modules/webapp/files/mozqa/etc-crond/mciconf-github-pull =================================================================== --- modules/webapp/files/mozqa/etc-crond/mciconf-github-pull (revision 92963) +++ modules/webapp/files/mozqa/etc-crond/mciconf-github-pull (working copy) @@ -1,2 +1,2 @@ MAILTO="webops-cron@mozilla.com" -15 * * * * root /data/bin/mciconfig-github-pull.sh +*/15 * * * * root /data/bin/mciconfig-github-pull.sh
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Alright. After all this ping pong :) this is finally fixed now. Thanks Chris for all the updates.
Status: RESOLVED → VERIFIED
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.