I would like to run a specific workflow when a new repository is created, so that I can guide the user in performing an initial setup that corresponds to the standard required by the organization (i.e. setup branch protection, create an empty project with right naming convention, enable dependabot and more).
I did not find anything in the documentation to provide such level of automation, looking at the event triggers this seems not supported.
Is there anything I'm missing or do you have any idea on how I could do such things?
Related
Various posts (including Github API - create branch?) give the API calls to make to create a new branch in a github repo, and can obviously be used in a script. I have a slightly different usecase though: I need to create a release branch (like release-1.2.3) when I already have a branch protection rule to cover release-*. The problem: without the branch protection rule, the linked method worked, while with it I get error:
422 Unprocessable Entity
The branch protection rule is fairly standard: requires a PR, requires a status check (I believe only applies to the PR?), "Restrict who can push to matching branches" and "Restrict pushes that create matching branches" are ticked and set to a group that contains all our main team, but includes the user who corresponds to the Jenkins job from where I am running this from.
My guess is that if I can use the new(ish) "bypass branch protections" and clear the "Do not allow bypassing the above settings" settings in the rule would work - can't actually try as yet because I don't have the rights to create the associated custom role but probably will. Alternatively creating the branch on a local repo and pushing it should work given the permissions (yet to try as more scripting but probably will). Question: has anybody got an easier way of doing this?
I have a GiHub repository with GitHub actions based workflow (/.github/workflows/build.yml) to do CI builds.
I am from the DevOps team, my case, folks from development team are not allowed to change CI pipelines, they can change whatever they want on a feature branch except “/.github/workflows/build.yml”.
How to prevent a developer changing GitHib workflow to see his app changes passing through different type of integration build quality checks ?
Is there any better approach to achieve this other than options mentioned below ?
1] Through PR reviews
2] Script/automation to validate PR to see if dev did any changes to (/.github/workflows/build.yml
With code owners you can specify who is allowed to modify certain files like so:
# .github/CODEOWNERS
.github/workflows/build.yml #myorg/devops-team
Somewhat off-topic, but note that Toughtworks does not recommend to separate code and pipeline ownership:
[..] in general we find it painful and unhelpful.
I see this
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github
I want to implement a custom web based github workflow similar to this workflow.
The workflow I have in mind involves allowing a group of developers to help with conflict resolution during a large merge/sync process.
Process involves the following steps. A lot of it will be the existing workflow described above, except that we are looking to do webex integration to notify multiple users and bring them all into helping resolving the conflicts
Create a PR
Start a Sync/Merge from branchA to branch B or Apply a patchfilelargeA to branch B
Collect the list of conflicts and have a conflict resolution page similar to the above link.
Identify the owners of the related change set with git blame
Integrate with Webex to create a Webex space with the list of blame owners so they can help with resolving the conflicts
Let these owners go to this PR, and show them a conflict resolution page similar to the 1 above and have them help resolve conflicts and mark them resolve
Review the resolution/changes
Merge the changes into the target branch.
Questions
Can custom actions like interacting with webex/bot be integrated into the github sync conflict resolution page? and if so how?
If this does not involve 2 branches but instead a branch and a large patch, is there a way to create a customized worklow that will allow that.
Is it possible within GitHub Actions to mark a workflow as something that is not a check? I can't find a hint inside the (good) documentation unfortunatly
I have included two default workflows to label pull requests and to greet first time contributors, but i don't want those workflows to be listed as "checks" since they aren't checking anything.
See here: https://github.com/wujood/awesome-gamejam/pull/3
It looks like it's not possible if you're triggering on the pull_request event. As a workaround you could try using a schedule or another event as a trigger.
As per https://github.blog/changelog/2019-09-24-ui-changes-in-github-actions-checks/ they explicitly changed the UI to don't display some checks.
GitHub Actions uses the Checks API for representing and storing information about job executions.
[...]
At the same time, Actions can be triggered not just when somebody pushes code to GitHub but when many other events occur. In these cases, GitHub Actions looks for workflow files in the default branch of the repository and creates and associates the checks with the SHA of the latest commit.
[...]
We have found that this can be noisy and not relevant in the context of a pull request. It can also cause friction when protected branch rules are enabled. As of today, we’re deploying a change to remove checks generated due to events other than push and pull_request from the context of pull requests or in the calculation of commit statuses. These checks will be available in the Actions tab for observability.
(emphasis mine)
And also:
GitHub Actions use the Checks API to output statuses, results, and logs for a workflow. GitHub creates a new check suite for each workflow run. The check suite contains a check run for each job in the workflow, and each job includes steps.
source: https://docs.github.com/en/free-pro-team#latest/actions/managing-workflow-runs/using-workflow-run-logs
There is also the following closed issue corresponding to the UI change described above: https://github.com/actions/toolkit/issues/86.
Whenever I try to import a workflow from Dev/Test environment of a versioned repository into Production environment which is also versioned, I get a option where it asks me if I want to Check in or continue without check in. What happens if I do not check in and continue? Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in? I am asking this because, it will be double work if all the objects used will not be checked in including the Workflow, then, I have to go one by one to check in the objects. If I check the check in option for the workflow, after importing the Workflow, the integration service is left blank and when I run it, it is pointing towards the Integration service not mentioned error. For this I generally check out the workflow once I import just to mention the Integration service name. I do not think this is a good practice. Any advices on this will be greatly appreciated.
Thanks
Dhruuv.
Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in?
The objects that will be left in the checked out state are:
the workflow,
the new objects (i.e. they were not present in the Prod repository before the import from Dev/Test),
the modified objects (i.e. they were present in the Prod repository but were overwritten because you chose the Replace option).
I have to go one by one to check in the objects
You don't have to check in every individual object - in Repository Manager open the Versioning menu and choose the Find Checkouts... option. All the checked out objects will be listed - you can select them and check in all of them at once.