I was upgrading virtualenv for good measure in 4545fc1da1488bb1623de82ad19f78702bd6df62, but didnt foresee it causing problems. I was wrong. Worked for everything except Trusty builds.
Steps taken:
$ make docker-compose-test
Create /root/.config/zanata.ini (Obtained from https://translate.engineering.redhat.com/dashboard/settings/client)
Update .pot files:
$ make pot
$ make languages
Push to Zanata:
python tools/scripts/manage_translations.py push --both --lang es
These macros were intended to pull the version and release from a python file if they werent passed in with --define, but /usr/bin/python is not available at this point in the build process. I'm not sure when or if this ever worked. Perhaps before we were using mock.
This approach also works for our Brew builds, as we cannot specify a macro value at build time.
This looks pretty hairy, but essentially it's just re-invoking `pip download` with `--no-deps` so that I can record the name of the local archives that are created.
I had to pull the git urls out of the main requirements files because in order to install offline (--no-index), we need pip to install from local package archives rather than cloning repo.
The weird `cat` thing going on in the Makefile is because we need to install everything as part of a single `pip install` transaction. Without this, installing only requirements_git.txt will result in dependencies getting unintentionally updated.
These packages were getting silently updated, making vendoring these dependencies difficult.
This ensures that the expected versions of these packages are installed in the virtualenvs.
For some reason -I wasn't cutting it. Even though we were trying to install pip 8.1.2, this was happening:
Collecting pip==8.1.2
Using cached pip-8.1.2-py2.py3-none-any.whl
Installing collected packages: pip
Successfully installed pip-9.0.1
¯\_(ツ)_/¯
I know, this sucks. I spent all day trying to get to the bottom of the CI failures that started happening the other day with no luck.
There is something going on with how we were moving the node_modules directory into the source tree from the pre-built location in /tmp. This was working, but then it broke. I hope to cycle back on this sometime next week if I have the time.
I know, this sucks. I spent all day trying to get to the bottom of the CI failures that started happening the other day with no luck.
There is something going on with how we were moving the node_modules directory into the source tree from the pre-built location in /tmp. This was working, but then it broke. I hope to cycle back on this sometime next week if I have the time.
Chromium and WebKit based browsers have the window.navigator.languages attribute, which is an ordered array of preferred languages as configured in the browser’s settings.
Although changing the language in Chrome results in an Accept-Language header being added to requests, window.navigator.language still returns the language specified by the OS.
I’ve tested this with Firefox, Chrome, IE 11, and Edge.
Connect #5360
- Renamed npm scripts to reflect what they are actually doing. Nothing is being built here!
- Not sure why the default django_host was 0.0.0.0…
- Removed unnecessary logic from build-docker-cid
This file was originally generated with a version of NPM that was affected by a bug that would cause `npm install` to fail on non-macOS systems. We were temporarily forced to downgrade to 3.10.7, but…. this fixes that! Verified on macOS Sierra and CentOS 7 using NPM version 3.10.10.
A couple reasons for this:
- The command for generating the API l10n files is currently broken, and I want to get the translation folks looking at the UI ASAP.
- These things require different environments:
- Generating the UI files requires Grunt, which is only available *before* packaging. We generate the static files before invoking mock or pbuilder.
- Generating the API files requires Django, which is only available inside the virtual environment. This will likely need to be invoked somewhere inside of the install playbooks.
Shane McDonald