I am creating a new git workflow. And just like any other piece of code, I want to test it separately without having to merge it into master first.
This will also help if I have to make few corrections if something doesn't work in the workflow yaml.
Here is the mechanism that I am looking for:
main branch has .github folder which contains all workflows
I create a branch and add my workflow to .github folder
Now I should be able to see(somewhere on Github) workflows from my branch running
When I know that workflows are working fine, I merge my branch in master
Now under github 'Action' tab, new workflows will reflect
Is there a way to do this?
I am actually doing workflow testing all the name, as you can see this test workflow workflow-level-notification is not merged into master branch (ie default branch), and I can still see the workflows in the UI.
Like GuiFalourd said, you can also use act to do the local testing as well. But working directly in the github repo is not that bad. (you can delete the workflow after)
If you would like to test non PR triggerd actions you can simply update your default branch temporarially, run the actions for test, then when you are done switch back.
Related
I want to automatically merge commits from master into another parallel branch which is used for different deployment strategy. So essentially whenever there is a change in master I want that change to be merged into one more branch automatically.
Is there a way in Github UI to do so?
Github does support automerge, but only for Pull Request.
You might check out a GitHub Action like action-automerge
GitHub action to automatically merge the source branch into a target branch every time a change is made.
You can add a GitHub Action workflow to your project in order to enable that "action-automerge".
That being said, maybe you have other approaches which would be simpler than merging master/main. Using the same branch but with a deployment script able to detect its execution environment would be easier.
I'm looking for a solution to dynamically select a branch to build in the Azure pipeline. I have Azure Repos Git where I select project, repository and default branch. I would like to be able to select branch based on a variable.
What I'm trying now is to use the Command Line task and fire a git checkout command (e.g. branch is a variable):
git checkout $(branch)
I can't confirm it working yet but still I confirm it works but I feel that there is a better option than checking out default branch and then switching branch with the command line.
Update:
If you want to have single pipeline that can build different branches (version branches) for different branches, you could just specify them in the trigger of branch filters. This will not build all branches.
The branch you select in build definition is just the default branch used when you Queue New Build manually. OTOH the build trigger establish which branch to download, e.g. if the build has been triggered by a git push on branch develop then that is the one checkout'ed and built. Take a look at this link: Get the sources from the branch that triggered the build in Team Services
Besides, you could disable the default get source step.Then use you own powershell script and git command to get source code manually(just what you want) and check out branch, finally build based on your variable.
For YAML, to disable the default "Get Sources" just specify none in
the checkout:
checkout: none
For UI, please refer my reply in this question:
Is it able to ignore/disable the first step Get source in vNext Build?
Assuming you're choosing the default branch. That doesn't mean that
it's the only branch that can be built by that build definition.
You can choose which branches to monitor for CI (on the Triggers tab,
you can add multiple branch filters to represent the branches you wish
to build on commit), and the appropriate branch will be checked out
when the build is triggered. You can also choose an alternate branch
when manually queuing the build.
Source Link: Get Sources from multiple branches
If you want to dynamically select default branch as below, this is not available at present.
This is the branch that you want to be the default when you manually
queue this build. If you set a scheduled trigger for the build, this
is the branch from which your build will get the latest sources.
The default branch has no bearing when the build is triggered
through continuous integration (CI). Usually you'll set this to be
the same as the default branch of the repository (for example,
"master").
There is a related user voice here: When triggering a build, use the same branch as the trigger build. You could kindly vote up and track the process.
We use an internally hosted github server for our SCM, Jenkins for our CI and Git-Flow (via maven's jgitflow plugin) for our branching strategy.
I have a Jenkins build job set up such that it takes the git branch as a parameter and then can check-out and build the correct branch based on what was selected.
.....
.....
.....
What I would like - is to automatically trigger the BASE_JOB to build only the branch that's been pushed. So far, I have been unable to find any way to do this.
If I set up to build when changes are pushed to github, then the job will simply rebuild whatever the last built branch was regardless of the branch that's been pushed.
I've seen some plugins for Jenkins that will auto-generate template jobs when new branches are created - but I think it is over-kill to necessitate having a job per currently active branch.
Is there a way to pass a branch parameter to the "Build when a change is pushed to GitHub"? Or some other way to work around this apparent limitation?
Thanks!
Check with these settings and see if it works.
We have over 100 repos which follow the github workflow https://guides.github.com/introduction/flow/. Ideally, when people are merging their code, they'll also click the Delete Branch button, but unfortunately, that step gets missed pretty often. I'm looking for a way to automatically delete branches which have been merged to the master branch. I'm thinking it should either be an organizational level webhook or integrated into our existing Jenkins system. I'm hoping that someone has already written this tool. Anyone?
We are using a private GitHub Organization as version control. When a task is assigned to a developer, they fork the primary repository, make their code changes, and submit a pull request to have the changes merged into the master branch of the primary repository.
We are also using TeamCity for CI. It is currently configured to kick off a build for a VCS commit, which builds, tests, and deploys the artifact to an artifact repository internally. To accomplish this, the Team City build configuration has multiple VCS roots installed; one for the primary and 1 for each developer's fork.
The problem is that Team City pulls from all of them when a commit is made assuming they are all necessary for the build instead of allowing you to only pull from the single repository that triggered the build. Any thoughts on how we can accomplish this without having to create n build configurations in Team City for each project (where n == number of developers working on a project)?
I see way to do this with preserving current workflow is turning off automatic checkout (VCS Checkout Mode), and checking out code manually in an additional command-line build step, with a parameter %teamcity.build.branch% (logical branch name).
I.e.:
git clone ...
git checkout %teamcity.build.branch%
Triggers will just start the job if there are changes in developer's VCS root, fulfill branch env variable; no automatic checkout will happen and then build step will check out only needed branch. Only works with one git URL.
After posting in the JetBrains forums, I was pointed to a blog that answers my question.
TL;DR: my approach of using feature branches does not work with GitHub's workflow. Instead, Forks and Pull Requests should be used. The blog referenced shows how you can use Team City to trigger off of a Pull Request. Simply add +:refs/pull/*/head to "Branch Specification" in your VCS Root and all pull requests to the Source repository will trigger your Build Configuration.