Conversation
Run Dockers add it with Jekyll
Add Docker Image CI workflow, add,M 365.remaned, Agent Cortana, in memory of Cortana live again please. I liked Cortana,she is built i to all Co Pilots
|
Skip to main content Workflow runs triggered by a contributor's pull request from a fork may require manual approval from a maintainer with write access. You can configure workflow approval requirements for a repository, organization, or enterprise. Workflow runs that have been awaiting approval for more than 30 days are automatically deleted. Approving workflow runs on a pull request from a public fork Under your repository name, click Pull requests. Screenshot of the main page of a repository. In the horizontal navigation bar, a tab, labeled "Pull requests," is outlined in dark orange. On the pull request, click Files changed. Screenshot of the tabs for a pull request. The "Files changed" tab is outlined in dark orange. If you are comfortable with running workflows on the pull request branch, return to the Conversation tab, and in the section "n workflow(s) awaiting approval", click Approve workflows to run. Help and support Privacy policy Still need help? |
There was a problem hiding this comment.
Pull request overview
This PR adds a Jekyll-based CI workflow to a React portfolio repository. However, the changes are fundamentally incompatible with the repository's existing technology stack and contain security issues.
Key Issues:
- The Jekyll workflow is incompatible with this React-based portfolio application
- Critical security vulnerability using
chmod -R 777 - Missing permissions declaration in the workflow
- Workflow trigger conflicts with existing deploy.yml workflow
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| -v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \ | ||
| jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future" |
There was a problem hiding this comment.
Using chmod -R 777 is a significant security risk as it grants read, write, and execute permissions to all users on all files and directories. This overly permissive approach can lead to security vulnerabilities. Instead, consider using more restrictive permissions or running the container with appropriate user permissions using the --user flag in docker run.
| -v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \ | |
| jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future" | |
| --user $(id -u):$(id -g) \ | |
| -v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \ | |
| jekyll/builder:latest jekyll build --future |
| branches: [ "main" ] | ||
| pull_request: | ||
| branches: [ "main" ] | ||
|
|
There was a problem hiding this comment.
This workflow lacks a permissions declaration. GitHub Actions workflows should explicitly define the permissions they require following the principle of least privilege. The existing deploy.yml workflow in this repository includes a permissions block. Consider adding a permissions section to specify exactly what access this job needs, or use 'permissions: {}' if no special permissions are required beyond the default read-only access.
| permissions: | |
| contents: read |
| on: | ||
| push: | ||
| branches: [ "main" ] | ||
| pull_request: | ||
| branches: [ "main" ] |
There was a problem hiding this comment.
The workflow is configured to trigger on push and pull_request events to the main branch, which overlaps with the existing deploy.yml workflow that also triggers on pushes to main. This duplication could lead to unnecessary CI runs, wasted resources, and potential conflicts. Since this repository uses React/Node.js (not Jekyll), this workflow should likely be removed entirely, or if both are needed, their trigger conditions should be differentiated.
| name: Jekyll site CI | ||
|
|
||
| on: | ||
| push: | ||
| branches: [ "main" ] | ||
| pull_request: | ||
| branches: [ "main" ] | ||
|
|
||
| jobs: | ||
| build: | ||
|
|
||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v4 | ||
| - name: Build the site in the jekyll/builder container | ||
| run: | | ||
| docker run \ | ||
| -v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \ | ||
| jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future" |
There was a problem hiding this comment.
This Jekyll workflow appears to be incompatible with the repository's technology stack. The repository is a React-based portfolio application (as evidenced by package.json, the existing deploy.yml workflow, and the React source files), not a Jekyll site. Adding a Jekyll-based CI workflow would not function correctly for this project and conflicts with the existing Node.js/React deployment workflow in deploy.yml.
|
Maintainers with write access to a repository can use the following procedure to review and run workflows on pull requests from contributors that require approval. |
1 participant
Skip to main content
GitHub Docs
Site policy/GitHub Terms/GitHub Community Guidelines
GitHub Community Guidelines
In this article
Millions of developers across the world host millions of projects—both open and closed source—on GitHub. We're fortunate to be able to play a part in enabling collaboration across the developer community every day, which is a responsibility we don’t take lightly. Together, we all have the exciting opportunity to make this a community we can be proud of.
Our diverse user base brings different perspectives, ideas, and experiences, and ranges from people who created their first "Hello World" project last week to the most well-known software developers in the world. We are committed to making GitHub an environment that welcomes all the different voices and perspectives our community has to offer, while maintaining a safe place for developers to do their best work.
By outlining what we think a safe, welcoming, and productive community looks like at GitHub, we hope to help you understand how best to interact and collaborate on our platform in line with our Terms of Service and Acceptable Use Policies.
We encourage our community members to communicate expectations clearly, moderate their projects where possible, and report any content that may violate our policies. GitHub Staff will investigate any reports of abuse, and may moderate public content on our site that we determine to be in violation of our Terms of Service.
Maintaining a strong community
The primary purpose of the GitHub community is to collaborate on software projects. We are committed to maintaining a community where users are free to express themselves and challenge one another's ideas, both technical and otherwise. At the same time, it's important that users remain respectful and allow space for others to contribute openly. In order to foster both a safe and productive environment, we encourage our community members to look to these guidelines to inform how they interact on our platform. Below, you’ll find some suggestions for how to have successful interactions as a valued member of the GitHub community.
Be welcoming and open-minded - New users join our community each day. Some are well-established developers, while others are just beginning. Be open to other ideas and experience levels. Make room for opinions other than your own and be welcoming to new collaborators and those just getting started.
Be respectful - Working in a collaborative environment means disagreements may happen. But remember to criticize ideas, not people. Share thoughtful, constructive criticism and be courteous to those you interact with. If you’re unable to engage respectfully, consider taking a step back or using some of our moderation tools to deescalate a tense situation.
Be empathetic - GitHub is a global community with people from a wide variety of backgrounds and perspectives, many of which may not be your own. Try to put yourself in others’ shoes and understand their feelings before you address them. Do your best to help make GitHub a community where others feel safe to make contributions, participate in discussions, and share different ideas.
What if something or someone offends you?
While some disagreements can be resolved with direct, respectful communication between community members, we understand that is not always the case. We encourage our community to contact GitHub Support through the GitHub Support portal when they believe content or activity they’ve encountered violates our policies. However, if you run into something or someone on the site that you find objectionable, here are some ways GitHub enables you to take action:
Communicate expectations - Maintainers can set community-specific guidelines to help users understand how to interact with their projects, for example, in a repository’s README, CONTRIBUTING file, or dedicated code of conduct. You can find additional information on building communities on the Communities page.
Moderate Comments - Users with write-access privileges for a repository can edit, delete, or hide anyone's comments on commits, pull requests, and issues. Anyone with read access to a repository can view a comment's edit history. Comment authors and people with write access to a repository can also delete sensitive information from a comment's edit history. Moderating your projects can feel like a big task if there is a lot of activity, but you can add collaborators to assist you in managing your community.
Lock Conversations - If a discussion in an issue, pull request, or commit gets out of hand, off topic, or violates your project’s code of conduct or GitHub’s policies, owners, collaborators, and anyone else with write access can put a temporary or permanent lock on the conversation. For more information, see Locking conversations.
Block Users - If you encounter a specific user who you would rather not engage with, you can block the user from your personal account or from your organization.
Limit Interactions - If your public project is getting unwanted attention, being trolled, spammed, or otherwise, you have the option of setting temporary interaction limits to keep certain users from interacting with your repository. You can even set code review limits to ensure quality contributions on your projects.
While we are passionate about empowering maintainers to moderate their own projects, please contact us through the GitHub Support portal if you need additional support in dealing with a situation.
What happens if someone violates GitHub's policies?
We rely on reports from the community, as well as proactive detection, to help ensure that GitHub is a safe, welcoming, and productive platform for software developers. There are a variety of factors we consider when we’re made aware of behavior or content not in line with GitHub’s policies. However, our policy enforcement and content moderation approach prioritizes our vision to be the home for all developers. This means:
We optimize for code collaboration. We recognize that code can have multiple uses and we distinguish between how the code is being used on the platform and other possible uses. We also think about how our enforcement actions can affect a potentially complicated web of interdependencies across the platform and aim to restrict as little legitimate content as possible.
We take a human-centered approach to content moderation and we tailor our responses to meet the needs of a specific situation. Our global team investigates the reports we receive on a case-by-case basis—considering context and the surrounding facts—before taking action. This could include taking into account potentially offensive content being posted in a way that lacks context or makes it easy for other users to unwittingly view or interact with while using GitHub. In those instances, we may favor moderation in order to safeguard our community.
Our decisions are rooted in our core belief that serving an interconnected community and empowering human progress through developer collaboration requires a commitment to diversity, inclusion, and belonging.
Where we have decided that moderation action is warranted, these are some of the ways we may respond:
Removing the offending content
Blocking or disabling the offending content
Downgrading the visibility of the offending content
Hiding a user account or organization from public view
Suspending a user account or organization
Appeal and Reinstatement
If your content or account has been disabled or restricted and you seek reinstatement or wish to appeal, please see our Appeal and Reinstatement page for information about the process and use our Appeal and Reinstatement form to submit a request.
Legal Notices
We dedicate these Community Guidelines to the public domain for anyone to use, reuse, adapt, or whatever, under the terms of CC0-1.0.
These are only guidelines; they do not modify our Terms of Service and are not intended to be a complete list. Under those terms, GitHub retains full discretion to remove any content or terminate any accounts for activity that violates our Acceptable Use Policies. These guidelines describe when we will exercise that discretion.
Help and support
Help us make these docs great!
All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.
Learn how to contribute
Still need help?
Ask the GitHub community
Contact support
Legal
© 2026 GitHub, Inc.
Terms
Privacy
Status
Pricing
Expert services
Blog