I have a VCS trigger which starts build each time a new commit in specific branch is detected. But sometimes I want one of steps to be skipped. I decided to add a specific keyword to such commits.
I tried to use template and two configurations (one with step enabled and another with disabled) but there is no possibility to modify VCS Trigger properties in derived configurations. Also I can't add a second VCS Trigger neither to the configuration nor to the template: when I click "Add" there is no VCS Trigger in list.
How can it be done?
If you have template then you can replace VCS trigger rules from hardcoded values with some parameter, e.g. %TRIGGER_RULES%. And in each build, that uses this template you could easily override this parameter for your needs. This should give you possibility to make something like
-:comment=.*do-not-trigger.*
But if you would like to skip only one step, then in this case you have to create some custom script for it and check commit message in it. The behaviour of build is simple: either build is executed and all steps are triggered, or build is not executed at all.
Related
I'm currently trying to build a reusable workflow where the reusable workflow is correctly setup with an on: workflow_call trigger and so forth.
When I'm calling the workflow though, I need to be able to dynamically populate the shared workflow file reference with the current branch or commit. I'd also like to populate the organisation and repo dynamically as well if possible with the current org/repo, but that's less essential. My call to the other workflow therefore looks like this:
jobs:
call-build-and-test:
uses: ${{github.repository}}/.github/workflows/cicd-build-and-test.yml#${{github.sha}}
Unfortunately however the two context variables, github.repository, and github.sha don't get evaluated and the workflow fails at runtime stating that a valid organisation and repo are required at the start of the string, or, if the organisation and repo are hardcoded so that they're valid, then it states the commit couldn't be found because that's not evaluated correctly either.
Can anyone explain why the context variables aren't getting evaluated? If this is not possible how can I dynamically populate these values? It's not sufficient to hardcode them as they need to execute against the version on the current branch, as the main branch has not had workflow merged in yet, so can't simply be hardcoded to that as in the examples in the Github docs here:
https://docs.github.com/en/actions/learn-github-actions/reusing-workflows#calling-a-reusable-workflow
I believing using context variables such as github.* is the right approach, as environment variables are only available within the scope of a shell executing a job, however I have also tried environment syntax as well, i.e. GITHUB_REPOSITORY, and GITHUB_SHA with the same problem.
It can't be done at the moment as Github Actions doesn't support expressions with uses attributes.
There is no workaround (yet?) because the workflow interpreter (that also checks the workflow syntax when you push the workflow to the repository) can't get the value from the expression at that moment.
It could maybe work if the workflow was recognized by the interpreter, but it doesn't event appear on the Actions tab as it's considered invalid.
For the moment, you can only use tag, branch ref or commit hash after the # symbol, the same way you use any action. Therefore, this has to be hardcoded at the moment.
As GuiFalourd says:
It can't be done at the moment as Github Actions doesn't support expressions with uses attributes.
If you just want to use the ${{ github.sha }}, and you only need the workflow from your local repo, don't specify the ref. As shown here:
If you use the second syntax option (without {owner}/{repo} and #{ref}) the called workflow is from the same commit as the caller workflow.
call-workflow-2-in-local-repo:
uses: ./.github/workflows/workflow-2.yml
You can find more info here.
Unfortunately I can't find any information on whether they are planning to support this one day.
I am also facing this issue when calling a build workflow from a deployment workflow. I think the solution for me is to pass the branch as a param to the reusable build workflow and checkout that branch if it's specified. I am just going to have to accept that I'm not using the workflow file from the branch specified.
I appreciate I'm late with this and it's a very specific scenario, but hope it may help you in some way!
i have a bitbucket classic build pipeline and i need to have the ability to set the build clean option at queue time. it seems like this used to be possible via the Build.Clean variable but that has since been deprecated.
When editing a build pipeline the Clean option uses an editable drop down but anytime you try and type something, it erases what you just wrote. i would like to set this option to a variable like $(CleanBuild)
Assign build clean option at queue time
Indeed, the variable Build.Clean is already deprecated. But the document Use predefined variables provided another variable Build.Repository.Clean, which will help us to clean the Sources:
Besides, if you want to clean other options fields, like All build directories:
I do not believe there is a way to assign the clean options at queue-time. Even if we use deprecated Build.Clean variable, we still can clear Sources only.
You could check the similar thread for some more details.
Hope this helps.
We use the option on build definitions to automatically create a bug upon build failure, which is awesome... until we set up to use separate teams within the project, for different focuses (e.g. BI / Client / Server), as they are separate teams, they have their own iterations.
Whenever a bug is being automatically created, it is being assigned to the build initiator (yay!), and it is being automatically assigned to a current iteration, but it is assigning to an iteration for a team the build initiator is not in (boo!)
I'm assuming that I can force Iteration by using the "Additional fields" options within the build definition, it's unclear if the iteration path can be set here (or if it can, how)? - From what I can see in the documentation on work item fields implies the iteration path is read only?
I'm assuming that I can force Iteration by using the "Additional fields" options within the build definition, it's unclear if the iteration path can be set here (or if it can, how)?
You can use the additional fields System.IterationPath to specify the iteration path for the bugs rasied on a failed build:
After build failed (My current iteration is MyTestProject\Iteration 1):
Hope this helps.
I'd like to create a branch restriction for a ClearCase preop merge trigger.
However, it should fire based not on the exact branch type, but rather
based on whether the branch type follows a specific naming convention, like
.../my_special_branchname_prefix*
Can I do this, or do I have to list every branch separately?
I read in "cleartool man mktrtype" that a "branch-type-selector" can be used,
but unfortunately I was not able to find comprehensive information on what
it entails, i.e. if it can be a version selector pattern as used in a config spec (using e.g. the three-dot ellipsis), or even a globbing pattern, or if it
can only be an exact branch type name.
One way to check what you can do is to write a dummy preop trigger script which will simply output the "trigger environment variables (EV)"
That way, you can check if one of those CLEARCASE_xxx environment variable has the name of the branch you want (do you mean the source or destination branch of that merge?).
Once you see the right variable, you can enforce your policy, by making sure the preop trigger script exits with -1 when the name of that branch does not start with the expected prefix.
We use ClearCase where I work and I'm trying to figure out how to find any files that have been modified but not merged up. We have a main branch at the very top level in ClearCase, and this is where the final source code changes are merged to and where we do our formal release builds from. We then have an integration branch under main where integration issues are worked out. When we get everything working and tested in the integration branch, we merge the integration branch up to main. For individual feature implementations and bug fixes, we create a new branch (usually named after an action, feature, or bugfix) off of the integration branch and work the issue. When we are done with it, we merge that change up to the integration branch.
I was wondering if anybody knew of a command or a way to see what files are modified in the feature/bug fix branches but were not merged back up to the integration branch. I've been looking around but I can't seem to find a way to do it. I would like to be able to run the command and have it tell me all files that have been modified on all of the sub-branches but not merged up. Thanks.
Normally, you use ct findmerge to find files to merge from one branch or view into the current view (assuming ct is an alias for cleartool).
I think you would have to identify all the branches you are interested in and do a separate ct findmerge operation for each branch - for each destination branch. That's complex. You'd also want to be able to eliminate many branches which are known to be fully merged. You can annotate a branch to indicate that it is fully merged.
So, I don't think there is a simple, single command to do this job.
You need to decide which branches are targets that you're concerned about. These would be your integration branch(es). Presumably, you have a fairly small list of these.
For each of those target branches, you need to decide which work branches are relevant to that integration branch. This is the tricky part; there is no easy way to determine whether a particular bug fix or feature branch is relevant to that integration branch using information in the VOBs; it is really only known by the users.
You then need a script that does (in outline):
for int_branch in $(list_relevant_integration_branches)
do
...create view with tag $tag for $int_branch...
ct setcs -f $(cspec_for_integration_branch $int_branch) $tag
ct setview -exec "find_outstanding_merges_for_integration_branch $int_branch" $tag
done
where find_outstanding_merges_for_integration_branch looks a bit like:
vob_list=$(list_relevant_vobs)
for mrg_branch in $(list_relevant_merge_branches $int_branch)
do
echo
echo "Merges from $mrg_branch to $int_branch"
ct findmerge $vob_list -fversion .../$mrg_branch/LATEST -print
done
Note that this command assumes (a) the current view is appropriate for the target, and (b) the integration branch name is passed as an argument.
You can get fancy and decide how to handle automatic or graphical merges instead of -print. The hard part is still the unwritten commands such as list_relevant_integration_branches and list_relevant_vobs. These might be simple:
# list_relevant_integration_branches
cat <<EOF
integration_branch_version_3_0
integration_branch_version_3_1
integration_branch_version_4_0
EOF
# list_relevant_vobs
cat <<EOF
/vobs/mainproject
/vobs/altproject
/vobs/universal
EOF
Or they might be considerably more complex. (If you only have one VOB, then your life is much simpler; the systems we work with have 20-odd VOBs visible in the cspec.)
The other unwritten script is list_relevant_merge_branches. I don't know whether there's a simple way to write that. If you define and apply appropriate attribute types (ct mkattype, ct mkattr) when the development branches are created (perhaps a 'target integration branch' attribute type, an enumeration type), you could use that to guide you. That leaves you with a retrofit problem; how to get the correct attribute onto each existing working branch. You also need a separate attribute to identify branches that no longer need merge scrutiny, unless you decide that the absence of a 'target integration branch' attribute means 'no need to scrutinize any more'. That reduces the retrofit problem to adding the target integration branch to those branches that still need merging; by default, all existing branches will be deemed fully merged.
If you know the source and destination branches (topic detailed in Jonathan's answer, which I have upvoted), then don't forget the query primitive merge:
merge (from-location , to-location)
In all cases, TRUE if the element to which the object belongs has a merge hyperlink (default name: Merge) connecting the from-location and to-location.
You can specify either or both locations with a branch pathname or a version selector.
Specifying a branch produces TRUE if the merge hyperlink involves any version on that branch.
The branch pathname must be complete (for example, /main/rel2_bugfix, not rel2_bugfix).
This thread illustrates that query in action:
How is it possible to find all the elements on a specific branch that are checked in and not merged away?
cleartool find \\view\administration\ProjectVOB \
-branch "brtype(HNH-372452) && \
!merge(...\HNH-372452\LATEST,...\main-372452\LATEST)" -print
\\view\administration\ProjectVOB\Com-API\Dll\COMFrontendDll\Mmi.cpp##\main\HNH-372452
\\view\administration\ProjectVOB\geometry\geochain\geocutterloc.cpp##\main\HNH-372452
That "merge hyperlink" is the red arrow you see in version tree:
(see article "Versioning and parallel development of requirements")