I managed to run the scheduler with a cron task.
I managed to auto publish a whole workspace on the publish date with the scheduler.
But I don't want the whole workspace to be published on the scheduler task, but only a single edit.
I tried to give the edit in the workspace a publish date, but that didn't work out.
Is this even possible?
TYPO3 version: 4.5.x
You could create another Workspace for this single edit. And publish this different workspace where you have only one edit.
If you give some more details, perhaps it is possible to do it without workspaces? F.e. you can create two content elements with different start and stop dates.
Related
I'm setting up secondary region for my synapse workspace, is there a way I can export all the triggers from one workspace to another?
You have 3 options, as far as I can see:
set up Git and Devops integration between your 2 workspaces and then set up a release pipeline to copy everything from one workspace to the other. Here is a link to the documentation. This is the best way if you have a lot to copy, and\or want to create a way to copy between environments on a regular basis.
Build a PowerShell script to get information about triggers from one workspace and then create them in the second workspace. Try the commands Get-AzSynapseTrigger to copy from one workspace and Set-AzSynapseTrigger to create on the new environment.
If you have few triggers, simply copying them is the simplest, thought programmatically disappointing solution.
Task Groups are a great way to build a library of commonly executed Build and/or Deployment Actions in Visual Studio Online. Does anyone know of a way to make a copy of (or clone) an existing Task group? I don't see that as an option in the UI anywhere.
I think there is no way to do this yet. It's not even possible on TFS On-premise. Though our TFS professional told us, it should come with TFS2017 Update 1.
Only thing you can do, is select all tasks in your task group and create a new TaskGroup with them. Which is basically the same as cloning the task group itself - it only takes you some clicks more.
Or you could export your task group, change its name and Id in the exported Json, and import it.
Currently there isn't the copy Task Group feature in VSTS and TFS.
You can create TaskGroups according to your requirement and manage them from TaskGroups tab, then use them directly in different scenario. Please follow below steps.
Create a Task Group from Build/Release definition
Navigate to Build&Release > Task Groups
Select the Task Group you need to modify, change the Properties/Tasks
Save the Task Group
If you just want to copy the Task Groups, you can install the "Copy Build Steps" extension. it can copy build/release steps from one definition to another, also support copy the Task Group.
After installing the extension, navigate to the Builds hub > All definitions. A new menu item, ‘Copy build steps’ will be available when you click the ‘’…’’ behind the definition.
To Use a task group:
In a build/release definition, choose Add steps/tasks to open in the Task catalog. Select the category you specified for your task group and find the task group (it displays the name and description you specified when you created it), then choose Add - just as you would with any other task.
I got two solution setting at same location. This two solution are sharing some of the projects along with some dedicated ones.
I have created two separate build definition with gated check in trigger but issue is that when I make any change in one solution it triggers both the build definition.
Can I somehow control the triggering of the build definition based on the solution that I am checking in?
You need to configure your workspace correctly for this to work. Any change in a Build definition's mapped workspace will cause a build to trigger. Due to this, it completely depends on your source control layout, whether it's possible to setup a build that only triggers when something changes that belongs to either solution.
This setup will become very hard to manage quite quickly, as such I recommend you put each set of projects in their own subfolder, that makes it a lot easier.
So ensure that you build definitions won't both trigger, open the Source Settings panel of your build definition and apply a cloak rule to each file or folder by changing "active" in the first column to "cloaked".
To cloak a file you need to enter its full path in TFS, the UI will only offer you a folder picker, but entering a path to a file will work.
These files should:
Not be needed to build the solution
and changes to should not trigger the build.
Do note that the cloak will cause Team Build to not get these files on the Build agent, so it's not possible to have files your build depends on, but not trigger the build when these files change.
You should create gated check-in build definitions per project not per solution.
I'm having a look at the Cloudbees Jenkins Folder Plugin. It looks like it will serve my purposes in allowing me to easily copy groups of jobs but...
When I copy a folder containing some jobs I have to click through Configure / Save for each job in the new folder before the Build option is available. Is this expected behavior?
thanks
Glenn
Yes, when a job is copied it is marked temporarily unbuildable until you save its configuration. This is essential in case the origin job was configured with a build trigger (like building on a schedule): you would not want the copied job to start running until you had a chance to check its configuration and perhaps make changes.
I'm trying to get continuous integration working using Hudson, Maven & Perforce (with an scm poll used to trigger each build)
One of the requirements is to automatically update POM snapshot version numbers following each successful build.
This is trivial using the Maven release plugin, but the act of checking in the newly versioned POMs triggers another build - which continues ad infinitum.
Is there any way of checking in version updates without triggering another build? There doesn't seem to be any way of excluding specific user checkins, specific changelists, or specific files when the scm poll makes the decision to rebuild.
This seems like a basic requirement - been doing it for years using Cruise Control / Ant / Perforce,
Cheers,
Mark
I have been contemplating a move to Hudson, but the inability to exclude specific files from the scm poll would be a deal breaker. Did you also ask this question on the Hudson mailing list?
users <at> hudson <dot> dev <dot> java <dot> net
The only workaround I can see from reading through the docs seems to be triggering builds based on p4 triggers, where you could then programmatically do whatever you want, but that doesn't seem to be a very simple approach.
I don't believe there is any way to configure Hudson to omit part of a Perforce workspace when polling. You may have better luck by setting up two different workspaces - one for build test using a default POM and one for your releases with the auto-updated release POM. The two workspaces could differ on just this one file and modifying the release POM would not trigger a new build.
Check out how to do individual file mapping in a workspace in the P4Guide.
Its possible to update the description of a changelist after it has been submitted, so if you build to a certain changelist number you can then update the description of that changelist to include your build number. This shouldnt trigger a new build.
What is "POM"?
You can have Hudson "Create or Update Label in Perforce" (see near the bottom of your project's configuration.) You could use that along with the BUILD_NUMBER environment variable that Hudson provides, giving you unique build numbers and stamped P4 labels of said build.
I have all tagging, ChangeLog updates, and packaging done by our checked in build code. This allows us to:
Create RC and appropriate tags without starting anther build
Allows us to debug all aspects of our build on any dev machine, not just those with Hudson.
Allows us to exactly recreate how a package, tag, etc was done in at any point in the past.
I had a similar problem checking in compiled src. I was able to find an alternative but i did consider the following.
In hudson specify a child folder of your project to poll. I.e. don't actually have hudson check out your project, just an incidental folder.
Add a shell script to check out your project proper.
Run you normal scripts.
check in your pom. The trick here is that the folder being polled won[t have changed at this point.
Not ideal, but works.
The perforce plugin has had polling masks for a while now. It's in the Advanced section under "View Mask".
Basically, you list a subset of files that you want polling to check for changes. Unfortunately there's no easy way to exclude files, so you'll have to create a list of file specs that specify everything BUT the file you want to exclude. So if the version is contained in a pom.xml, I would need to specify the files and directories that don't contain it.
For example, if your directory structure looked like this:
./pom.xml
./lib/
./src/
You would specify,
//depot/project/lib/...
//depot/project/src/...
as the view mask, and check the checkbox to use it only for polling. There are a few limitations with this feature, such as not being able to use '-' to exclude file specs, but it's still a workable solution for now.