Our project has maintainers and reviewers with a 12 hour time difference. We have agreed to allow PRs to remain open for at least 24 hours so that everyone has a chance to review and comment. Unfortunately, this is easy to forget or overlook, especially for small PRs.
We would like to automate this as a check.
Is there an existing action, app, or check suite to enforce a minimum PR review period? (I am not interested in writing my own.)
If you're on an enterprise plan, you can use environment protection rules.
More specifically, configure a new environment pr-sleeper and set the wait time to 24 hours (1440 minutes):
The second step is to create a workflow that uses the environment:
name: Wait for 24h
on: pull_request
jobs:
wait:
runs-on: ubuntu-latest
environment: pr-sleeper
steps:
- run: echo done
Essentially, this means the job is blocked for 24 hours and then automatically proceeds to print 'done'.
So when you now create it a PR, you'll see a check like so:
If you want to ensure nobody can merge before the 24 have passed, also create a branch protection rule for the target branch and add this as a required check.
Related
The documentation doesn't specify how to prevent workflow cancellation, however, it'd be useful for my case.
In my opinion it would make sense to have a configuration option to either hide or disable the 'Cancel workflow' button when the given workflow is running.
Posting this here as an answer for visibility (please if someone from Github is reading this, update me):
Apparently, this feature is not yet implemented, for now you can only use if: ${{ cancelled() }} or if: ${{ always() }} to run operations even if the workflow is canceled, note that the jobs will be killed after 5min from receiving the signal (source)
After the 5 minutes cancellation timeout period, the server will force
terminate all jobs and steps that don't finish running or fail to
complete the cancellation process.
Also, as you may know: Runs can be only manually triggered and cancelled by the contributors. So you may consider limiting the access to your organisations
See:
https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization
https://github.com/orgs/community/discussions/26064
I have two workflows that are triggered at the same time and both push a commit to a branch.
While there's no risk of a merge conflict because both commits affect different files, the problem is that there's no merge at all. The two simultaneous commits result in diverging history on that branch, and only one of the commits is retained in the branch. The other is lost.
E.g. when branch gh-pages is at commit A, and two simultaneous workflows push commits B and C respectively:
What I'd like is for both commits to be retained on the branch. It doesn't matter what order they're in so long as they're there.
I can think of a couple of ways this might be possible:
The workflows need to be run in series rather than in parallel. I found a couple of Actions that could be used for this, e.g. https://github.com/lewagon/wait-on-check-action, but these actions seem to require that the specified workfow be run or have finished running while the other action takes place. I can't guarantee this - either of my two actions could also be started individually.
There might be a Git-based way of getting around the issue - e.g. if I can find out the SHA of both commits, I can subsequently create a merge commit. But the two workflows, while started simultaneously, don't know about each others' existence... right?
Using concurrency and assigning both workflows to the same concurrency group such that only one can run at a time. But, the maximum queue length is 1 - there can only be one pending workflow at a time (any existing pending workflow is cancelled). This seems safe for 2 workflows, but does it scale to a hypothetical case of 3 or more simultaneous workflows (or even 3 workflows initiated within a few minutes of each other, depending on how long they take to complete)?
Given that the two workflows both create a commit on a given branch, and can be started simultaneously but could also be started individually, how can I make sure that both of those commits end up in the history of that branch?
I think the most modern approach is concurrency - using a proper key for it you can put as many workflows as you need into a queue.
Before concurrency, the best approach that was working for me was to detect problems on the GIT level.
You run all those workflows and let them push - there is nothing like simultaneous commits - one of them will be first the second one will be rejected.
I was implementing proper rejection handling - if git refuses to take a commit - you just retry it.
In case you need to regenerate your data taking into account master branch state - just git reset, git pull - try again - until it works.
I'd like to abstract some of my GitHub Actions with a reusable workflow.
In order to do this, I need to call my newly defined callable workflow in the format {owner}/{repo}/{path}/{filename}#{ref}
e.g. (from the docs)
jobs:
call-workflow-1:
uses: octo-org/this-repo/.github/workflows/workflow-1.yml#172239021f7ba04fe7327647b213799853a9eb89
call-workflow-2:
uses: octo-org/another-repo/.github/workflows/workflow-2.yml#v1
However, in practice, I'm working on my branch, some-branch-name, where I'm working on my workflow-1.yml file and I'd like to be able to run my actions as defined in my current branch, Given
`{ref} can be a SHA, a release tag, or a branch name.
It seems like I'd need to use
jobs:
call-workflow-1:
uses: octo-org/this-repo/.github/workflows/workflow-1.yml#some-branch-name
But, I'd like this to work for any branch, so
jobs:
call-workflow-1:
uses: octo-org/this-repo/.github/workflows/workflow-1.yml#${{ github.ref }}
But, it turns out this isn't possible as expressions can't be used in the uses attributes.
How can I achieve this?
EDIT: This is now supported as of 25 January 2022
(check TWiStErRob's answer for more details).
Previous answer (before 2022 update)
It's as you said: 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.
Note that someone else had the same issue here
This is now supported as of 25 January 2022.
https://github.blog/changelog/2022-01-25-github-actions-reusable-workflows-can-be-referenced-locally/
Example usage from blog:
jobs:
call-workflow-in-local-repo:
uses: ./.github/workflows/workflow-2.yml
And a real life example from my opened issue:
https://github.com/TWiStErRob/net.twisterrob.healthcheck/pull/28
Note: With this ./ syntax the reusable workflow definition (.yml file) and the usage (uses from a job) must be in the same repository. See: here for more info.
Update: DO NOT USE THIS, see other answer.
A really hacky (and untested) way to workaround this.
Based on the fact that a workflow can contain multiple jobs, and assuming a low-churn PR environment one could set up something like this:
jobs:
tag-my-workflow:
steps:
- name: git tag ${{ github.ref }} as "current-branch"
uses: see for example https://levelup.gitconnected.com/how-to-move-a-git-tag-using-github-actions-e23a523eb325
call-workflow:
needs: tag-my-workflow
uses: my/repo/.github/workflows/called.yml#current-branch
I used the workflow-dispatch github action described here to successfully trigger a workflow B in the same repo (note that you need to set up a personal access token secret and include ref: ${{ github.event.pull_request.head.ref }} to refer to the current branch).
But unfortunately workflow A continues once workflow B has been triggered, rather than waiting around to see if workflow B succeeds. As suggested in this thread it might be possible to use another github action to make workflow A wait for workflow B to successfully finish, but that seemed like overkill for me... maybe this'll be useful to someone else though. Fingers crossed it gets supported instead :D
We all know that this is untenable and must have a solution in the long term: You're going to want to establish a common pipeline and have perhaps hundreds of repos calling the same workflow. Having to commit to 'main' on your reusable workflow to test it could break every pipeline that depends on it. So GHA will pick up this functionality soon enough simply because it has to.
Workaround: What about forking instead of branching for now? You can develop and test on the fork and submit a PR when it works.
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.
We use Jenkins for doing incremental builds of our project on each commit to the SCM. We would like to get separate builds for every single commit. However, the naive approach (setup SCM and use post-commit hooks to trigger a build) exhibits problem in the following scenario:
Build is triggered.
While build takes place (it can take up to several minutes) two separate commits to the SCM are made by two developers.
One new build is triggered. It receives changes from both of the commits, made during previous build.
This "race condition" complicates finding which one of the commits has broken the build/introduced warnings.
The currently employed solution is checking for changes in one job ("scheduler job") and triggering another job to do the actual checkout and build.
Are there any proper solutions to this problem?
Not yet, there's a Feature Request covering this kind of build, but it's still open: Issue 673
Maybe it misses the point, but we have a pretty nice build process running here.
We use git as our source control system
We use gerrit as our review tool
We use the gerrit trigger to run builds on our jenkins server
We check for changes on the develop branch to run jenkins when a changeset is merged
In short the ideal developer day is like this
developer 1 stars a new branch to do his changes, based on our main develop branch
The developer 1 commits as often as he likes
developer 1 thinks he finished his job, he combines his changes into one change and pushes it to gerrit
A new gerrit change is created and jenkins tries to build exactly this change
When there are no errors during the build, a review is made on this change
When the review is submited, the changeset is merged into the develop branch of the main repository (No change is merged into the develop branch, without review)
Jenkins builds the merged version to be sure, that there are no merge errors
no developer 2 joins the party and tries to do some work
the process is exactly the same both start working, in there branches. Developer 1 is faster and his changes are merged into the develop branch. Now, before developer 2 can publish his changes he has to rebase his changes on top of the changes made by developer 1.
So we are sure, that the build process is triggered for every change made to our codebase.
We use this for our C# development - on windows not on linux
I don't believe what you'd like to do is possible. The "quiet period" mentioned by Daniel Kutik is actually used to tell Hudson/Jenkins how much time to wait, in order to allow other commits to the same project to be picked up. Meaning -- if you set this value to 60 seconds and you've made a commit, it will wait for a minute before starting a new build, allowing time for other commits to be picked up as well (during that one minute).
If you use the rule "NO COMMIT on a broken build‏" and take it to it's logical conclusion, you actually end up with "No commit on a broken build or a build in progress", in which case the problem you describe goes away.
Let me explain. If you have two developers working on the same project and both of them try to commit (or push if you're using DVCS). One of them is going to succeed and and they other will fail and need to update before the commit.
The developer who had to do the update knows from the commit history, that the other commit was recent and thus a build in progress (even if it hasn't checked out yet). They don't know if that build is broken yet of not, so the only safe option is to wait and see.
The only thing that would stop you from using the above approach is if the build takes so long, in which case you might find that your developers never get a chance to commit (it's always building). This is then a driver to split up your build into a pipeline of multiple steps, so that the Post Commit job takes no more than 5 minutes, but is ideally 1 minute.
I think what might help, is to set the Quiet Period (Jenkins > Manage Jenkins > Configure System) to 0 and the SCM Polling to a very short time. But even during that short interval there could be two commits. As of now Jenkins does not have the feature to split build into single builds on multiple SVN commit.
Here is a tutorial about that topic: Quiet Period Feature.
As pointed out by someone in Issue 673 you could try starting a parametrized build with the parameter being the actual git commit you want to build. This in combination with a VCS commit hook.