Can you please give a clear explanation, maybe with an example, as to what does github mean when saying that a plan includes 2000 actions minutes/month? If I execute a git pull does this count as one action? How actions connect to minutes? The time I take to pull some commits from a repo counts towards the minutes I have?
I am aware of SO answers (like this) that may tell someone how to calculate the time remaining but I don't really understand what an action is.
For example, say I have a repository with some python/js code and I start working on a new system. When I do a git pull to clone my repository in this new system are there any actions in the backstage that are consumed? Do I consume any time from my plan? This is what I haven't clarified and needed maybe some simple examples to demonstrate. Thanks!
GitHub Actions is a feature provided by GitHub to create workflows which can run on triggering any GitHub event, for eg run the build of the project on creation of a pull request. GitHub actions can be configured by creation of a workflow in the form of a yaml file and placing it under .github/workflows directory in your repo. This documentation provides more info regarding creating workflows.
For example, say I have a repository with some python/js code and I start working on a new system. When I do a git pull to clone my repository in a new system are there any actions in the backstage that are consumed? Do I consume any time from my plan?
No, running a git pull to clone your repo doesn't use up any allocated action minutes.
GitHub actions only run if you have configured them to run by creating the workflows for specific GitHub events as mentioned here. When any actions are configured for a repo, the same can be viewed under the Actions tab as shown below. Every GitHub action triggered shows up here.
Also, the current 2000 action minutes per month allocation is for the triggered workflows for private repos, not public repos. You can check your usage of the free action minutes for private repos at https://github.com/settings/billing, as mentioned in my SO answer here .
That relates to Github Actions, not things like pushing, pulling etc.
Related
During an automated "pages build and deployment" workflow, I get the following error:
Error: Request failed with status code 400
This is just a static site, no jekyll or anything like that (I have a .nojekyll file in the root) and it's worked fine for several years until today.
I've opened a ticket on GitHub support, but in case anyone here can help me in the meantime... Is there anything I can do to try to resolve this?
It could be the side-effect of (from two days ago)
GitHub Pages: using GitHub Actions for builds and deployments for public repositories
Today you will begin to see a new workflow running called pages build and deployment in your public GitHub Pages repositories.
This workflow is automatically triggered when you push to the branch configured for GitHub Pages in your repository.
As the name suggests, it builds and deploys your pages site.
The initial benefit of this change is enabling you to see your build logs and any errors that may occur which has been a long standing issue for Pages users.
However, in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.
You may notice this workflow uses some new actions actions/pages-deploy, and actions/jekyll-build-pages.
For now these actions are designed to be used in the generated workflow, however, starting early next year we will introduce some additional changes that will enable you to take advantage of them.
Learn more about GitHub Pages
So Cecilapp/GitHub-Pages-deploy (the GitHub Pages deploy) workflow you might be using) might behave differently in light of those recent changes.
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 would ask you a question about Jenkins :
Is it possible to apply several pipeline to one github repository ?
If yes, someone can help me with tutorial our documents or other things ?
I've tryed to do this with the BlueOcean plugin but this seems impossible ...
I would like to apply 6 pipepline on one github repository triggerd by events so this question is essential to me !
When you create a job on Jenkins you bind it to a repo.
If you create two jobs and bind them both to the same repo they will both be triggered when you push to your repo. Then you attach your pipelines to these jobs.
You can create pipeline jobs pointing at different build scripts (ie, filenames other than /Jenkinsfile) in the repo or different branches just fine. I do it all the time.
However, be aware that any scm polling you do on the repo/branch could prevent other jobs from identifying changes depending on how you are triggering them.
I followed this answer to set up a Jenkins job, and it's working fine.
I have scheduled a Job on github master commit push as
Poll SCM : * * * * *
But, it continuously starts a build Job each minute.
How can I restrict this so that it runs only once per commit push?
There are several options. The two I've used with most success are:
Use a git commit hook to call the Jenkins rest API to start the job. The simple approach is to call the job's build API call directly (something like http://jenkinsmachine:8080/job/your-jobs-name/build), but that hardcodes the job name and branch into the git hook script. A more flexible approach is to use the Git plugin's own rest mini-API, as described by Kohsuke in his blog.
Use something like the Throttle Concurrent Builds plugin or a creative use of slaves nodes and executors to limit the number of cuncurrent builds of that job.
The first option is much preferred, but there are times when rest access to the jenkins machine from the git machine is not available, so the second option can be used in those circumstances.
This approach is actually polling. That means Jenkins is scanning every minute if there aren't any changes in GitHub repository.
If you want true Push from Github to your Jenkins You need to Integrate Github WebHooks with Jenkins. I wrote a blog post on this subject. Scroll to section 2: "Jenkins - Github Integration"
If you are just playing around or using it for your personal open source project, you may want to look into Jenkins alternatives like Drone.io or Codeship.io. These services are generally free for open source and can configure Github Webhooks in few clicks. But they are not suitable for complicated enterprise builds.
Currently, my team is using TeamCity to automatically build pull requests from GitHub.
We have a configuration to build all the pull requests. In the version control settings of the config, our branch specification is
+:refs/pull/*/merge
In the "Build Triggers" configuration setting, we have only one trigger with the following trigger rule:
+:root=Pull Requests on our Repository:\***/*\*
"Pull Requests on our Repository" is our VCS root name.
The issues:
When someone views a pull request on GitHub website without doing anything else, a build would be triggered in the TeamCity build agent. This is quite annoying, because from time to time, we have multiple build agents building the same pull requests (when multiple people view it).
When someone comments on a pull request, a build would also be triggered.
From my perspective, the only time I want TeamCity to start a build is when new commits are pushed to the pull requests.
Is there a way to do it?
Github's refs/pull/*/merge branches are updated every time mergeability of the branch is recalculated, i.e. on every commit to destination (most likely master) branch. They are also updated when pull request is closed and then reopened. Github's support says these branches are not intended for end users use. The only workaround at the moment is to run builds on refs/pull/*/head branches automatically and on refs/pull/*/merge branches manually.
Do you have TeamCity configured as per this blog post? I then activate the TeamCity service hook in GitHub which takes care of triggering a build in TeamCity whenever there is a push. This seems to do the right thing for me. Or am I missing something?
I know this is old but I wanted to post what we've found as alternatives:
Stop using VCS roots altogether as a mechanism for triggering pull requests. Instead, configure a GitHub webhook to notify a web app of yours whenever there is an update to a PR and only then trigger a build via the TeamCity REST API.
In your build config, add a step that checks what changed in the PR. If nothing changed (i.e. no new commits were added), or if the PR is closed, cancel the build. The problem with this is that the build queue will still be populated with builds that will then be cancelled. Also, you'd have to store somewhere the last commit that was built in order to do the check.
According to their TeamCity's issue tracker, the issue of the TeamCity.GitHub plugin causing an infinite loop of builds was fixed in v9.0