Skip to content
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

Accessible link #260

Open
wants to merge 110 commits into
base: master
Choose a base branch
from
Open

Accessible link #260

wants to merge 110 commits into from

Conversation

Aagbator
Copy link

@Aagbator Aagbator commented Jan 6, 2021

Added "auth-link" class to forgot password

Brian Sadler and others added 30 commits September 4, 2014 08:33
Move necessary assets and configuration out for production deployment
remove javascript that is useless but was making the loading+autofocus lag
default service option in config
call logout on bz platform too to keep things straight
kill the redirect because it gives better interop with canvas in our case
should show the log in page rather than log out to avoid template error
sadleb and others added 30 commits May 11, 2017 10:22
Fix Volunteer menus to match public website
Remove navigation menus since they don't add much value and are hard to maintain
Missed a div in last commit. Also, format the file better
link in script for staging test (will be in separate pr)
people keep asking about this message, just telling them what they ne…
…e-param

use service param if available in logout page's login form
As part of getting docker-compose files, some versions of gems were locked, but they don't match what we have on staging and prod. Changing the values to match.
Update Docker files to be able to setup a development environment
Move the services onto a common network shared by all other apps.
Don't remove volumes on restart and rebuild. The dev can do that if
they need to b/c they want to nuke everything. We should rely on a
generally working env and not require nuking the volumes in the normal
dev flow. Use COPY instead of ADD b/c ADD wasn't doing what I thought it
was. COPY is recommended and volumes are mounted through the
docker-compose.yml file so that changes to files inside and outside the
container are reflected in both places.
…reflected inside.

This is done by mounting the entire codebase as a volume when started
using docker-compose.

Note: a dependency of webmock (dev builds only) got updated to the point
of only supporting ruby 2.3 and above. So I locked it down to the last
version that supported ruby 2.1. The dependency tree was:

  webmock was resolved to 1.24.6, which depends on
    addressable was resolved to 2.7.0, which depends on
      public_suffix was resolved to 4.0.1

Also, stop supporting a local dev. All dev should be done with the
container. Removed Gemfile.lock for the docker build so that everything
inside is the same as outside and it's like you're just developing
locally with the Docker container acting as the web-server.
We weren't .dockerignore'ing Gemfile.lock, so when you last built
the Docker image it built whatever Gemfile.lock (which is .gitignored)
into the image. This may not match what `bundle install` installs and things
fail. Just ignore this file in the image build for now. The proper solution
is to check-in Gemfile.lock and have a process for how to update it, but since
we're planning on getting rid of this app/server, I'm not investing time to fix
this up properly.

TESTING:
- Did a fresh docker build (no cache) and it failed to start. Made this change
  and rebuilt. It started.
Make Docker restarts/rebuilds work when new gem versions are available.
Pinning it at the last version supported for Ruby 1.9.3. We had
never done a staging of prod release after the last time I changed this
(or just generally for years and years). So this make this repo at
least deployable to staging and prod even if none of the recent changes
have needed to be deployed b/c they are all for dev env stuff.

TESTING:
- manually made the change on staging and ran `bundle install --path vendor/bundle`
- restarted the server and it worked
Staging and prod run Ruby 1.9.3. A prior gem I pinned was for Ruby 2.1.
We should have our Gemfile.lock checked in so that we can
understand the behavior / differences when bundle install
uses new versions of gems. But, to do this we needed the dev
env to more closely match staging / prod, hence downgrading Ruby
to 1.9.3. I verified that the Gemfile.lock generated here matches
staging/prod.

Note: originally I built this dev env out with Ruby 2.1 b/c the
plan was to start updating / patching all our apps to be on the same
version of Ruby and it just seemed to work. But now we're getting rid of
this web app, so in the meantime, I just want the dev env to work properly
and when things change/fail have them be easy to diagnose / fix.

TESTING:
- rebuilt the container (including blowing away the DB volume) and was
  able to login.
…ions change.

See: https://nickjanetakis.com/blog/dealing-with-lock-files-when-using-ruby-node-and-elixir-with-docker
for an EXACT description of the problem. Now with this change and the checked in Gemfile.lock,
it should be easy to see when a change happens on a rebuild and check that into src
ctrl (plus, it should just work).

TESTING:
- rebuilt the container and verified I can login.
Finally fixing Docker dev env rebuilt/restart issues?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants