Inject patch in Docker Installation


(Dorianamouroux) #1

Hello there,

I’m trying to setup a single sign on system from my custom oauth2 provider.
I found this topic to overwrite the process after successful redirection : Disable “create account” screen for CAS logins
I’m using the docker installation, I don’t know how to inject code inside the container, should I bundle this around a plugin and clone it in the after_code hooks ?

Thank you for your help,

Dorian


(Matt Palmer) #2

Yes, you should bundle the necessary functionality into a plugin and install it as part of the container build. You could also change the location that Discourse itself is cloned from to a git repo that contains the patches you want, but forking the main Discourse codebase is just going to leave you with a maintenance headache in the future when you need to update to a newer version of Discourse. So stick with a plugin.


(Dorianamouroux) #3

I created a private repository and managed to clone it with mounting my ssh key folder, thank you for your help !


(Matt Palmer) #4

World of pain commencing in 3… 2… 1…


(Dorianamouroux) #5

It was pretty easy

  - volume:
      host: /home/server/.ssh
      guest: /root/.ssh

and

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone git@github.com:dorianamouroux/private_repo.git

(Rafael dos Santos Silva) #6

Ahhhhhhhhhhhhhhhhhh

I guess @mpalmer undestood the same as me. That the private repo was a Discourse fork! It’s a plugin! That’s perfect!


(Dorianamouroux) #7

Haha no, just private repository.
But having a private fork of a project is not that complicated, you juste need 2 git remote and you pull the public one when you want updates, I did it for gollum wiki it works like a charm (the project is barely maintained now though)


(Mark Moorcroft) #8

I had a similar problem, but getting the GitLab oauth to work. I did the following:

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://gitlab.com/gitlab-org/discourse-omniauth-gitlab.git
run:
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  #- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"

  - exec: apt install unzip
  - exec: unzip /shared/ssl/NTAM_Collection_Ubuntu_2016.2.zip -d /usr/local/share/ca-certificates/
  - exec: chmod 444 /usr/local/share/ca-certificates/*
  - exec: c_rehash /usr/local/share/ca-certificates
  - exec: update-ca-certificates

  - exec: echo "End of custom commands"

(Matt Palmer) #9

Sorry I misunderstood what you were saying.

As far as maintaining a private fork of Discourse, here’s the difference:

Discourse has several people employed full-time to add features and fix bugs (including security bugs), as well as a large number of fantastic contributors from all over the Internet. There’s a pretty good chance the changes in a private fork is going to end up conflicting with the changes made in mainline fairly often, necessitating manual review and modification of the local patches.