I created a generic repo in Artifactory which I want to deploy my artifacts to.
I'm trying to setup a simple-layout folder structure such as:
I can get this structure only if i'll deploy couple of sub folders.
When deploying I get in Artifactory this structure:
Which is anyoing because I set properties on the build_definition_name level
which I want to read and write to but they are not visible as it now points to
the version folder.
Any suggestion?
Artifactory by default compresses empty folders in the UI.
You can disable it easily by unchecking the following:
Related
I'm trying to set up a git repository for my bespoke WordPress theme builds, using gulp to compile the code but im struggling to understand how to manage the repo.
The outcome I'm after:
Use a separate repo to pull in my gulp workflow. (Could be housed as a submodule)
Offer developers full access to my gulp workflow, src and build.
Push the build folder to remote servers such as production and staging.
Current Scenario
My gulp workflow will be held in a separate repo as it will be used amongst several different builds.
The current workflow I can think of would look like this:
gulp-wp-build -> git repo
src -> git repo
build -> WordPress ready theme not held in a repo
Ideally though I'd like to be able to push my code to the production and staging servers through git and I understand that to do this I'd need to do include the build folder inside of my repo. But would including both my src folder and build folder within the repo be overkill?
I like the idea of containing everything inside of one repo so other developers can work on the theme later down the line using either their gulp workflow or the one I used for the build.
But really in terms of pushing changes through git I'd only want the build to be pushed live so could I separate this build folder from the repo when pushed to a certain remote?
Use a .gitignore file to do that.
create a .gitignore file and inside put the path or the files that will be ignored by git.
relative/Path/to/your/autogenerated/files/*
after you finish, commit and push your file to your remote repository
check this link
What's the proper way to handle having multiple developers on a Meteor application? On each computer that I want to develop the app on I have to follow these steps to get it running after cloning from the repo:
Rename my-app/ to app/
Run meteor create my-app
Move all files from app/ into my-app/
Delete the auto generated my-app.*files
Re-add all packages (jquery, iron:router, etc...)
Note that I'm not including the .meteor/local directory in the repository.
I feel like I'm missing something obvious but it's not making itself apparent.
Push to the repo all files at the same level as the .meteor directory. Nothing to rename or meteor create. Yes, packages do need to be added, but the list of packages is specified in a file inside .meteor.
Just include the full .meteor/ directory in your repository. That way whenever the repo is cloned they will get the right version of meteor, a list of all the installed packages (which are downloaded at runtime) and any settings they need to run the app.
As far as I'm aware there is nothing in the .meteor/ directory that can't be shared across to different developers.
My team has is working on a git repository which contains a fully deployable Wordpress app. This was configured in this way so that it could be deployed to a AWS stack quite easily. The repository contains a caching plugin which creates two folders in the wp-content/ folder named
cache/
w3tc-config/
When devs are checking out this application they are removing the caching features for development and thus the plugin is writing these changes to the two directories it uses. Which then encourages .git to stage them for a commit.
Is there anyway we can ignore these folders on dev machines but not remove them from the repo? Also i'd be interested in hearing other solutions which might help me get round this problem even if it is a larger change.
If you check out your repository and let master follow that, then you can create a devel branch where you just add cache w3tc-config to .gitignore.
I do something similar at work where I use git-svn to work with a svn repository which "links" in another svn repository for a sub module. Git clone did not fetch that sub module, so I just copied in the content from a svn checkout, checked into a devel branch (leaving master following the svn trunk branch), and added the sub module directory to .gitignore.
This is a solution that will require specific action from each developer, and not something you can push out from the repository. But similar to git hooks, if you create a tools/do_it.sh script that does the required actions it is possible to lower the bar considerably.
You cannot have it both ways. Either the files are tracked or they are not. You cannot keep files in the repository but avoid tracking changes to them. Once they are tracked, it is up to you to not git add them. (And it is worth noting that git does not track folders ever.)
Create an archive called UnzipMeRightAfterCloning.zip that contains all the stuff you want ignored. Anyone cloning the repo needs to extract that archive, and it will add all the files/folders blocked by your .gitignore settings. (And given your current setup, you will have to untrack the files in those folders first.)
Put these in your .gitignore file. (Do not put in asterisk.)
cache/
w3tc-config/
Yes, create a local .gitignore file in the project directory.
in the file paste the following
cache/*
w3tc-config/*
Now, these files will be excluded from git, but they won't be removed from the repository.
I am attempting to setup Team City for CI on my project. We currently have 9 developers working on the project and using Mercurial for source control. Right now all web.config files are ignored in the main project repo and the web.config files are located in a separate repo so that we do not have to use a dozen transforms.
How can I configure Team City/MS Build so I can checkout both repos (have this working so far) and then update the repos and copy the web.config to the main project folder before doing the build?
What you actually want to do is:
Each developer has his own web.config, but you want the build to use the same "central" web.config each time and ignore the developers' own web.config versions.
Correct?
If yes, I would do it a different way:
You can let the developers use their own web.config files by default, but still put the "central" web.config into the main project repository with a different file name (for example, web.config.build.
Then you can use BeforeBuild (in the .csproj file) in a way so that it will be automatically copied to web.config when there is no web.config file present (which should be the case on the build server, but not on the developer machines).
Read this answer to see how I'm doing something similar:
how to ignore files in kiln/mercurial using tortoise hg “that are part of the repository”
You can create a second VCS root and have it 'merge' files in your checkout on the teamcity machine
create a second VCS root in teamcity
append ignore rules to match only your *.config file as needed and place it in the correct folder
example ignore pattern from the top of my head:
-:*
+:web.build.config=>website/
But i would suggest you follow the approach of Christian Specht because when you have a web.example.config which you copy to web.config on pre-build event you are able to modify it with new settings. This will get picked up easily by teamcity because you can have it 'clean' the directory (with Swabra) to remove the 'old' web.config file and get it re-copied from the (new) web.example.config
I'm using Microsoft Web Deploy to publish and update my site. (script is generated with Visual Studio). This tool removes auto-generated files and folders on update, as they are not included into install package. How to make it keep these files?
The Web Deploy command line tool has two switches that may be useful: -skip and -enableRule:DoNotDeleteRule. For information on -skip, see Web Deploy Operation Settings, and for DoNotDeleteRule, see Web Deploy Rules.
In Visual Studio, you may be able to tweak the deploy.cmd file to use these to achieve what you want. For more information, see How to: Install a Deployment Package Using the deploy.cmd File.
Having to edit the deploy.cmd files each time you generate them is a pain. I am using VS2017 and found I can set an environment variable on the server and deploy.cmd will use it. The deploy readme file says it:
Alternatively, you can specify additional flags by setting the
"_MsDeployAdditionalFlags" environment variable. These settings are
used by this batch file.
So on the server I created the environment variable:
_MsDeployAdditionalFlags=-enableRule:DoNotDeleteRule
And that did it. It now adds the rule each deploy on the server.