-
-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge branches #44
Merge branches #44
Conversation
Alpine image
…ns-group add Group flag
Conflicts: Dockerfile
# Conflicts: # Dockerfile
# Conflicts: # Dockerfile
# Conflicts: # Dockerfile
# Conflicts: # Dockerfile
# Conflicts: # Dockerfile
# Conflicts: # Dockerfile
# Conflicts: # Dockerfile
Maybe a package was removed from parent image
To enable `ps -p` option Fixes https://github.com/jenkinsci/docker-jnlp-slave/issues/65
[JENKINS-52847] Add procps package to alpine
groupadd and useradd are missing in alpine
# Conflicts: # Dockerfile
[JENKINS-51986] - Introduce a Java 11 packaging for the Debian image
Fixed Jenkins UID and GID to be consistent with the Jenkins Docker image
# Conflicts: # Dockerfile-alpine
@batmat Going forward, I believe we should move the build/packaging logic of jenkins/slave and jenkins/jnlp-slave to Remoting. Like jenkinsci/remoting#292 , but something with a new tooling. There is no sense to keep Docker packaging separated from the main codebase if we switch to the Jenkins-driven builds |
I agree, and in case you wonder I do remember we already discussed that a
bit some time ago :).
Nevertheless I believe this PR isn't backwards wrt. this mid term
direction: having all variants alongside each other is anyway I think a
good thing to have.
Overall, I thoroughly agree that we should have less agents' repo so it's
easier to manage the same way (building and publishing).
Cheers!
Le dim. 23 déc. 2018 à 01:35, Oleg Nenashev <notifications@github.com> a
écrit :
… @batmat <https://github.com/batmat> Going forward, I believe we should
move the build/packaging logic of jenkins/slave and jenkins/jnlp-slave to
Remoting. Like jenkinsci/remoting#292
<jenkinsci/remoting#292> , but something with a
new tooling.
There is no sense to keep Docker packaging separated from the main
codebase if we switch to the Jenkins-driven builds
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANqbUNXb19TY-n6aQKakqhyYucePcYuks5u7s-zgaJpZM4ZfnFb>
.
|
Yes, I am OK with the approach in general. |
Hello, @oleg-nenashev when to merge the PR Install Git LFS in image. #39? It is almost one month and a half since @batmat referenced the PR on 22 Jan. We need it! |
@Tianny I am not sure what you are asking me about. @batmat requested changes, and they have not been addressed yet. I also do not maintain this repo actively nowadays, please see https://groups.google.com/d/msg/jenkinsci-dev/uc6NsMoCFQI/AIO4WG1UCwAJ |
LGTM I'm going to merge before it becomes stale again, and will update dockerhub builds |
Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
…g-nenashev/workdir-env-var Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
…g-nenashev/workdir-env-var Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
…g-nenashev/workdir-env-var Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
…g-nenashev/workdir-env-var Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
…ev/workdir-env-var Add JENKINS_AGENT_WORKDIR env var (update of jenkinsci#44)
Following up on #38 (comment) and agreement there from @carlossg for instance.
I propose in this PR to merge all branches into a single one and many Dockerfiles. This will make aligning variants much simpler, instead of having to file 3 PRs like #38.
Also created a small
build.sh
which I'll call from aJenkinsfile
as soon as https://issues.jenkins-ci.org/browse/INFRA-1857 gets looked at by @olblak or someone else with sufficient permissions.Once this is merged, we will delete the branches and keep only
master
to avoid ambiguity for contributors.