There is currently no ability to restrict jobs which are able to run on the same agent from potentially interacting with each other. There are a bunch of feature requests asking for this sort of granularity, but if I understand your question correctly the most fitting request would be this one BAM-2504 Jira Ticket
It's a huge gap in the product line, the ...
As stated in the documentation, VOLUME instruction inherits the directory content and permissions existing in the container, so you can workaround the problem with a dockerfile like this:
RUN useradd -d /home/ubuntu -ms /bin/bash -g root -G sudo -p ubuntu ubuntu
RUN mkdir /opt/myvolume && chown ubuntu /opt/myvolume
If your question is how to manage database changes consider something like Flyway. This lets you control your changes via tracked config files in your repository and apply them via an automated & controlled process - use your normal code review & promotion steps.
If the question is "how do I get devs to stop bugging me to run arbitrary SQL commands" ...
You could embed database schema and data changes into source code control by using a concept called database migrations. These can then be executed on dev and staging environments as part of a partially automated deployment process.
For example in my environment (PHP Web application), I am using Doctrine Schema for schema updates, Yii2 migrations for data ...
I see a first problem, DevOps is about building teams able to handle an application from build to exploitation.
So your devs should have access to the databases, you quoted various cases which are the reality for a lot of people and the major drawback which is turning you and your colleague in a bottleneck as well as impeding your own work.
Other answers ...
The reason for the failure is that the server in question, unlike all the others, had sftp disabled.
Why the error messages are what they are, I don't know (why the errant scp transfer mechanism failed?), but I don't have time right now to investigate with the debug option enabled.
But that was the issue, and adding scp_if_ssh=True to the [ssh_connection] ...
I had a similar problem, this worked for me:
Write Docker file with:
# Create app layer:
# Create app user & group "testuser" with IDs:
RUN groupadd -r testuser --gid 1234 && useradd -d /home/testuser -ms /bin/bash -r -g testuser testuser --uid 1234
# Create "testuser" working dir:
# Make working dir known ...
As described in https://github.com/docker-library/tomcat/issues/35, this is related to the storage driver used (aufs). Changing to use overlay2 solved the issue:
docker run -ti --rm \
-v $PWD:/workdir \
-v $HOME/.ssh:/root/.ssh \
--user $(id -u):$(id -g) \
As long as you're not doing anything funny with the entrypoint in the container, this will leave files owned as the user that invoked Docker.
There are 4 type of user permissions in Jenkins:
Jenkins is accessible for everyone with no permissions. Basically anyone can do anything. This should be used for internal use only.
User authentication (all admins)
All users are admins. The authentication method can use Jenkins’ own user database, LDAP, Unix user/group database, servelet container (e....