I thought ivy:info task would do the job by...
<ivy:info file="${local_ivy_file}"/>
<ivy:info organisation="${ivy.organisation}" module="${ivy.module}" revision="${ivy.revision}" property="check"/>
But even when the artifact does not exist on the repo, the properties of "check" (check.organisation, check.module, check.revision) always returns the same values as that of ivy.organisation, etc... when the expected values of "check" properties should be null (since they don't exist on repo)
Am I missing something?
Why this is needed:
I have a large set of third party jars to upload, but i do not have admin rights to overwrite (and should not overwrite) if file exists.
Doing
<ivy:publish overwrite="false"/>
will break the entire process whereas I need the task to continue cycle through the whole set of jars/ivy.xml.
Thanks
i found my problem. my original method does work, except that i have to remove the ivy cache before running the info task, since ivy looks in the cache before looking in the repo.
<delete dir="${ivy_cache_path}"/>
<ivy:info file="${local_ivy_file}"/>
<ivy:info organisation="${ivy.organisation}" module="${ivy.module}" revision="${ivy.revision}" property="check"/>
now ${check.revision} correctly captures the revision of the artifact in the source ivy file if the artifact exists in the online repo, and has no value if it does not exist. I can use this as a condition for the subsequent tasks.
Related
I am using TeamCity as build server and have a little trouble when configuring projects and their dependencies.
Eventually I want to get the checkout directory of project dependencies to configure certain build steps. For that I have the variable %teamcity.build.checkoutDir% for the checkout directory of the project itself.
However, I did not find something like %dep.<dependencyID>.teamcity.build.checkoutDir%.
Is there a way to get the checkout directory of a dependency?
You can add a parameter (say checkoutDir ) in the first build whose value is equal to %teamcity.build.checkoutDir% . You can then fetch this value in the dependent build (either through snapshot or artefact dependency)
I am using this myself and I can access my dependent Build's Checkout directory with...
%dep.<dependecyID>.teamcity.build.default.checkoutDir%
I believe this will only work with a Snapshot Dependency though
So the problem is that all developers need different settings for their local testing, but the settings file is part of the project (unlike the nbproject folder for example that we all ignore). I know about .htignore, but the filter only applies to files that are not part of the project.
If I forget the file, then this removes it from the "global" repository, where we have a "holder" version of the settings file.
Right now we just don't commit that file, but every now and then somebody forgets and pushes his own settings, which then are synced back to other developers and it's a constant pain. We just want to "automatically" not push that file. Is there a solution to this? Are we doing something wrong?
You could add a precommit hook that gives an error every time you try to commit this particular file.
To handle the case of developers that forget to setup such a hook, you can also add a serverside hook that will reject their push.
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
I've searched awhile for this and haven't seen anything. Which could mean, it's not supposed to be done or it just can't be done.
I looked at a list of hooks for mercurial and I could not seem to find (or get one working) that executed a script after you give the hg pull command.
Thank you
From the hgrc docs section on "hooks" -
"incoming"
Run after a changeset has been pulled, pushed, or unbundled into the
local repository. The ID of the newly arrived changeset is in
"$HG_NODE". URL that was source of changes came is in "$HG_URL".
or...
"post-<command>"
Run after successful invocations of the associated command. The contents
of the command line are passed as "$HG_ARGS" and the result code in
"$HG_RESULT". Parsed command line arguments are passed as "$HG_PATS" and
"$HG_OPTS". These contain string representations of the python data
internally passed to <command>. "$HG_OPTS" is a dictionary of options
(with unspecified options set to their defaults). "$HG_PATS" is a list
of arguments. Hook failure is ignored.
(The documentation also goes into detail about what the config should actually look like and how hook scripts are called.)
We are in the process of switching to Mercurial. Our repository has a number of different projects, so we are using the filtered source control so that only changes to a project’s files trigger a build. I’m seeing in my ccnet.log that CruiseControl is correctly grabbing the modification list from Mercurial, but it always reports "No modifications detected." I think I might be specifying the wrong or an incorrect pattern.
This is what I see in the log:
2010-08-12 18:25:41,305 [BuildAndTools:DEBUG] Modification Modification: (Type=Changeset,FileName=Build/App.targets,FolderName=,ModifiedTime=8/12/2010 6:16:42 PM,UserName=user,ChangeNumber=5640629ec7b5,Version=5640629ec7b5,Comment=Making a change to see if it triggers a build.,Url=,IssueUrl=,EmailAddress=user#example.com) was not accepted by the filter specification.
2010-08-12 18:25:41,305 [BuildAndTools:INFO] No modifications detected.
And this is the path filtering configuration:
<sourcecontrol type="filtered">
<dynamicValues />
<exclusionFilters />
<inclusionFilters>
<pathFilter>
<caseSensitive>False</caseSensitive>
<pattern>Build\**\*.*</pattern>
</pathFilter>
</inclusionFilters>
</sourcecontrol>
What do I need to do to get CruiseControl.NET to see a modification?
Update: This issues was fixed in CruiseControl.NET version 1.6.
It turns out this is a bug in the Mercurial source control plug-in. It gets changes by changeset, instead of by file (all the files in a changeset are grouped together into a space separated list). This is not the format the filtered source control provider works, so it never notices any modifications.
I fixed the issue, created a JIRA item to track the issue, and attached my code changes to it.