While this bug is fixed: #867416: /tmp on www1 fills up with temp packaging directories, some -dev tarballs are still not being built.

For example: http://drupal.org/project/node_clone

I made a lot of commits over the last couple days, but the -dev tarballs are still from over a week ago.

hunmonk says it ran with message: Done packaging releases for node_clone from branches: 0 built, 5 considered.

Comments

heine’s picture

heine commented

Marked #869360: drupal.org does not create new dev releases about storm contrib (http://drupal.org/node/814652) as a duplicate.

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

http://drupal.org/project/mongodb
http://drupal.org/project/views

hunmonk’s picture

hunmonk commented

Done packaging releases for node_clone from branches: 0 built, 5 considered. this means that it's finding the branch releases, but it considers that they do not need to be rebuilt.

the way the script determines if a -dev release needs to be repackaged is by comparing the newest file in the CVS checkout with the age of the tarball -- if there's no newer file than the tarball, then it skips packaging.

since we've made zero changes to the packaging script in weeks, i'm wondering if somehow the file timestamps from files the packaging script examines from it's CVS checkout of the module is getting screwed up by some other change.

gerhard killesreiter’s picture

gerhard killesreiter commented

http://drupal.org/node/818322

also not packaged for over a week.

hunmonk’s picture

hunmonk commented
Title: some -dev tarballs still not packaged » check of -dev tarball generation time should use filemtime, not filectime
Project: Drupal.org infrastructure » Project
Version: » 6.x-1.x-dev
Component: Packaging » Packages
Assigned: Unassigned » hunmonk
Status: Active » Fixed

after digging into the packaging script further, i found that the time check on the tarballs uses filectime() -- this changes any time the inode metadata on the file changes.

as part of the hudson migration yesterday, we chown'd many of the tarballs so that hudson could properly manage them -- this of course reset the filectime, thus causing this bout of packaging issues.

killes, basic` and i all agreed that filemtime() is really what we want to use for this check, as that changes only when the file is actually written to.

this change *should* retroactively fix the -dev packaging issues. if you find one that's still not being packaged, try committing something to the branch that's connected to the release in question.

committed to 5.x-1.x-dev and 6.x-1.x-dev, and deployed on drupal.org

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.