I want the GH action to run when I create pr to master OR push to any other branch.
When I create a new pr, the GH action executed twice, probably something with my config.
Here is the relevant part of the workflow
on:
push:
pull_request:
branches: [ master ]
Please check this topic on GitHub you will find there reference to Skip Duplicate Actions
If you work with feature branches, then you might see lots of duplicate workflow-runs. For example, duplicate workflow-runs can happen if a workflow runs on a feature branch, but then the workflow is repeated right after merging the feature branch. skip-duplicate-actions allows to prevent such runs.
Full traceability: After clean merges, you will see a message like Skip execution because the exact same files have been successfully checked in <previous_run_URL>.
Fully configurable: By default, manual triggers and cron will never be skipped.
Flexible Git usage: skip-duplicate-actions does not care whether you use fast-forward-merges, rebase-merges or squash-merges. However, if a merge yields a result that is different from the source branch, then the resulting workflow-run will not be skipped. This is commonly the case if you merge "outdated branches".
You need to set concurrent_skipping which takes one of the following values never, same_content, outdated_runs, always.
Related
I am developing github workflows in a centralized repository for use by other app teams repositories within our organization.
All of these calling repositories have a main.yml (for push action) and a pull-request.yml (for pull-request-actions). Within these files, these repositories are calling individual workflows in this format:
jobs:
call-workflow:
uses: octo-org/example-repo/.github/workflows/workflow-A.yml#v1
where example-repo contains a release-tag called 'v1'
I am currently working on an automated way to open a PR to these calling repos for new releases and bug-fix versions.
The ay I'm thinking of doing it is:
creating an trigger for release tag creation
looping through all repos in our org
Checking for existance of .github/workflows dir (not all repos in org are making use of our workflows yet)
If found, checking for the call to our workflows
Opening a PR if this workflow tag-ref requires an update.
Is this a good way to go about this? Is there something more preferable? I was hoping to set some kind of org-level $RELEASE_VERSION variable, but it seems these vars cannot be evaluated on a workflow call. Any ideas?
One of the solutions is to refer a branch instead of a release. For example:
jobs:
call-workflow:
uses: octo-org/example-repo/.github/workflows/workflow-A.yml#stable
And then your teams will pull from the stable branch.
The other approach is what you mentioned, have a trigger on tag creation and then have a GitHub bot committing in all of your repositories.
Edit:
There are already some actions like BetaHuhn/repo-file-sync-action you may want to have a look at them as well
Except a tag stated with v pushed to the branch, all other action shall start the pipeline
Here is my code
on:
push:
tags-ignore:
- "v*"
pull_request:
tags-ignore:
- "v*"
Why its stops everything? When I push anything to the branch, nothing is happing with my pipeline
It all works as expected, here is an example
I think you may have a problem of branches versus workflows.
Usually you push all workflows in master branches - that's fine.
But for all existing branches it won't work - if workflow doesn't exist on certain branch, it won't be triggered for it.
You have to either rebase branches on top of master or cherry pick a commit with your workflow to make it work.
I'm using Github actions to run automated tests on every pull request. However, I don't know what is the correct set of events that I should be using. I've seen many variations of this, but I don't know which one is the proper one.
A) Only the pull_request event
on: [ pull_request ]
B) Only the push event
on: [ push ]
C) Both push and pull_request event
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
I started trying option (A), with only the pull_request event. However, that appears to be incompatible with caching dependencies. Each pull request starts with an empty cache; the cache does not carry over to the next pull request.
I then tried to switch to option (B), with only the push event. The automated tests appear to run correctly for pull requests that are entirely inside my repository. However, if someone opens a pull request from an external fork, the status ends up stuck as "Expected — Waiting for status to be reported". I don't know if this is expected behavior, because when I googled for that message I got very few hits which I don't believe are related to my problem. (I'm not sure, this Github actions stuff is completely baffling.)
Finally, I tried switching to option (C) with both the push event and the pull event, as suggested in the Github starter workflows. However, when I do this every the CI runs twice for every pull request. Once before it is merged and another time after it is merged. This seems terribly redundant and wasteful; I'd prefer if my test scripts only had to run once.
At the end, I'm terribly confused. Option (B) does what I want unless a fork is involved, in which case it fails miserably. Option (C) seems to be the default that Github recommends, but it runs the automated tests twice instead of only once. That can't possibly be right! What is the correct approach here?
I've read similar posts of SO, the official Hg guide, many articles and guides, and it's still unclear to me what the best Hg workflow is for developing by feature. Maybe some of the articles on the web are years old and don't include the latest features from Hg. Obviously there's also a lot of options in how to approach it.
I'm a solo developer working on a project where a request for a fix or feature will be submitted to me as a task, like "Task #546 - Change whatever". Some of these tasks take a few days, and some tasks are open for months and there's often up to a dozen going at one time. A task is shipped to the final site after it's approved by the requestor.
The Hg guide seems to recommend having a clone per feature. But having a dozen full copies of the site on my drive seems... wasteful? I'm up for trying it, but I've seen other suggestions that make more sense. Do people really have a dozen copies of each site on their dev machine at a time?
Name branches at first sound like what I'd want, where's I'd name a branch "task 546" work on it, then merge it back in when it ships. I see a lot of discussion about the permanence of the names and having so many branches (though they can be closed). Some people seem to care about that and some don't. I don't know Hg enough to know if I care or not, and what the downsides really mean.
Finally, bookmarks seem to be popular with the more recent articles and it would seem that the best way to use them would be to set a bookmark like "task 546" then when you merge it back into the main branch using a commit message that has the task number in it to keep a reference to what was being done in the work. I know you can delete bookmarks, but it's unclear if I'd need to do this after the final merge.
So my thought for a combined approach is to have:
one repo
three named branches:
"default" which holds the released version of the site
"dev" on which I do feature development
"test" which would hold all of the tasks being reviewed by the client
on the "dev" branch I would use bookmarks for each of the tasks that I'm working on, so I'd have a head for each task
My workflow for a task/feature would be to:
Update to the main line of the "dev" named branch
Start a new branch using a bookmark for the task "task #123"
Commit changes until I'm ready for the client to review
Merge "task #123" into the "test" branch
Deploy "test" to the test server
Repeat the commit, merge, deploy until ready for production
When approved, merge with the main line of the "dev" branch with a commit message that includes the task name
Merge "dev" into the "default" branch.
Deploy the "default" branch to the live server
Merge "default" into the open feature branches
Thoughts? Would I be better off just having a clone for each feature, and a "live" and "test" repo that I push to?
Edit: I see from some links that I should be doing the development off of "default" so my first change to my listed process would be to use a name "production" branch instead of a named "dev" branch.
Bookmarks-style of branching (Git-like "branches") works poorly in, at least, two common cases
Cross-tasks merges in the process of development
Time-back machine, when you'll want to see "the whole history of changes for task#123" (you can do it visually and, with some grimaces and jumping, using revsets)
While using named branches haven't such problems and, btw, workflow with named branches (and only default branch as aggregation point) will be less complex and more logical way
Default contain only mergesets from task-branches, head of default is always "stable version"
Heads of named branches are WIP; branches, merged to default - finished (and accepted by customer - see below) work
Default, merged to task-branch (after development of task, before merging task-branch to default) is equivalent of your "test": without affecting mainline you can test final state of feature, integrated into your stable app, show results to customer
Accepted work added to stable mainline by merging named branch to default
History (full history) of changes for every task in the past can be easy restored by using single, easy, short, memorable revset for log: -r "branch(TASK-ID)"
I like it. +1. This is the way I'd do it.
I have a Jenkins build job with a Mercurial trigger on the default branch, which works fine for building "release candidates". This job then starts a smoke test job.
We use a branch-per-feature branching scheme, so that at any given time there could be up to a dozen different active branches in Mercurial (but the active branches change regularly).
I would like a Jenkins job triggered by changes to any branch, that will then build and run the smoke tests for all branches that need updating. Each time we do a build, we should create artifacts named to match the branch.
I saw a suggestion in another answer of using "tip" instead of the branch name in the Mercurial trigger - this is a possibility, but I think it would fall into the "mostly works" category. The trigger is polling, so if changes to more than one branch occur within the polling interval, then a branch update could be missed.
I could create a new job each time a branch is created, but due to the dynamic nature of our branches, that would be a lot of ongoing work.
If you decide to go with the job for every branch approach, the following tools can make the task a bit more manageable:
jenkins-build-per-branch (supports git)
jenkins-autojobs (supports git, mercurial and svn)
I think you'll need to customize: the top-level polling job (tuned to tip) runs a custom script that determines branches that have changed or have been added. It then will use Jenkins API to start a job parameterized by the branch name. That parameter can be used in your job to customize everything you need by the branch name (including the artifacts).