I'm trying customizing the webstatus templates for my buildbot 0.8.8 installation
According to the documentation:
Buildbot uses a templating system for the web interface. The source of these templates can be found in the status/web/templates/ directory in buildbot's library area. You can override these templates by creating alternate versions in a templates/ directory within the buildmaster's base directory.
Here what I did:
copied all html templates from my buildbot installation folder (/usr/lib64/.../status/web/templates) into the templates folder I found inside my buildmaster installation root folder (the templates was already there, and it contains a README file that seems to confirm what the documentation states)
modified the root.html templates
Unfortunately I cannot see any changes in the webstatus page.
Another test I did is to directly change the original template file in the buildbot installation path. The changes are now displayed. It seems like the buildmaster is not "seeing" the new template in the local configuration path.
I checked the file/dir permissions and I cannot spot any issue on that side.
Tried cleaning up the browser cache without luck as well.
Have I done something wrong?
As per source code, templates are retrieved from the WebStatus objects, i.e.
builder.py:573 ([1]) :
template = req.site.buildbot_service.templates.get_template("builders.html")
This property is created in baseweb.py:465 ([2]) :
self.templates = createJinjaEnv(revlink, self.changecommentlink,
self.repositories, self.projects, self.jinja_loaders)
The template lookup algorithm can be found in createJinjaEnv function, around base.py:506 ([3]) :
all_loaders = [jinja2.FileSystemLoader(os.path.join(os.getcwd(), 'templates'))]
if jinja_loaders:
all_loaders.extend(jinja_loaders)
all_loaders.append(jinja2.PackageLoader('buildbot.status.web', 'templates'))
loader = jinja2.ChoiceLoader(all_loaders)
As per documentation [4], jinja will return the first existing file in specified list, so while trying to load your template, Jinja will lookup sequentially in :
cwd
jinja_loaders property, that can be defined in WebStatus constructor by jinja_loaders param in your master.cfg
files from python package
IMO the easiest option is the second.
Hope it helps
[1]https://github.com/buildbot/buildbot/blob/2ab0e16ed0c46249f1d33308fd6878a1fc953f6e/master/buildbot/status/web/builder.py#L573
[2]https://github.com/buildbot/buildbot/blob/2ab0e16ed0c46249f1d33308fd6878a1fc953f6e/master/buildbot/status/web/baseweb.py#L465
[3]https://github.com/buildbot/buildbot/blob/2ab0e16ed0c46249f1d33308fd6878a1fc953f6e/master/buildbot/status/web/base.py#L506
[4]http://jinja.pocoo.org/docs/dev/api/#jinja2.ChoiceLoader
Related
I start using Github 2 days ago, and it's in a private repository.
So I with my friend (I appointed him as Collaborator) working a project together, but what is the best setting for .gitignore file when you're working with a team?
Because what I'm thinking is, if Github ignore file such as .env (the app key) & /vendor, the program wouldn't work as what it must to be right?
for now I using the default setting of .gitignore files.
/node_modules
/public/hot
/public/storage
/storage/*.key
/vendor
/.idea
/.vscode
/.vagrant
Homestead.json
Homestead.yaml
npm-debug.log
yarn-error.log
.env
Please help, I already search about it but I can't get the answer.
It is easier to start with the recommendation form gitignore.io.
See gitignore.io/api/laravel
Laravel
/vendor
node_modules/
npm-debug.log
# Laravel 4 specific
bootstrap/compiled.php
app/storage/
# Laravel 5 & Lumen specific
public/storage
public/hot
storage/*.key
.env.*.php
.env.php
.env
Homestead.yaml
Homestead.json
# Rocketeer PHP task runner and deployment package. https://github.com/rocketeers/rocketeer
.rocketeer/
Note that ignoring folders should be specified as aFolder/, with a trailing slash.
Any folder with generated content should be ignored.
If vendor/ is *not generated (but includes sources that you need to compile), then you should not ignore it.
I'm learning Aurelia via the TypeScript / ASP.NET Core skeleton navigation app. Everything runs fine in its default state. To test the exported production bundle, I run the Gulp Export task, then publish the app via Visual Studio project publish to a local folder, then replace the published wwwroot folder with the wwwroot folder from within the "export" folder, then use dotnet from the command line to run the app.
Things break if I have any source modules in a subdirectory. For example, I moved the welcome.ts/html component files into "/src/Pages" and adjusted its route moduleId in app.ts accordingly to "./pages/welcome". The unbundled app then still runs up fine, but when I try the exported version, I get a request being made by SystemJS to http://localhost:5000/dist/pages/welcome.js which 404s (as you'd expect).
I can see the contents of the welcome component in the app-build.js file, and the config.js file within the export folder contains the expected file paths, i.e. it has "Pages/welcome...".
I have read this seemingly similar issue:
https://github.com/aurelia/bundler/issues/131
But setting depCache to false made no difference in my case. Why is SystemJS trying to load this module separately from outside of the bundle?
I was able to reproduce this error locally.
Presuming that you have a Windows environment, it will be a case-sensitivity issue.
After renaming [P]ages folder to [p]ages, bundled version works as expected.
On the filesystem there is a [P]ages/welcome.js viewmodel, but [p]ages/welcome has been defined as moduleId.
Unbundled mode: Windows filesystem is case-insensitive, which behaviour can be misleading by loading [P]ages/welcome.js correctly.
Bundled mode:
Based on file path, bundling process embeds[P]ages/welcome.js as [P]ages/welcome module.
But, according to the route config, SystemJS will be looking for [p]ages/welcome module within app-build.js.
My recommendation would be to use lowercase folder/filenames whenever it's possible.
I want to deploy some front end assets to the local web root of a site using file replacement. I can't seem to get it to work with a relative path in the target location field though. Is it possible to do this though tds or should I use a post build event instead?
The reason these assets aren't included in a project is that they are part of a third party solution but we still want this tracked in source control to try to make the project setup easier.
Most developer machines will be set up the same way for this project with the same file structure but I think it's a little more flexible if I can make the target a relative path so I don't need to worry about differences like drive letters and such.
The folder structure is as follows:
repo
folderToCopy
sitecore
webroot
I have tried the following using ..'s based on what tds changed my source location to be while using the "Make selected Source Location relative" option (changed it from an absolute path to ..\folderToCopy\):
../../Sitecore/Website
/../../Sitecore/Website
..\..\Sitecore\Website
\..\..\Sitecore\Website
From my understanding, TDS does the file replacement based on the files published from the associated Website project.
You can then have relative replacements such as the following:
<Replacement Include=".\assets\folderToCopy\myFile.txt">
<TargetPath>.\assets\targetFolder\myFile.txt</TargetPath>
<IsFolder>False</IsFolder>
<IsRelative>True</IsRelative>
</Replacement>
I have not been able to successfully get TDS to use the file replacement with files that are in source control but not in the project.
My suggestion would be to set up a build event that will copy these files to the correct location, or to create a nuget feed for them and pull them in as nuget references.
In TYPO3, Version 6.1.5, I'd like to split my configuration in typo3conf in three parts:
One part generated by the install-tool, under version control.
One manually managed part, under version control.
One manually managed part, containing server specific stuff, not under version control. Contains e.g. database credentials.
I've tried to do it like this:
is done using LocalConfiguration.php,
is done using AdditionalConfiguration.php
is done by and additional file, included by the AdditionalConfiguration.php.
This does not work, as it seams that the files are evaluated in this order:
LocalConfiguration.php
AddtitionalConfiguration.php
LocalConfiguration.php
So the changes from my server specific file (and AdditionalConfiguration.php) are simple overwritten by the stuff from LocalConfiguration.php.
Any idea how to get around something like this?
First: don't apply any manual changes in your: LocalConfiguration.php file as it will be removed after each operation in the Install Tool, Extension Manager etc.
For adding custom configuration, you should use AddtitionalConfiguration.php file which isn't changed (as probably you know while you are using it). In this additional conf you need to use 'old' syntax for overwriting values, ie:
<?php
$GLOBALS['TYPO3_CONF_VARS']['DB']['database']='some_db_loc';
$GLOBALS['TYPO3_CONF_VARS']['DB']['host']='localhost';
$GLOBALS['TYPO3_CONF_VARS']['DB']['username']='jost';
$GLOBALS['TYPO3_CONF_VARS']['DB']['password']='yourpass';
finally at the end of the additional conf use common include() for including next PHP file in which you can overwrite these values again:
#include('jost_localconf_dont_commit.php');
At least in TYPO3 ver. 6.1.1 this scenario works like a charm.
EDIT: also take a look at Viktor's answer according to accessing the properties in additional config.
BTW: I'm not really sure why you need to commit AdditionalConfiguration.php , IMHO it should be ignored in the git, and on every environment it should have this file filled with local data typical for this env. Main (production) instance should keep whole its config in LocalConfiguration.php
Just one things to add to biesior's answer:
For security reasons, it is even better not to have the DB credentials in AdditionalConfiguration.php. It's better to include a PHP file with the credentials from a path that is outside the document root of the host. Therefore if PHP doesn't work properly, the file cannot be downloaded and the DB credentials are not exposed.
I am trying to automate deployments of a particular project and a bit lost as to who to handle config file as well as user assets.
(Application is based on Zend Framework based btw).
Main application folder is structured as follows:
./app
./config.ini <----- config file
./modules
./controllers
./models
./views
./libs
./public
That config file is where all the configs are stored.
So 'app' folder contains whole bunch of code in PHP and 'public' contains whole bunch of code in JavaScript, HTML/CSS and stuff like that(web accessible basically).
If I follow Capistrano's model, where each package is expanded into it's own folder that is then symlinked to, how do I handle that config.ini file?
What about all the user content that is uploaded into ./public folder?
Thanks!
The Capistrano approach to this is to have a structure like this on your remote server:
releases/
20100901172311/
20101001101232/
[...]
current/ (symlink to current release)
shared/
in the shared directory you include your config file and any user generated content (e.g. shared/files). Then on each deployment, once you've checked out the code you automatically create symlinks from the checkout into your relevant shared directories. E.g.:
releases/20101001101232/public/files -> shared/files
releases/20101001101232/application/configs/config.ini -> shared/config.ini
that way, when a user uploads a file to public/files it is actually being stored in shared/files.