We are using Cloudbees dev#cloud service, and are looking to create a number of application based off of an archetype stored in Github. I would like to create a custom ClickStart in order to streamline the process.
We are currently forking the archetype, then using a Folder Template that I have created to provision a build pipeline for the application.
While I have been able to create a simple ClickStart, I would like to create one that:
Forks or copies the clickstart source into a Github repository, and not cloudbees forge. The GitHub API supports this.
Point to my folder template using the Jenkins XML API. Currently, not all attributes of a folder template are represented in the rendered XML.
Target a specific folder to create my new folder job under.
The ClickStart API and JSON doesn't seem that well documented, and I have gotten about as far as I can go with trial-and-error.
Is what I am looking to accomplish possible with the current state of the Clickstart API?
Forks or copies the clickstart source into a Github repository
I do not believe this is possible today. Certainly it has been proposed.
not all attributes of a folder template are represented in the rendered XML
Such as what? The config.xml of a folder, just like that of a job, should be definitive. (It does not include definitions of child items.)
Target a specific folder
Also not possible today that I know of. (Though the user of the ClickStart could always move the result into a subfolder after the fact.)
Related
I have a dropwizard API app and I want one endpoint where I can run the call and also upload and image, these images have to be saved in a directory and then served through the same application context.
Is it possible with dropwizard? I can only find static assets bundles.
There is similar question already: Can DropWizard serve assets from outside the jar file?
The above module is mentioned in the third party modules list of dropwizard. There is also official modules list. These two lists are hard to find maybe because the main documentation doesn't reference them.
There is also dropwizard-file-assets which seems new. I don't know which module will work best for your case. Both are based on dropwizard's AssetServlet
If you don't like them you could use it as example how to implement your own. I suspect that the resource caching part may not be appropriate for your use case if someone replace the same resource name with new content: https://github.com/dirkraft/dropwizard-file-assets/blob/master/src/main/java/com/github/dirkraft/dropwizard/fileassets/FileAssetServlet.java#L129-L141
Edit: This is simple project that I've made using dropwizard-configurable-assets-bundle. Follow the instructions in the README.md. I think it is doing exactly what you want: put some files in a directory somewhere on the file system (outside the project source code) and serve them if they exist.
How can I share (or publish) a flohub graph like is done in this answer?
I need to be able to post a publically accessible project, and am willing to set up a server if needed.
Examples indeed only support a single graph for now. If your example uses subgraphs or custom components and is targeting NoFlo on the browser, another nice option is to make a public HTML build of it and host it somewhere (for example GitHub pages).
The noflo-browser-app repository has build automation setup for this, including pushing to GitHub. To use it, you need to do the following steps:
Fork noflo-browser-app
Set your project to use your forked repository path in project settings on Flowhub
Push your graphs and components to GitHub
Share the live mode URL
To make the automatic publishing of app builds to GitHub Pages work, you need to enable the project in Travis CI and provide a GitHub access token via the GH_TOKEN secure env var.
Also remember to tweak the component.json file to include whatever custom component libraries you need.
noflo-browser-app bundles the WebRTC runtime, so it should be quite easy to access.
Sharing is somehow magically implemented through github gists. This works with graphs using ONLY the built-in components. Here's how you do it:
create a github gist
copy the json for the graph you want to share and paste them into the gist. my main.json, for example.
name the gist file noflo.json (not sure if this is required)
copy the gist's id from the url, in my case it is ecf36f449034209b8c2e
form your share link like this https://app.flowhub.io/#example/<yourGistId> here is mine
This only works for projects which use standard components. This issue is tracked here
I am trying to understand the templating system. There is a /templating directory with following README:
It is not advised to make local modifications to those files after installation, as they might be lost during the installation of a new Trac version.
As an alternative, you can copy the templates you want to modify and place them in the templates/ directory of your Trac environment or in the location specified in the trac.ini file under the [inherit] templates_dir setting (the former having precedence over the latter).
This would be nice - I could have templates for my project nicely separated in the same path as my project. But this directory contains only part of the templates and for example ticket templates modification is impossible within this path.
So what is the correct way to modify Trac templates?
Thanks!
It is discouraged in general, because local/custom templates take precedence, and this could come in the way, if upstream releases have significant changes. You'll never get warned about a changed template and you'll have to re-base your template customization on-top of each new template.
Anyway, start from a fresh template copy from source. Templates are to be found in sub-directories templates of the respective Trac realm (i.e. ticket/templates, versioncontrol/templates, wiki/templates) and put it to all directly into <env>/templates (initially empty) or for reusing them in multiple Trac environments as per your [inherit] configuration.
Since Trac-0.11 Trac uses the Genshi template engine. See it's own wiki documentation about the available syntax.
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.
I created several web applications that use the same static files (css, js, images).
When I use svn for version control, I use an external repository (svn: externals) to add files to the current project.
For example:
- Project_1
---- Webapp
-------- Static (external to static's repo)
- Project_2
---- Webapp
-------- Static (external to static's repo)
I could easily use it in their web pages by adding a link like /static/ ...
But now our company has moved to perforce.
How can I support the current structure?
We also use maven, I think to pack these files as a jar and use as a dependency, but then my editor (idea) does not see that this dependence are js-scripts and styles.
And i need to repackage and deploy jar file when create minor changes.
How to use maven correctly?
Perforce has support for defining multiple mappings from the depot to your hard drive as part of the client spec. You could, for example, set the following:
Client Name: Sample_Maven
Client Root: c:\inetpub\wwwroot
//depot/Project_1/Webapp/... //Sample_Maven/Project_1/...
//depot/Project_2/Webapp/... //Sample_Maven/Project_2/...
//depot/Shared/static/... //Sample_Maven/static/...
... any other folder mappings you need to bring in and sync ...
Perforce won't handle multiple mapping of the shared static folder situation by itself, you will have to use junctions/symlinks in your file system to get the behavior you want. A word of caution though, make sure only one of the shared static folders is actually managed through Perforce. It can get slightly grumpy if resources get changed out from under it without it knowing about the changes.
Really though, you are probably better off (if you can) - having a single workspace/client spec per project - one for proj1 and one for proj2, each with their own mappings to the shared static folder. If you can structure things appropriately and just use maven to build each "project" things will go more smoothly.
For a Maven based solution, you could use WAR Overlays, sharing common resources across multiple web applications is exactly what overlays are for.
It seems you have a couple of choices, both called overlays:
a) Maven overlays as #Pascal suggests. Then you a struction like #Goyuix suggests to checkout the static content from Perforce.
b) Perforce overlays, which would allow you to have two different workspaces/client specs, one for each project, and in each import the static content into the expected place in the filesystem. This is the closest match to the subversion structure you were using before.