Dies ist derzeit etwas, das im Pipeline/Multi-Branch-Workflow sehr fehlt. Sehen Sie sich hier ein Ticket an: https://issues.jenkins-ci.org/browse/JENKINS-34395
Wenn Sie sich nicht gegen die Verwendung von Release Branches anstelle von Tags aussprechen, werden Sie das vielleicht als einfacher empfinden. wenn Sie sich entschieden zum Beispiel, dass alle Zweige, die mit release-
beginnen, sind als „Release Zweige“ behandelt werden, können Sie gehen ...
if(env.BRANCH_NAME.startsWith("release-")) {
// groovy code on release goes here
}
Und wenn Sie den Namen verwenden, die nach dem release-
kommt, wie zum wie release-10.1
in 10.1
drehen, erstellen sie einfach eine Variable wie so ...
if(env.BRANCH_NAME.startsWith("release-")) {
def releaseName = env.BRANCH_NAME.drop(8)
}
beide werden wahrscheinlich einige Verfahren weißen Listen, um funktionsfähig zu sein erfordern.
Brad, haben Sie diese Jobs in einem öffentlichen Repo haben, so Ich kann sehen, wie Sie diesen Freestyle-Job umgesetzt haben? –
@JoaquimOliveira Ich habe es nicht in einem Repo und ich kann es nicht wörtlich (Entschuldigung) teilen. Der Freestyle-Job hat wirklich nur eine Hauptsache, in der B Ich habe einen Build-Schritt, um ein Powershell-Skript auszuführen (ich bin in Windows und habe das Powershell-Plugin). Das Powershell-Skript implementiert nur das oben erwähnte Verhalten, führt die git-Befehle aus und überprüft das Tag anhand einer Textdatei und löst dann den Build über eine URL aus. –
Es ist in Ordnung, aber das Problem hier ist, müssen Sie einige Validierung für den bereits ausgeführten Build setzen und nicht erneut für das gleiche Tag auslösen. Aber wann immer es einen Push gibt, löst es einen Build aus und kann nicht kontrolliert werden. Ich möchte Build nur mit einem Schlag eines Tags auslösen. –