I think what I am looking to do is fairly simple - I just can't wrap my head around it.
I've got a repo in AzDo. This repo contains configuration files for firewalls. This is how we manage changes in these configurations.
I've got a simple build pipeline that copies the relevant files and creates an artifact.
I have a release pipeline that gets the files onto the on-prem machine in my Deployment Group. The files show up in c:\azagent\r1\_work\<artifact folder>.
As part of this pipeline I am looking to copy the files from c:\azagent\r1\_work\<artifact folder> to e:\shares\<artifact name>. This is the part that I cannot figure out how to make work.
What strategy could I use to put this together? I've looked into the documentation but it seems like this is somewhat of an edge case (not deploying an app or web site, etc). Ideally, I'd love to do this in a multi-stage YAML pipeline - but from what I've read, it appears as if these do not yet support Deployment Groups. So a classic pipeline is fine for now.
You can add a copy file task(Click the plus sign(+) on the agent job and search for copy files) in your release pipeline to copy the files to a different place on your local machine.
Then you can specify the source folder(ie. $(System.DefaultWorkingDirectory)), and the contents to copy and the target folder(ie. e:\shares\). In below example all contents in $(System.DefaultWorkingDirectory)(ie. C:\agent\_work\r1\a) will be copied to folder D:\Test\New folder
Please check the prefined variables for more information about its map to the local folders.
Related
I am in the process of rebuilding a API documentation site for an open source project where we want to keep an archive of previous releases. I am wondering how I can configure Jekyll to generate the right hierarchy?
We have the following directory layout in our current /docs folder (which we would like to reuse in Jekyll somehow):
current/
v1/
v2/
v3/
Whenever we release a new version the current folder gets copied to a new folder (say v4). The contents of each folder is something like this:
introduction.md
testing.md
api-foo.md
api-bar.md
I'd like these to be available under the url domain.com/v3/testing/, domain.com/current/testing/, etc. I see that I could probably employ collections to do this, having one collection per version. To do this I see myself auto-updating the _config.yml as part of a build script (I made an example doing this here), but I am not sure how to progress from here, or if using collections for this is the wrong approach ...
This is too brief of an update to be of real quality, but thought I would mention that we solved this in the end in the Sinon project. Check out the repo at GitHub sinonjs/sinon and see the docs folder as well as the scripts called from package.json.
Feel free to improve on this answer by editing it and adding content and links.
We have a need to set some directives in the snappy config files for the various components (servers, locators, etc).
The snappy_ec2 scripts do a good job at creating all of the config's and keeping them in sync across the cluster, but I need to find a serviceable method to add directives to the auto generated scripts.
What is the preferred method using this script?
Example: Add the following to the 'servers' file:
-gemfirexd.disable-getall-local-index=true
Or perhaps I should add these strings to an environments file such as
snappy-env.sh
TIA
-doug
Have you tried adding the directives directly in the servers (or locators or leads) file and placing this file under (SNAPPY_DIR)/ec2/deploy/home/ec2-user/snappydata/? The script would read the conf files under this dir at the time of launching the cluster.
You'll need to specify it for each server you want to launch, with the name of server as shown below. See 'Specifying properties' section in README, if you have not already done so. e.g.
{{SERVER_0}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
{{SERVER_1}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
If you want it to be applied for all the servers, simply put it in snappy-env.sh as you mentioned (as SERVER_STARTUP_OPTIONS) and place the file under directory mentioned above.
We could have read the conf files directly from (SNAPPY_DIR)/conf/ instead of making users copy it to above location, but we may release the ec2 scripts as a separate package, in future, so that the users do not have to download the entire distribution.
Flash builder project files can't be opened on another computer even if the files were copied, for e.g. through version control like git or svn.
Importing and Exporting fxp projects is not possible as we do not want to overwrite files for git or svn unnecessarily.
How do people collaborate on Flash Builder projects without creating new project in Flash Builder and having to set up all the settings for the project again and again for multiple collaborators?
If you import the project using its folder location as per #Sean Fujiwara answer then:
One useful way to collaborate in Flash Builder projects is to utilise environment variables. You can access these using - Window > Preferences > General > Workspace > Linked Resources:
From here you can add a new variable or edit an existing one, from the example above you can see that we use a FRAMEWORK_SOURCE variable which points to the source for our shared framework code, we use a swc but this is handy for debugging errors.
We also have another variable called OUTPUT_FOLDER which in our case points to a folder where we run our project over localhost see example below, to use this in a project, you go to right click project name > Properties > ActionScript Build Path, here you enter the folder name you want creating inside the folder that OUTPUT_FOLDER points to:
When you do a Project > Clean from the menu, all resources from your html-template folder will be copied across to this folder and it should open in a browser.
Now we have been able to check in to SVN our .project and .actionScriptProperities files with few issues. When someone new to the project checks them out, they will get an Error in the Problems panel telling them they don't have for example - OUTPUT_FOLDER\MyProjectName, therefore the project leader should have a document listing all the required variables to be setup in your environment.
Other things you can share are paths to raw font files etc.
The only problem I've had with this approach is sometimes it asks for the path to the SDK if it is different from your location, not had chance to figure this one out yet.
Flash builder project files can't be opened on another computer even
if the files were copied, for e.g. through version control like git or
svn.
Flash builder projects can be imported into the workspace just like other Eclipse projects.
Once you copy them to another computer:
Right click in package explorer and go to Import....
Select General/Existing Projects into Workspace.
Select the folder containing the .project directory.
If you make sure Copy projects into workspaces is deselected, you can commit the files directly from wherever you checked the code out.
This is now solved in Flash Builder 4.7 where you can actually import the project folder as is.
I would like to keep two versions of a static html file in my git repository. Both are basically identical, except for links for scripts, media etc (dev version vs. live version).
Right now I keep the dev version in repo, and overwrite the live version values manually on the live machine (=I have local git changes there). I am not happy with this setup, because there's manual labour for each push/pull.
What is the best flow for managing files that cannot be split into config/rest sections (like HTML)?
You could...
Remove the file from your repository and just manually populate it. If it doesn't change very often, this works just fine.
Remove the file from your repository, and generate it from a template via a post-merge script in .git/hooks/post-merge (this hook is run, for example, after git pull).
Name the file after the branch or hostname or some other variable (e.g., static.master.html vs. static.develop.html, etc) and dynamically determine which one to use at runtime.
Those are some ideas. I imagine other folks will contribute additional suggestions.
Expanding on the 2nd bullet point by larsks:
You could keep two copies in the repo (say it were your homepage) index.dev.html and index.prod.html. On the remote, your post-merge script could do something like:
cp -a index.prod.html index.html
or
truncate -s 0 index.html
cat index.prod.html >> index.html
Another problem beside renaming is to keep the content of the both files in sync. So having dedicated files for the same reason only differing in one minor path is a lot of redundncy, if you change one, you have to think on updating the other as well.
OK, you stated that the HTML file is static, but here a line of PHP to generate the difference would solve our problem
Achim
Our build has a variety of generated HTML reports. I would like to have those reported and accessible on the build page, like JavaDoc entries. Is there a generic way to expose these reports without writing a custom plug ins ?
If that isn't available, is there a way to post an HTTP link on the page ?
You can choose "archive the artifacts" and archive for example "reports/*.html"
These will appear under the project page under the heading "Last successful artifacts".
Even if you clear your workspace before each build, these artifacts are moved to a separate directory.
You could also add a build script which will modify or update a file in your userContent directory (since Hudson 1.299), and link to these build artifacts in yet another location.