I need a Github action which closes an issue when that issue is moved to a "Done" column on a Github Project.
My issue is that the project_card trigger only works on "classic" projects. Github specifies this in their documentation for the project_card trigger: "This event only occurs for projects (classic)."
I would use a classic project, but unfortunately Github has made it so classic projects cannot be created for repositories unless that repo has an existing classic project. I assume this is to phase out classic projects, which is fine except for triggers like project_card which only work with them.
Hoping there is some form of solution for project_card trigger to work with non-classic Github projects in the interim?
I tried using this Github Action with a non-classic project, but the action uses the project_card trigger which led me to this issue.
Related
I'm trying to create a GitHub action/workflow that will close an Issue when it's State field is set to "Done", but looking at the documentation it appears there are only triggers for the classic projects. Is this correct, are there no triggers for projects v2, or am I missing something?
I want to create a workflow for moving issues in GitHub project boards such as:
When someone creates an issue it moves to the project board "To do".
Once the developer creates a branch with issue name then the issue should move to the different project board "In Progress"
Once the developer finished his work and merge it with the master branch then it should move to project board "Done"
I got some workflow for creating a branch for issues and move-in boards but I am unable to create the flow.
Github API
There is a full project section in the Github API with endpoints you could use to customize your workflows.
Note: here is a similar question
Github Actions
There is also a Github automate project action on the Github marketplace, to use directly in your workflow if it match your context.
Note: There may be others on the github marketplace
looking for workflow solution. We need something like ad-hoc sharing workflow https://docs.bit.dev/docs/workflows/projects with one addition - before the component publishing could happen only after the code review. let me try to describe the short scenario:
there is a repo with the shared components
there are several consumer projects. each one sits in its own repo
there is no dedicated team to maintain the repo with the shared components
the developer of consumer project imports a share component and make changes
the developer wants to create a pull request for a component changes
So far I see only one solution - the developer manually applies changes he made locally to a shared library repo and manually creates a pull request. Kind of boring. Does the bit.dev provide an automated solution for such case?
While a PR-like feature is still not available in Bit, you can use Git's PR workflow to set up a code review process for components with some automation.
Note this flow can work regardless of the specific workflow your team implements. In this answer, I'll focus on the ad-hock flow, as your team uses.
You'll first need to set up automation on your projects, that when there's a change in component's code, your CI will bit tag && bit export the modified components. This should happen only when a PR is approved and merged to master branch (in Git).
Then using the Git integration feature set up your projects to receive PRs on new versions for components.
With these two setups, this will be the workflow your team can utilize:
Import component to any project and modify.
Submit PR to the project.
Have a peer do a code review.
When change is merged, run bit tag && bit export --eject during CI
Commit and push back changes to package.json to the repo (with a skip-ci flag, per your automation infrastructure).
All projects that use that component get a PR from Bit with the newly available version.
I will update this answer whenever a new feature in Bit improves on this workflow.
as Itay says, you can use the GitHub integration on bit.dev.
But if you want, I create demos projects that show how to use GitHub or Azure CI to integrate the project with Bit, and export new components when code our pushed to master, and also run Bit script on PRs.
https://github.com/teambit/bit-with-github-actions
https://github.com/teambit/bit-with-azure-devops
I hope it will help you.
I'm using AWS COdeBuild with GitHub on several projects, and I noticed today that it doesn't work anymore. Something's broken, and I don't know what.
I have configured CB to automatically build when a PR is updated. It used to work fine, but now it shows "Expected", without any link toward the CodeBuild build. And, on CodeBuild interface, there isn't any build running.
It's as if the commit on the PR didn't trigger any build on CodeBuild.
Considering everything was working fine, and I don't believe I've made any change to the GitHub nor CodeBuild configuration. So, what could be the reason for the build not to be triggered? What should I look for?
Manually triggering a build from CodeBuild UI works fine, and is properly sync with the PR.
The reason was both stupid and simple: I had renamed the GitHub repository using a different case.
I.e: 'myproject' > 'MyProject'
Changing the source in CodeBuild to load the new source (with updated case) fixed it:
https://github.com/UnlyEd/MyProject.git
Simple, stupid, and so easy to miss. GitHub handles very nicely those name changes and there is no need to change the local git config, as it treats older names as aliases. But CodeBuild must somehow check for the source repository name and doesn't handle case changes.
I'm using Visual Studio Team Services to build my project which is stored in GitHub (here). The master branch contains multiple projects which make up the solution. Amongst those are a WebAPI project and a Cordova project. I need to build those using two separate build definitions in VSTS.
Previously I had set-up my build definition and used the branch filters to filter on what had been pushed to the repo. For instance:
master/src/API
This worked, but it doesn't any more. It seems as if the underlying code has changed. A filter of 'master' still works and I understand how this feature is probably meant to filter specifically on branches and maybe not on folders within the branch?
It's not a huge problem, but at this time all of my builds will trigger with every check-in, even if nothing changed in the meantime for that source code. So I'm not wondering what a good solution for this issue would be:
Put every project in it's own branch. Seems like a workaround
Some other filter option or maybe another syntax or something?
Leave it as it and don't worry about the extra builds (but that itches, you know...)
Anyone running a similar set-up?
Path filters is not supported for VSTS GitHub CI Build, it is available for Git CI Build on VSTS. You can vote this user voice: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/15140571-enable-continuous-integration-path-filters-for-git
The workaround is as you said that put every project in its own branch.