Hudson file permissions

[thomas.diesler]

Over the last couple of days we did not have any hudson runs because most files belong to ropalka.jbossws and do not have group write permissions. Hudson silently aborts a job if it cannot write the 'nextBuildNumber'

It is therefore important that you run

> umask 2
> hudson-setup
> hudson-start

That should cause all newly created files to have group write access. umask is a build-in shell command that cannot be run from within ant AFAIK.

[thomas.diesler]

I need to recreate the hudson env to verify what I claim above

[ropalka]

I was thinking about all those qa things some days ago Thomas. Here is my idea, how it could work:
* there will be a new user, let's call him builder for illustration
* each team member log in to jbws.dyndns.org
* then he switch to builder user
* do the QA staff, such as new environment setup, update of existing one
What do you think about this idea?

[thomas.diesler]

yeah, I was thinking about a dedicated user as well.

Then again

> su -l
> su whoever

will probably do the same

[ropalka]

Then I would go this way. There will be no need to rewrite hudson scripts and play with file permissions and deal with deep directory structures (time consuming issue) ;)

[ropalka]

Thomas,

umask 2
hudson-stop
hudson-setup
hudson-start

doesn't work, see:

http://jbws.dyndns.org:8180/hudson/job/CXF-Core-AS-4.2.2/11/console

[ropalka]

IMHO we should switch to user builder and use this approach instead